cg_llvm: Assert that LLVM range-attribute values don't exceed 128 bits
The underlying implementation of `LLVMCreateConstantRangeAttribute` assumes that each of `LowerWords` and `UpperWords` points to enough u64 values to define an integer of the specified bit-length, and will encounter UB if that is not the case.
Our safe wrapper function always passes pointers to `[u64; 2]` arrays, regardless of the bit-length specified. That's fine in practice, because scalar primitives never exceed 128 bits, but it is technically a soundness hole in a safe function.
We can close the soundness hole by explicitly asserting `size_bits <= 128`. This is effectively just a stricter version of the existing check that the value must be small enough to fit in `c_uint`.
---
This is a narrower version of the fix in rust-lang/rust#145846.
Implement some more checks in `ptr_guaranteed_cmp`.
* Pointers with different residues modulo their allocations' least common alignment are never equal.
* Pointers to the same static allocation are equal if and only if they have the same offset.
* Pointers to different non-zero-sized static allocations are unequal if both point within their allocation, and not on opposite ends.
Tracking issue for `const_raw_ptr_comparison`: <https://github.com/rust-lang/rust/issues/53020>
This should not affect `is_null`, the only usage of this intrinsic on stable.
Closes https://github.com/rust-lang/rust/issues/144584
The underlying implementation of `LLVMCreateConstantRangeAttribute` assumes
that each of `LowerWords` and `UpperWords` points to enough u64 values to
define an integer of the specified bit-length, and will encounter UB if that is
not the case.
Our safe wrapper function always passes pointers to `[u64; 2]` arrays,
regardless of the bit-length specified. That's fine in practice, because scalar
primitives never exceed 128 bits, but it is technically a soundness hole in a
safe function.
We can close the soundness hole by explicitly asserting `size_bits <= 128`.
This is effectively just a stricter version of the existing check that the
value must be small enough to fit in `c_uint`.
Support non-defining uses in HIR typeck
This changes the impl of `NormalizesTo` for opaque types to be structural during HIR typeck. The previous impl equated region variables of the opaque type key with existing entries which can result in spurious leak check errors and also results in mismatches with MIR borrowck, theoretically causing ICE.
The approach is very similar to rust-lang/rust#145244 in MIR typeck:
- we collect all uses of opaque types during HIR typeck
- before writeback, we search for *defining uses*
- the opaque type key has fully universal generic args modulo regions
- the hidden type has no infer vars
- we use these defining uses to compute the concrete type for the opaque and map it to the definition site
- we use this concrete type to check the type of all uses of opaques during HIR typeck. This also constrains infer vars in non-defining uses
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/135, fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/49.
r? `@BoxyUwU`
cg_llvm: Replace the `llvm::Bool` typedef with a proper newtype
This should be nicer and more type-safe than the old typedef for `c_int`/`i32`.
Using `#[repr(transparent)]` should ensure that it's still ABI-compatible.
Account for impossible bounds making seemingly unsatisfyable dyn-to-dyn casts
Fixes https://github.com/rust-lang/rust/issues/141806
When we have an impossible where clause like `dyn Trait<u8>: Sized`, this may make a dyn-to-dyn cast like `dyn Trait<()> -> dyn trait<u8>` to successfully type check as if it were a wide-to-thin ptr cast (discarding metadata):
16ad385579/compiler/rustc_hir_typeck/src/cast.rs (L862-L865)
In borrowck, we are expecting that the only meaningful dyn-to-dyn cast to be a metadata-preserving wide-to-wide ptr cast, which requires that the principals of the dyn pointers are equal. Borrowck additionally assumes that these principals have already been proven equal *modulo regions*, and we thus ICE since `Trait<u8>` and `Trait<()>` do not unify:
16ad385579/compiler/rustc_borrowck/src/type_check/mod.rs (L1481-L1524)
This PR fixes this ICE by checking whether the RHS of the cast is considered to be Sized in the environment of the MIR typeck, and if so then skipping over this dyn->dyn principal compatibility check.
r? `@lcnr` perhaps?
Remove chunk size from each chunk in `ChunkedBitSet`.
Almost all chunks in a `ChunkedBitSet` have the same constant `CHUNK_SIZE`, except the last in a bitset which takes the remainder `domain_size % CHUNK_SIZE`.
r? `@ghost` for perf
Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES`
Fixes https://github.com/rust-lang/rust/issues/145772
This PR changes the primary span(s) of the `MISMATCHED_LIFETIME_SYNTAXES` to point to the *unnamed* lifetime spans in both the inputs and *outputs* of the function signature. As reported in rust-lang/rust#145772, this should make it so that IDEs highlight the spans of the actionable part of this lint, rather than just the (possibly named) input spans like they do today.
This could be tweaked further perhaps, for example for `fn foo(_: T<'_>) -> T`, we don't need to highlight the elided lifetime if the actionable part is to change only the return type to `T<'_>`, but I think it's improvement on what's here today, so I think that should be follow-up since I think the logic might get a bit hairy.
cc ```@shepmaster```
Add lint against integer to pointer transmutes
# `integer_to_ptr_transmutes`
*warn-by-default*
The `integer_to_ptr_transmutes` lint detects integer to pointer transmutes where the resulting pointers are undefined behavior to dereference.
### Example
```rust
fn foo(a: usize) -> *const u8 {
unsafe {
std::mem::transmute::<usize, *const u8>(a)
}
}
```
```
warning: transmuting an integer to a pointer creates a pointer without provenance
--> a.rs:1:9
|
158 | std::mem::transmute::<usize, *const u8>(a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is dangerous because dereferencing the resulting pointer is undefined behavior
= note: exposed provenance semantics can be used to create a pointer based on some previously exposed provenance
= help: if you truly mean to create a pointer without provenance, use `std::ptr::without_provenance_mut`
= help: for more information about transmute, see <https://doc.rust-lang.org/std/mem/fn.transmute.html#transmutation-between-pointers-and-integers>
= help: for more information about exposed provenance, see <https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance>
= note: `#[warn(integer_to_ptr_transmutes)]` on by default
help: use `std::ptr::with_exposed_provenance` instead to use a previously exposed provenance
|
158 - std::mem::transmute::<usize, *const u8>(a)
158 + std::ptr::with_exposed_provenance::<u8>(a)
|
```
### Explanation
Any attempt to use the resulting pointers are undefined behavior as the resulting pointers won't have any provenance.
Alternatively, `std::ptr::with_exposed_provenance` should be used, as they do not carry the provenance requirement or if the wanting to create pointers without provenance `std::ptr::without_provenance_mut` should be used.
See [std::mem::transmute] in the reference for more details.
[std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html
--------
People are getting tripped up on this, see https://github.com/rust-lang/rust/issues/128409 and https://github.com/rust-lang/rust/issues/141220. There are >90 cases like these on [GitHub search](https://github.com/search?q=lang%3Arust+%2Ftransmute%3A%3A%3Cu%5B0-9%5D*.*%2C+%5C*const%2F&type=code).
Fixes https://github.com/rust-lang/rust-clippy/issues/13140
Fixes https://github.com/rust-lang/rust/issues/141220
Fixes https://github.com/rust-lang/rust/issues/145523
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
Fix ICE when validating transmuting ZST to inhabited enum
MIR validation attempts to determine the number of bytes needed to represent the size of the source type to compute the discriminant for the inhabited target enum. For a ZST source, there is no source data to use as a discriminant so no proper runtime check can be generated.
Since that should never be possible, insert a delayed bug to ensure the problem has been properly reported to the user by the type checker.
Fixesrust-lang/rust#145786
