Fix const-eval of shared generic reborrows
`Rvalue::Reborrow` const-eval now handles shared generic reborrows produced by `CoerceShared`. Those reborrows intentionally copy from the source ADT into a distinct same-layout target ADT, so the interpreter uses the transmute-capable copy path for `Mutability::Not`.
Promotion is intentionally kept conservative: promotion candidates whose validated temporary graph contains `Rvalue::Reborrow` are rejected, so generic/user-defined reborrows are not promoted.
Fixesrust-lang/rust#156313.
cc @aapoalas
Tracking: rust-lang/rust#145612
@rustbot label F-reborrow
MIR inlining: allow backends to opt-in to inlining intrinsics
This is the same as https://github.com/rust-lang/rust/pull/156398. Github stopped processing updates on that other branch.
r? @oli-obk
Fix suggestion of unused variables with raw identifier in struct pattern
This MR fixes a broken lint suggestion that occurs when a struct pattern contains an unused variable written with a raw identifier.
In the following fragment, `r#move` is an unused variable. The compiler suggested to change it to `move: _` which doesn’t compile since move is a keyword. This change makes it so that the suggestion becomes `r#move: _`
```rust
struct Foo {
r#move: u32
}
fn bar(foo: Foo) -> u32 {
match foo {
Foo { r#move } => 0
}
}
```
r? JonathanBrouwer
Remove unsound `target_feature_inline_always` feature
## Summary
- Remove `target_feature_inline_always`
- Update stdarch generators to only use `#[inline]` & regenerate stdarch.
## Why?
Succinctly; the feature relies on LLVMs `AlwaysInlinerPass()` running before LLVMs heuristic based inliner pass. Which is not a basis for sound code.
This has been discussed in [the tracking issue](https://github.com/rust-lang/rust/issues/145574).
If the ordering of the passes were to change, of which they have in the past, it is very possible we could inline functions across callsites with mismatching target features leading to unsound code. Checks proposed in; https://github.com/rust-lang/rust/pull/155426 would only take into account caller -> callee which is not enough to guard against possibly of generating unsound code if the pass ordering were to change.
There doesn't seem to be a way, presently, this this mechanism to provide soundness guarantees nor does it seem like `AlwaysInlinerPass()` is a desired feature of LLVM, which this feature relies on.
r? @RalfJung
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
DestinationPropagation: compute liveness as ranges instead of traveling bitsets
The current implementation of `save_as_liveness` is very slow, and consists in inserting a traveling bitset in an interval set.
As the `MaybeLiveLocals` has a gen-kill property, we can leverage it to make it faster. "Gen" is creating a new interval. "Kill" is ending this interval, ripe to save in the interval set.
Fix unused assignments in diverging branches
Fixesrust-lang/rust#156416
Add `location` and use `is_predecessor_of` to check in the control flow graph.
r? @ghost
I'd like to see whether there is performence regression.
This function doesn't have an obvious home, but there's little reason for it to
be in mir-transform, and having it in `rustc_driver_impl::pretty` at least puts
it near other callers of `write_mir_pretty`.
Using https://github.com/rust-lang/rustfmt/pull/6893, reformat the codebase. The result is that matches that *would have* been formatted under normal circumstances get their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
Have arrays' `drop_glue` just unsize and call the slice version
It's silly to emit two loops (because of the drop ladder -- just one in panic=abort) for every array length that's dropped when we can just polymorphize to the slice version.
Built atop rust-lang/rust#154327 to avoid conflicts later, so draft for now.
r? @WaffleLapkin
Simplify `intrinsic::raw_eq` in MIR when possible
After https://github.com/rust-lang/rust/pull/150945 things can inline enough to have this end up specific enough that we can remove it, for example changing `raw_eq::<[u8; 4]>(a, b)` → `Transmute(a) == Transmute(b)`.
The LLVM backend can also do this (and in more cases too) but we might as well do it in MIR instead when we can so it applies to all backends and other MIR optimizations can apply afterwards.
change the type of the argument of `drop_in_place` lang item to `&mut _`
We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack:
https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392
This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf.
This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`:
https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833
------
The rest of the PR is blessing tests and cleaning up things which are not necessary after this change.
One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that?
I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper)
-------
cc @RalfJung
Closes https://github.com/rust-lang/rust/issues/154274
Remove unused spans from AttributeKind
Recently I noticed some spans in diagnostic attributes were never used. I went through and checked the other variants too.
compiler: Print valid `-Zmir-enable-passes` names if invalid name is used
If a user passes an invalid name to `-Zmir-enable-passes`, print the valid names as a note.
To avoid the annoyance of having to keep blessing test output, completely normalize away the list of names in the test.
The diagnostic is duplicated, but that is not introduced by this commit. In other words, we don't make matters worse. The existing "is unknown and will be ignored" diagnostic is already duplicated, as can be seen in the existing test stderr.
The output is on one long line, but that makes normalization in tests easier, and I don't think we have to overdo this. We can let terminals wrap the line.
<details>
<summary>Click to expand current output</summary>
`note: valid MIR pass names are: AbortUnwindingCalls, AddCallGuards, AddMovesForPackedDrops, AddRetag, CheckAlignment, CheckCallRecursion, CheckConstItemMutation, CheckDropRecursion, CheckEnums, CheckForceInline, CheckInlineAlwaysTargetFeature, CheckLiveDrops, CheckNull, CheckPackedRef, CleanupPostBorrowck, CopyProp, CtfeLimit, DataflowConstProp, DeadStoreElimination-final, DeadStoreElimination-initial, Derefer, DestinationPropagation, EarlyOtherwiseBranch, ElaborateBoxDerefs, ElaborateDrops, EnumSizeOpt, EraseDerefTemps, ForceInline, FunctionItemReferences, GVN, ImpossiblePredicates, Inline, InstSimplify-after-simplifycfg, InstSimplify-before-inline, InstrumentCoverage, JumpThreading, KnownPanicsLint, LowerIntrinsics, LowerSliceLenCalls, Marker, MatchBranchSimplification, MentionedItems, MultipleReturnTerminators, PostAnalysisNormalize, PreCodegen, PromoteTemps, ReferencePropagation, RemoveNoopLandingPads, RemovePlaceMention, RemoveStorageMarkers, RemoveUninitDrops, RemoveUnneededDrops, RemoveZsts, ReorderBasicBlocks, ReorderLocals, RequiredConstsVisitor, SanityCheck, ScalarReplacementOfAggregates, SimplifyCfg-after-unreachable-enum-branching, SimplifyCfg-final, SimplifyCfg-initial, SimplifyCfg-make_shim, SimplifyCfg-post-analysis, SimplifyCfg-pre-optimizations, SimplifyCfg-promote-consts, SimplifyCfg-remove-false-edges, SimplifyComparisonIntegral, SimplifyConstCondition-after-const-prop, SimplifyConstCondition-after-inst-simplify, SimplifyConstCondition-final, SimplifyLocals-after-value-numbering, SimplifyLocals-before-const-prop, SimplifyLocals-final, SingleUseConsts, SsaRangePropagation, StateTransform, StripDebugInfo, Subtyper, UnreachableEnumBranching, UnreachablePropagation, Validator`
</details>
Reuse CTFE MIR for constructors.
For constructors, we manually build the MIR shim we want. We can just have `optimized_mir` call `mir_for_ctfe` instead of rebuilding the shim.
Add a `Local::arg(i)` helper constructor
While reading through stuff I was noticing just how many `+1` fixes there were in various places (and comments explaining those fixups), so this adds a new inherent helper on `Local` for making an argument to help make this clearer.
r? mir
If a user passes an invalid name to `-Zmir-enable-passes`, print the
valid names as a note.
The diagnostic is duplicated, but that is not introduced by this commit.
In other words, we don't make matters worse. The existing "is unknown
and will be ignored" diagnostic is already duplicated.
To avoid the annoyance of having to keep blessing test output,
completely normalize away the list of names in the test.
Guillaume Gomez