Add edition checks for some tests that had divergent output #142255
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
estebank
force-pushed
the
edition-diagnostic-changes
branch
from
85c28a9 to
ce7480d
Compare
estebank
commented
Jun 9, 2025
Comment on lines
+1
to
+23
| error[E0657]: `impl Trait` cannot capture higher-ranked lifetime from outer `impl Trait` | ||
| --> $DIR/issue-54895.rs:18:40 | ||
| | | ||
| LL | fn f() -> impl for<'a> Trait<'a, Out = impl Sized + 'a> { | ||
| | ^^^^^^^^^^^^^^^ `impl Trait` implicitly captures all lifetimes in scope | ||
| | | ||
| note: lifetime declared here | ||
| --> $DIR/issue-54895.rs:18:20 | ||
| | | ||
| LL | fn f() -> impl for<'a> Trait<'a, Out = impl Sized + 'a> { | ||
| | ^^ | ||
|
|
||
| error[E0657]: `impl Trait` cannot capture higher-ranked lifetime from outer `impl Trait` | ||
| --> $DIR/issue-54895.rs:18:53 | ||
| | | ||
| LL | fn f() -> impl for<'a> Trait<'a, Out = impl Sized + 'a> { | ||
| | ^^ | ||
| | | ||
| note: lifetime declared here | ||
| --> $DIR/issue-54895.rs:18:20 | ||
| | | ||
| LL | fn f() -> impl for<'a> Trait<'a, Out = impl Sized + 'a> { | ||
| | ^^ |
There was a problem hiding this comment.
These duplicated errors are unfortunate and quite common throughout the test suite.
estebank
commented
Jun 9, 2025
Comment on lines
+4
to
+5
| LL | fn a<'a>() -> impl Fn(&'a u8) -> (impl Debug + '_) { | ||
| | -- this generic parameter must be used with a generic lifetime parameter |
There was a problem hiding this comment.
The last edition changes the span being pointed at in such a way that the wording should change (or get the span from previous editions back).
|
The parts about bare trait names in type position LGTM, but it would probably be better if someone else who knew about RPITs better to assess the changes in those tests r? compiler |
|
r? compiler |
WaffleLapkin
approved these changes
Jun 24, 2025
There was a problem hiding this comment.
Some diagnostics are bad, but that's a pre-existing issue. @estebank would you mind opening issues for the bad cases here?
This improves test coverage, which seems like a good idea.
Comment on lines
+1
to
+3
| //@revisions: edition2015 edition2021 | ||
| //@[edition2015] edition:2015 | ||
| //@[edition2021] edition:2021 |
There was a problem hiding this comment.
maybe we should have a shorthand for this 🤔
|
@bors r=fee1-dead,WaffleLapkin rollup |
bors
added
S-waiting-on-bors
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 25, 2025
…s, r=fee1-dead,WaffleLapkin Add edition checks for some tests that had divergent output In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while I was looking at something else.
This comment has been minimized.
This comment has been minimized.
|
This needs to be rebased and blessed. @bors r- |
bors
added
S-waiting-on-author
|
@bors rollup=iffy |
This comment has been minimized.
This comment has been minimized.
|
@bors r=fee1-dead,WaffleLapkin |
bors
added
S-waiting-on-bors
|
@bors p=5 |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 26, 2025
…s, r=fee1-dead,WaffleLapkin Add edition checks for some tests that had divergent output In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while I was looking at something else.
bors
added a commit
that referenced
this pull request
Jun 26, 2025
Rollup of 17 pull requests Successful merges: - #124595 (Suggest cloning `Arc` moved into closure) - #139594 (Simplify `ObligationCauseCode::IfExpression`) - #141311 (make `tidy-alphabetical` use a natural sort) - #141648 ([rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion) - #142255 (Add edition checks for some tests that had divergent output) - #142285 (tests: Do not run afoul of asm.validity.non-exhaustive in input-stats) - #142549 (small iter.intersperse.fold() optimization) - #142637 (Remove some glob imports from the type system) - #142647 ([perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation) - #142700 (Remove incorrect comments in `Weak`) - #142884 (StableMIR: Add method to retrieve body of coroutine) - #142925 (Rewrite `.gitattributes` CRLF ui tests into run-make tests) - #143001 (Rename run always ) - #143010 (Update `browser-ui-test` version to `0.20.7`) - #143015 (Add `sym::macro_pin` diagnostic item for `core::pin::pin!()`) - #143020 (codegen_fn_attrs: make comment more precise) - #143033 (Expand const-stabilized API links in relnotes) r? `@ghost` `@rustbot` modify labels: rollup
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 8f21a5c (parent) -> 3b9d04c (this PR) Test differencesShow 84 test diffsStage 1
Stage 2
Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 3b9d04c62f74b9be46c3ba56cf8393529aa81d26 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced Jun 26, 2025
|
Finished benchmarking commit (3b9d04c): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary 2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -9.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 691.142s -> 690.7s (-0.06%) |
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 10, 2025
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](rust-lang#139587), and [amanda's SCCs rework](rust-lang#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 rust-lang#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 fixes rust-lang#135646, a diagnostics ICE from the previous implementation.
rust-timer
added a commit
that referenced
this pull request
Aug 10, 2025
Rollup merge of #143093 - lqd:polonius-pre-alpha, r=jackh726 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](#139587), and [amanda's SCCs rework](#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 #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 fixes #135646, a diagnostics ICE from the previous implementation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to expose edition dependent divergences in some tests in the test suite, add explicit
editionannotations. Some of these tests might require additional work to avoid the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while I was looking at something else.