When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
`tests/ui/issues/`: The Issues Strike Back [4/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ````````@jieyouxu````````
Simplify polonius location-sensitive analysis
This PR reworks the location-sensitive analysis into what we think is a worthwhile subset of the datalog analysis. A sort of polonius alpha analysis that handles NLL problem case 3 and more, but is still using the faster "reachability as an approximation of liveness", as well as the same loans-in-scope computation as NLLs -- and thus doesn't handle full flow-sensitivity like the datalog implementation.
In the last few months, we've identified this subset as being actionable:
- we believe we can make a stabilizable version of this analysis
- it is an improvement over the status quo
- it can also be modeled in a-mir-formality, or some other formalism, for assurances about soundness, and I believe ````````@nikomatsakis```````` is interested in looking into this during H2.
- and we've identified the areas of work we wish to explore later to gradually expand the supported cases: the differences between reachability and liveness, support of kills, and considerations of time-traveling, for example.
The approach in this PR is to try less to have the graph only represent live paths, by checking whether we reach a live region during traversal and recording the loan as live there, instead of equating traversal with liveness like today because it has subtleties with the typeck edges in statements (that could forward loans to the successor point without ensuring their liveness). We can then also simplify these typeck stmt edges. And we also can simplify traversal by removing looking at kills, because that's enough to handle a bunch of NLL problem 3 cases -- and we can gradually support them more and more in traversal in the future, to reduce the approximation of liveness.
There's still some in-progress pieces of work w/r/t opaque types that I'm expecting [lcnr's opaque types rework](https://github.com/rust-lang/rust/pull/139587), and [amanda's SCCs rework](https://github.com/rust-lang/rust/pull/130227) to handle. That didn't seem to show up in tests until I rebased today (and shows lack of test coverage once again) when https://github.com/rust-lang/rust/pull/142255 introduced a couple of test failures with the new captures rules from edition 2024. It's not unexpected since we know more work is needed with member constraints (and we're not even using SCCs in this prototype yet)
I'll look into these anyways, both for future work, and checking how these other 2 PRs would change things.
---
I'm not sure the following means a lot until we have some formalism in-place, but:
- I've changed the polonius compare-mode to use this analysis: the tests pass with it, except 2 cases with minor diagnostics differences, and the 2 edition 2024 opaque types one I mentioned above and need to investigate
- things that are expected to work still do work: it bootstraps, can run our rustc-perf benchmarks (and the results are not even that bad), and a crater run didn't find any regressions (forgetting that crater currently fails to test around a quarter of all crates 👼)
- I've added tests with improvements, like the NLL problem case 3 and others, as well as some that behave the same as NLLs today and are thus worse than the datalog implementation
r? ````````@jackh726````````
(no rush I know you're deep in phd work and "implmentating" the new trait solver for r-a :p <3)
This also fixesrust-lang/rust#135646, a diagnostics ICE from the previous implementation.
add a scope for `if let` guard temporaries and bindings
This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (https://github.com/rust-lang/rust/pull/141295#issuecomment-2968975596). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings.
This only introduces a new scope for match arms with guards. Perf results (https://github.com/rust-lang/rust/pull/143376#issuecomment-3034922617) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes).
Tracking issue for `if_let_guard`: rust-lang/rust#51114
Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295.
The suboptimal error only appears with NLLs due to liveness differences
where polonius cannot have as many boring locals. Sometimes this causes
NLLs to emit a duplicate error as well.
`tests/ui/issues/`: The Issues Strike Back [3/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ```@jieyouxu```
lower pattern bindings in the order they're written and base drop order on primary bindings' order
To fixrust-lang/rust#142163, this PR does two things:
- Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings).
- Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](2a023bf80a/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang/rust#121716.
My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives:
- We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es.
- I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here.
- For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched.
This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference.
This will conflict with rust-lang/rust#143376 and probably also rust-lang/rust#143028, so they shouldn't be merged at the same time.
r? `@matthewjasper` or `@Nadrieril`
Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
Rehome 21 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
Fix Box allocator drop elaboration
New version of rust-lang/rust#131146.
Clearing Box's drop flag after running its destructor can cause it to skip dropping its allocator, so just don't. Its cleared by the drop ladder code afterwards already.
Unlike the last PR this also handles other types with destructors properly, in the event that we can have open drops on them in the future (by partial initialization or DerefMove or something).
Finally, I also added tests for the interaction with async drop here but I discovered rust-lang/rust#143658, so one of the tests has a `knownbug` annotation. Not sure if it should be in this PR at all though.
Fixesrust-lang/rust#131082
r? wesleywiser - prev. reviewer
`tests/ui/issues/`: The Issues Strike Back [1/N]
I believe I’ve finally brought [my program](https://github.com/Kivooeo/test-manager) to life -- it now handles multiple test moves in one go: plain moves first, then a gentle touch on each file depends on given options. The process should be much smoother now.
Of course, I won’t rush through everything in a few days -- that would be unkind to `@Oneirical.` I’ll pace myself. And also I can't have more than one such PR because `issues.txt` will conflict with previous parts after merging them which is not fun as well.
This PR is just that: first commit - moves; second - regression comments and the occasional .stderr reblesses, also issue.txt and tidy changes. Nothing special, but progress nonetheless. This is for the purpose of preserving test file history during restructuring
Part of https://github.com/rust-lang/rust/issues/133895.
r? `@jieyouxu`
`tests/ui`: A New Order [28/28] FINAL PART
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
`tests/ui`: A New Order [25/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
Remove let_chains unstable feature
Per https://github.com/rust-lang/rust/issues/53667#issuecomment-3016742982 (but then I also noticed rust-lang/rust#140722)
This replaces the feature gate with a parser error that says let chains require 2024.
A lot of tests were using the unstable feature. I either added edition:2024 to the test or split out the parts that require 2024.
`tests/ui`: A New Order [11/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
add tests for pattern binding drop order edge cases
This adds tests for rust-lang/rust#142163, rust-lang/rust#142057, and rust-lang/rust#142056. I'm using these tests to help make sure I don't commit breaking changes when implementing match lowering for guard patterns, but I think it makes sense to add them separately. They don't directly have anything to do with guard patterns.
r? `@Nadrieril` or reassign
Add a new `mismatched-lifetime-syntaxes` lint
The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is:
- Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples:
```rust
// Lint will warn about these
fn(v: ContainsLifetime) -> ContainsLifetime<'_>;
fn(&'static u8) -> &u8;
```
- Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule:
```rust
// Lint will not warn about these
fn(&u8) -> &'_ u8;
fn(&'_ u8) -> &u8;
fn(&u8) -> ContainsLifetime<'_>;
```
- Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler.
---
This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
`tests/ui`: A New Order [4/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
r? ``@jieyouxu``
added stderr tag for commit which means it included generated stderr
