Regression test for trait-system-refactor#7
Adds a regression test for [`AliasRelate` hides info in transitive cases](https://github.com/rust-lang/trait-system-refactor-initiative/issues/7).
The example previously errored under the new solver but compiles cleanly now thanks to eager normalization (post-rust-lang/rust#119106). Verified on both the `old` and `next` revisions.
The issue body has an older TODO suggesting a goal-proving variant test; per lcnr's recent note in `#t-types/trait-system-refactor` ("this isn't an issue as we eagerly normalize"), the underlying mechanism is now resolved across both inference and goal-proving paths, so this single regression test is sufficient. Closing the upstream issue manually after merge.
r? @lcnr
Add `const_param_ty_unchecked` gate
Add `const_param_ty_unchecked` internal feature gate to skip `ConstParamTy_` trait enforcement on type. Provides an escape hatch for writing tests and examples that use const generics without needing to ensure all fields implement `ConstParamTy_`.
r? BoxyUwU
Fix 'assign to data in an index of' collection suggestions
fixes https://github.com/rust-lang/rust/issues/150001
fixes https://github.com/rust-lang/rust-analyzer/issues/16076
fixes https://github.com/rust-lang/rust/issues/134917
The issues are threefold and linked:
1. Assigning data to a ~~collection~~BTreeMap/HashMap suggests 3 solutions all marked as `MachineApplicable`
2. The suggestions are slightly wrong with regards to their borrowing needs.
3. The suggestions are not guaranteed to produce code that is valid, and suggestion number two is equivalent to an update, not an insertion.
This PR:
- splits the large triple suggestion into three
- sets them to `MaybeIncorrect`
- automatically determines the required borrowing to use.
I think this solution may not be very elegant, expecially the key typechecking / borrowing part, but it works. I am however very open to any improvement/change :)
edit: edited to replace 'collection' with BTreeMap/HashMap'
refactor rustc_on_unimplemented's filtering
Previously when you had a
```rust
pub struct Directive {
pub is_rustc_attr: bool,
pub condition: Option<OnUnimplementedCondition>,
pub subcommands: ThinVec<Directive>,
pub message: Option<(Span, FormatString)>,
...
}
```
that condition would control the emission of the message, label, notes etc. I've changed that to
```rust
pub struct Directive {
pub is_rustc_attr: bool,
pub filters: ThinVec<(Filter, Directive)>,
pub message: Option<(Span, FormatString)>,
...
```
so that the message etc is always emitted, and there's a vec of tuples with (filter, directive) where the filter controls whether that directive is even emitted, which i think is much clearer. That also makes it easier to not have to do the reverse iteration thing and this makes it so that notes are emitted in declaration order (with nonfiltered options always last).
The rename is because I plan on making it available to other diagnostic attributes at some point (very wip) so `OnUnimplementedCondition` and the like would have to be renamed anyway.
Validate source snippet when format input is raw string
Fixesrust-lang/rust#114865
The issue occurred because the user's proc macro respanned the format arg to an unrelated multi-byte string and we ICE'd by landing in the middle of a multi-byte char.
This PR adds validation that prevents the parser from trying to walk such obviously wrong snippets. Such validation already existed for non-raw strings. This PR adds it for raw strings as well.
Make retags an implicit part of typed copies
Ever since Stacked Borrows was first implemented in Miri, that was done with `Retag` statements: given a place (usually a local variable), those statements find all references stored inside the place and refresh their tags to ensure the aliasing requirements are upheld. However, this is a somewhat unsatisfying approach for multiple reasons:
- It leaves open the [question](https://github.com/rust-lang/unsafe-code-guidelines/issues/371) of where to even put `Retag` statements. Over time, the AddRetag pass settled on one possible answer to this, but it wasn't very canonical.
- For assignments of the form `*ptr = expr`, if the assignment involves copying a reference, we probably want to do a retag -- but if we do a `Retag(*ptr)` as the next instruction, it can be non-trivial to argue that this even retags the right value, so we refrained from doing retags in that case. This has [come up](https://github.com/llvm/llvm-project/pull/160913#issuecomment-3341908717) as a potential issue for Rust making better use of LLVM "captures" annotations. (That said, there might be [other ways](https://github.com/rust-lang/unsafe-code-guidelines/issues/593#issuecomment-4328112031) to obtain this desired optimization.)
- Normal compilation avoids generating retags, but we still generate LLVM IR with `noalias`. What does that even mean? How do MIR optimization passes interact with retags? These are questions we have to figure out to make better use of aliasing information, but currently we can't even really ask such questions.
I think we should resolve all that by making retags part of what happens during a typed copy (a concept and interpreter infrastructure that did not exist yet when retags were initially introduced). Under this proposal, when executing a MIR assignment statement, what conceptually happens is as follows:
- We evaluate the LHS to a place.
- We evaluate the RHS to a value. This does a typed load from memory if needed, raising UB if memory does not contain a valid representation of the assignment's type.
- We walk that value, identify all references inside of it, and retag them. If this happens as part of passing a function argument, this is a protecting retag.
- We store (a representation of) the value into the place.
However, this semantics doesn't fully work: there's a mandatory MIR pass that turns expressions like `&mut ***ptr` into intermediate deref's. Those must *not* do any retags. So far this happened because the AddRetag pass did not add retags for assignments to deref temporaries, but that information is not recorded in cross-crate MIR. Therefore I instead added a field to `Rvalue::Use` to indicate whether this value should be retagged or not. A non-retagging copy seems like a sufficiently canonical primitive that we should be able to express it. Dealing with the fallout from that is a large chunk of the overall diff. (I also considered adding this field to `StatementKind::Assign` instead, but decided against that as we only actually need it for `Rvalue::Use`. I am not sure if this was the right call...)
This neatly answers the question of when retags should occur, and handles cases like `*ptr = expr`. It avoids traversing values twice in Miri. It makes codegen's use of `noalias` sound wrt the actual MIR that it is working on. It also gives us a target semantics to evaluate MIR opts against. However, I did not carefully check all MIR opts -- in particular, GVN needs a thorough look under the new semantics; it currently can turn alias-correct code into alias-incorrect code. (But this PR doesn't make things any worse for normal compilation where the retag indicator is anyway ignored.)
Another side-effect of this PR is that `-Zmiri-disable-validation` now also disables alias checking. It'd be nicer to keep them orthogonal but I find this an acceptable price to pay.
- [rustc benchmark results](https://github.com/rust-lang/rust/pull/154341#issuecomment-4125313290)
- [miri benchmark results](https://github.com/rust-lang/rust/pull/154341#issuecomment-4129840926)
added a valid example that violated the assumption in the proposed
change: it is possible for a borrowee type to be a ref of it's borrowed
type.
removed the assumption, treated all cases appropriately.
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>
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.
linker-messages is warn-by-default again
cc rust-lang/rust#136096
I ended up keeping it a lint and adding an option for lints to ignore `-Dwarnings` (there was already a lint that did that actually, it was just hard-coded in rustc_middle instead of in rustc_lint_defs like I'd expect). This allows people to actually see the warnings without them failing the build in CI.
Adds a couple UI tests for polonius
I went through all the open issues labeled `fixed-by-polonius` and from that created two UI tests based on issues that seemed a little novel.
One for rust-lang/rust#92038 and another for rust-lang/rust#70044.
Both tests fail under NLL but pass with polonius (legacy and alpha).
Fix order-dependent visibility diagnostics
Fixesrust-lang/rust#40066.
Fixes https://github.com/rust-lang/rust/issues/109657.
Delay visibility path diagnostics until module collection has finished, so paths to later non-ancestor modules report E0742 instead of an unresolved path error.
It used to ICE when hitting an `assert_ne!(location.block, successor.block` due
to hitting a self-dominating bb
Fixed by checking *strict* domination instead of normal one
Suggest public re-exports when a private module makes an import path inaccessible
This is an attempt at solving rust-lang/rust#13065.
When a `use` path fails because it passes through a private module (E0603), and a public re-export of the target item exists elsewhere, the compiler will now suggest importing through that re-export instead.
For example, given:
```rust
mod outer {
pub use self::inner::MyStruct;
mod inner {
pub struct MyStruct;
}
}
use outer::inner::MyStruct; // error: module `inner` is private
```
the compiler will now suggest use `outer::MyStruct`; - the publicly accessible path - rather than just pointing at the private module definition and leaving the user to figure out the alternative.
When possible, relative paths are suggested, including those using `super` (currently capped at a maximum of one `super` path item).
The newly added test is parametrised by editions because of the change in behaviour around `crate::`-prefixed imports in edition 2018. Perhaps that’s an overkill – I’ll be happy to remove the variations for editions 2021 and 2024.
Closesrust-lang/rust#13065.
a set of slightly different tests showing that E0594 can be reached in
some cases via autodereferencing, but also that slight variations
produce E0277 instead.
SynapLink