Tie `impl_trait_overcaptures` lint to Rust 2024
The `impl_trait_overcaptures` lint is part of the migration to Rust 2024 and the Lifetime Capture Rules 2024. Now that we've stabilized precise capturing (RFC 3617), let's tie this lint to the `rust_2024_compatibility` lint group.
Tracking:
- https://github.com/rust-lang/rust/issues/117587
r? `@compiler-errors`
mv `build_reduced_graph_for_external_crate_res` into Resolver
`build_reduced_graph_for_external_crate_res` is only related to `Resolver`, so move it there.
r? `@petrochenkov`
const checking: properly compute the set of transient locals
For const-checking the MIR of a const/static initializer, we have to know the set of "transient" locals. The reason for this is that creating a mutable (or interior mutable) reference to a transient local is "safe" in the sense that this reference cannot possibly end up in the final value of the const -- even if it is turned into a raw pointer and stored in a union, we will see that pointer during interning and reliably reject it as dangling.
So far, we determined the set of transient locals as "locals that have a `StorageDead` somewhere". But that's not quite right -- if we had MIR like
```rust
StorageLive(_5);
StorageDead(_5);
StorageLive(_5);
// no further storage annotations for _5
```
Then we'd consider `_5` to be "transient", but it is not actually transient.
We do not currently generate such MIR, but I feel uneasy relying on subtle invariants like this. So this PR implements a proper analysis for computing the set of "transient" locals: a local is "transient" if it is guaranteed dead at all `Return` terminators.
Cc `@cjgillot`
The `impl_trait_overcaptures` lint is part of the migration to Rust
2024 and the Lifetime Capture Rules 2024. Now that we've stabilized
precise capturing (RFC 3617), let's tie this lint to the
`rust_2024_compatibility` lint group.
add back test for stable-const-can-only-call-stable-const
This got accidentally removed in https://github.com/rust-lang/rust/pull/128596 (file `tests/ui/internal/internal-unstable-const.rs`). The test has little to do with "allow internal unstable" though, so add it in a file that already tests various const stability things.
Also tweak the help that suggests to add `rustc_allow_const_fn_unstable` to make it clear that this needs team approval, since it is a fairly big gun.
Use `FxHasher` on new solver unconditionally
r? lqd
This should actually fix the inference problem in ad855fe6db, since `HashSet::default` was not inferring the hasher when `HashSet` was coming from the stdlib due to the way that defaulted types/inference vars work. You could cherry-pick this on top of your PR alternatively.
rustdoc: clean up tuple <-> primitive conversion docs
This adds a minor missing feature to `fake_variadic`, so that it can render `impl From<(T,)> for [T; 1]` correctly.
Remove redundant flags from `lower_ty_common` that can be inferred from the HIR
...and then get rid of `lower_ty_common`.
r? ``@fmease`` or re-roll if you're busy!
Use subtyping for `UnsafeFnPointer` coercion, too
I overlooked this in #129059, which changed MIR typechecking to use subtyping for other fn pointer coercions.
Fixes#129285
Make `rustc_type_ir` build on stable
This PR fixes a handful of issues that appear in `rustc_type_ir` when trying to build the new solver on stable.
r? ```@compiler-errors```
```@bors``` rollup
library: Move unstable API of new_uninit to new features
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as it was decided to only stabilize `uninit*` and `assume_init`.
Print the generic parameter along with the variance in dumps.
This allows to make sure we are testing what we think we are testing.
While the tests are correct, I discovered that opaque duplicated args are in the reverse declaration order.
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint
Revives #120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.
Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.
The suggestion is not made for `&mut CString` or `*mut CString`.
r? ``````@cjgillot`````` (since you were the reviewer of the original PR #120176, but feel free to reroll)
Detect `*` operator on `!Sized` expression
The suggestion is new:
```
error[E0277]: the size for values of type `str` cannot be known at compilation time
--> $DIR/unsized-str-in-return-expr-arg-and-local.rs:15:9
|
LL | let x = *"";
| ^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `str`
= note: all local variables must have a statically known size
= help: unsized locals are gated as an unstable feature
help: references to `!Sized` types like `&str` are `Sized`; consider not dereferencing the expression
|
LL - let x = *"";
LL + let x = "";
|
```
Fix#128199.
Retroactively feature gate `ConstArgKind::Path`
This puts the lowering introduced by #125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :)
cc #129137 ``@camelid,`` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta.
Fixes#128016
make writes_through_immutable_pointer a hard error
This turns the lint added in https://github.com/rust-lang/rust/pull/118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in https://github.com/rust-lang/rust/pull/117905. Still, let's do a crater run just to be sure.
Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of https://github.com/rust-lang/rust/pull/129195 which is already nominated for discussion.
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as
it was decided to only stabilize `uninit*` and `assume_init`.
