Assert that non-extended temporaries and `super let` bindings have scopes
This PR clarifies a point of confusion in the compiler: all bodies have an outer temporary drop scope, including `static` and `const` item bodies[^1]. Whenever a temporary should be dropped in its enclosing temporary scope, it should have a temporary scope to be dropped in so that its drop can be scheduled[^2]. As such, I've updated some relevant comments and made `ScopeTree::default_temporary_scope` and `RvalueScopes::temporary_scope` panic when an enclosing temporary scope isn't found instead of allowing potential bugs where potentially-drop-sensitive temporaries are effectively given static lifetimes.
Since non-extended `super let` bindings are dropped in their block's enclosing temporary scope, this applies to them as well: the enclosing temporary scope should exist.
[^1]: See https://github.com/rust-lang/rust/blob/master/compiler/rustc_hir_analysis/src/check/region.rs#L773-L778 for non-`fn`/closure bodies. The `this.cx.var_parent = None;` enables [lifetime extension to `'static` lifetimes](https://doc.rust-lang.org/stable/reference/destructors.html#r-destructors.scope.lifetime-extension.static) and the `ScopeData::Destruction` scope ensures non-extended temporaries are dropped in the body expression's scope.
[^2]: For certain borrowed temporaries, drops that don't require running destructors may later be removed by constant promotion. That is unrelated to this PR.
Fix normalization overflow ICEs in monomorphization
Fixesrust-lang/rust#92004Fixesrust-lang/rust#92470Fixesrust-lang/rust#95134Fixesrust-lang/rust#105275Fixesrust-lang/rust#105937
Fixes rust-lang/rust#117696-2
Fixesrust-lang/rust#118590Fixesrust-lang/rust#122823Fixesrust-lang/rust#131342Fixesrust-lang/rust#139659
## Analysis:
The causes of these issues are similar. They contain generic recursive functions that can be instantiated with different args infinitely at monomorphization stage.
Ideally this should be caught by the [`check_recursion_limit`](c0bb3b98bb/compiler/rustc_monomorphize/src/collector.rs (L468)) function. The reality is that normalization can reach recursion limit earlier than monomorphization's check because they calculate depths in different ways.
Since normalization is called everywhere, ICEs appear in different locations.
## Fix:
If we abort on overflow with `TypingMode::PostAnalysis` in the trait solver, it would also catch these errors.
The main challenge is providing good diagnostics for them. So it's quite natural to put the check right before these normalization happening.
I first tried to check the whole MIR body's normalization and `references_error`. (As elaborate_drop handles normalization failure by [returning `ty::Error`](c0bb3b98bb/compiler/rustc_mir_transform/src/elaborate_drop.rs (L514-L519)).)
It turns out that checking all `Local`s seems sufficient.
These types are gonna be normalized anyway. So with cache, these checks shouldn't be expensive.
This fixes these ICEs for both the next and old solver, though I'm not sure the change I made to the old solver is proper. Its overflow handling looks convoluted thus I didn't try to fix it more "upstream".
Perform unused assignment and unused variables lints on MIR.
Rebase of https://github.com/rust-lang/rust/pull/101500
Fixes https://github.com/rust-lang/rust/issues/51003.
The first commit moves detection of uninhabited types from the current liveness pass to MIR building.
In order to keep the same level of diagnostics, I had to instrument MIR a little more:
- keep for which original local a guard local is created;
- store in the `VarBindingForm` the list of introducer places and whether this was a shorthand pattern.
I am not very proud of the handling of self-assignments. The proposed scheme is in two parts: first detect probable self-assignments, by pattern matching on MIR, and second treat them specially during dataflow analysis. I welcome ideas.
Please review carefully the changes in tests. There are many small changes to behaviour, and I'm not sure all of them are desirable.
Extract most code from `define_feedable!`
This PR extracts most of the non-trivial code from the `define_feedable!` macro (which defines the `TyCtxtFeed::$query` methods), and moves it to a helper function `query_feed_inner` written in ordinary non-macro code.
Doing so should make that code easier to read and modify, because it now gets proper IDE support and has explicit trait bounds.
---
There should be no change in compiler behaviour.
I've structured the commits so that the actual extraction part is mostly just whitespace changes, making it easier to review individually with whitespace changes hidden.
Validate CopyForDeref and DerefTemps better and remove them from runtime MIR
(split from my WIP rust-lang/rust#145344)
This PR:
- Removes `Rvalue::CopyForDeref` and `LocalInfo::DerefTemp` from runtime MIR
- Using a new mir pass `EraseDerefTemps`
- `CopyForDeref(x)` is turned into `Use(Copy(x))`
- `DerefTemp` is turned into `Boring`
- Not sure if this part is actually necessary, it made more sense in rust-lang/rust#145344 with `DerefTemp` storing actual data that I wanted to keep from having to be kept in sync with the rest of the body in runtime MIR
- Checks in validation that `CopyForDeref` and `DerefTemp` are only used together
- Removes special handling for `CopyForDeref` from many places
- Removes `CopyForDeref` from `custom_mir` reverting rust-lang/rust#111587
- In runtime MIR simple copies can be used instead
- In post cleanup analysis MIR it was already wrong to use due to the lack of support for creating `DerefTemp` locals
- Possibly this should be its own PR?
- Adds an argument to `deref_finder` to avoid creating new `DerefTemp`s and `CopyForDeref` in runtime MIR.
- Ideally we would just avoid making intermediate derefs instead of fixing it at the end of a pass / during shim building
- Removes some usages of `deref_finder` that I found out don't actually do anything
r? oli-obk
Remove StatementKind::Deinit.
It is a remnant from the time we deaggreated MIR.
Now, it is only constructed by the `LargeEnums` MIR pass, which is disabled by default.
Prefer to use repeat_n over repeat().take()
More from https://github.com/rust-lang/rust/pull/147464, but batch processed with `ast-grep` to find and replace.
second commit add notes for library: affaf532f9
r? ``@RalfJung``
clarify wording of match ergonomics diagnostics (`rust_2024_incompatible_pat` lint and error)
Partially addresses rust-lang/rust#143557:
- Uses different wording than the Edition Guide chapter, to hopefully stand alone a bit better. Instead of referring to the "default binding mode", it now talks about what can't be written "within elided reference patterns". I ended up going with "elided" instead of "implicit" in hope that it reads bit less like it should behave the same as an explicit reference pattern, but I'm not totally happy with that wording.
- The explanatory note still points to where the default binding mode was introduced, but only refers to its effect, not what we call it. How that relates to the rest of the diagnostic may still be a bit of a puzzle, but hopefully it isn't too much of one? It also doesn't make sense anymore for the case of `&` written under a by-ref binding mode, so I've left the note out in that case (but kept the label). It's more cramped, but talking about binding modes would feel like a non-sequitur for the error about `&` patterns without further explanation.
- Links to the stable version of the Edition Guide instead of the nightly version. It looks like almost every link to the Edition Guide in diagnostics is to the nightly version, presumably for the same reason as here: the diagnostics were added before the new Edition was stabilized, then never updated. I'll make a separate PR to clean up the others.
This only changes the diagnostic messages, not the code suggestion or the Edition Guide.
r? `@Nadrieril` or reassign
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146865 (kcfi: only reify trait methods when dyn-compatible)
- rust-lang/rust#147205 (Add a new `wasm32-wasip3` target to Rust)
- rust-lang/rust#147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`)
- rust-lang/rust#147398 (Fix; correct placement of type inference error for method calls)
- rust-lang/rust#147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels)
- rust-lang/rust#147422 (collect-license-metadata: Print a diff of the expected output)
- rust-lang/rust#147431 (compiletest: Read the whole test file before parsing directives)
- rust-lang/rust#147433 (Fix doc comment)
Failed merges:
- rust-lang/rust#147390 (Use globals instead of metadata for std::autodiff)
r? `@ghost`
`@rustbot` modify labels: rollup
kcfi: only reify trait methods when dyn-compatible
fixes https://github.com/rust-lang/rust/issues/146853
Only generate a `ReifyShim` for trait method calls if the trait is dyn-compatible.
Until now kcfi would generate a `ReifyShim` whenever a trait method was cast to a function pointer. But technically the shim is only needed for dyn-compatible traits (where the method might end up in a vtable).
Up to this point that was only slightly inefficient, but in combination with c-variadic trait methods it is wrong. For c-variadic trait methods the generated shim is incorrect, and that is why c-variadic methods make a trait no longer dyn-compatible: we should simply never generate a `ReifyShim` that is c-variadic.
With this change the documentation on `ReifyReason` is now actually correct:
> If KCFI is enabled, creating a function pointer from a method on a dyn-compatible trait. This includes the case of converting `::call`-like methods on closure-likes to function pointers.
cc ```@maurer``` ```@workingjubilee```
r? ```@rcvalle```
Do not assert that a change in global cache only happens when concurrent
Fixesrust-lang/trait-system-refactor-initiative#234
I think it should just be safe to remove this assert (rather than delaying a bug). If the previous and current result are the same, I wouldn't expect issues.
r? lcnr
Introduce debuginfo to statements in MIR
The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix rust-lang/rust#128081.
I don't modify Stable MIR, as I don't think we need debug information when using it.
This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv.
The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.
The current rules for dropping debug information in this PR are:
- If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
- All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.
I doesn't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it.
Turn ProjectionElem::Subtype into CastKind::Subtype
I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.)
The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant.
cc rust-lang/rust#112651, rust-lang/rust#133258
r? Icnr (bc you've been the main person dealing with `Subtype` it looks like)
Rename various "concrete opaque type" things to say "hidden type"
r? lcnr
I've found "concrete opaque type" terminology to be somewhat confusing as in conversation and when explaining opaque type stuff to people I always just talk about things in terms of hidden types. Also the hidden types of opaques are very much not *concrete* in the same sense that a type without any generic parameters is concrete which is an unfortunate overlap in terminology.
I've tried to update comments to also stop referring to things as concrete opaque types but this is mostly best effort as it difficult to find all such cases amongst the massive amounts of uses of "concrete" or "hidden" across the whole compiler.
Much of the compiler calls functions on Align projected from AbiAlign.
AbiAlign impls Deref to its inner Align, so we can simplify these away.
Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq,
as those have odd inference.
Make `def_path_hash_to_def_id` not panic when passed an invalid hash
I'm using this function in a third-party application (Creusot) to access private items (by reverse engineering their hash). This works in the happy path, but it panics when an item does not exist. There is no way to hack it downstream because the hook `def_path_hash_to_def_id_extern` must always return a `DefId` and its implementation uses `def_path_hash_to_def_index` which is internal and which is where the panic happens.
