Skip to content

Simplify polonius location-sensitive analysis #143093

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Aug 10, 2025

Conversation

lqd
Copy link
Member

@lqd lqd commented Jun 27, 2025

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, and amanda's SCCs rework 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.

@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 27, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 27, 2025

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

@rustbot

This comment was marked as resolved.

@lqd lqd force-pushed the polonius-pre-alpha branch from 09a0ec6 to 3d44596 Compare June 27, 2025 13:53
@jackh726
Copy link
Member

Happy to review, but don't expect it for 2 weeks :)

@bors

This comment was marked as resolved.

Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First thought: there are a bunch of really useful tests added here. I'd really like to see them added separately, covering nll, polonius-legacy, and polonius-next. You can use known-bug as appropriate.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 26, 2025
tgross35 added a commit to tgross35/rust that referenced this pull request Aug 7, 2025
Add a lot of NLL `known-bug` tests

r? `@jackh726`

As requested in rust-lang#143093 (review) this extracts most tests from that PR and expands upon them as described.

The handful of linked-list cursor-like tests will also turn into polonius=next known-bugs in rust-lang#143093 where the behavior w/r/t kills changes of course.
Zalathar added a commit to Zalathar/rust that referenced this pull request Aug 8, 2025
Add a lot of NLL `known-bug` tests

r? ``@jackh726``

As requested in rust-lang#143093 (review) this extracts most tests from that PR and expands upon them as described.

The handful of linked-list cursor-like tests will also turn into polonius=next known-bugs in rust-lang#143093 where the behavior w/r/t kills changes of course.
rust-timer added a commit that referenced this pull request Aug 8, 2025
Rollup merge of #145053 - lqd:known-bugs, r=jackh726

Add a lot of NLL `known-bug` tests

r? ``@jackh726``

As requested in #143093 (review) this extracts most tests from that PR and expands upon them as described.

The handful of linked-list cursor-like tests will also turn into polonius=next known-bugs in #143093 where the behavior w/r/t kills changes of course.
lqd added 2 commits August 8, 2025 14:10
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.
@lqd lqd force-pushed the polonius-pre-alpha branch 3 times, most recently from 9f959bd to 1e087f2 Compare August 8, 2025 14:59
lqd added 4 commits August 8, 2025 15:14
Remove incomplete handling of kills during traversal for loan liveness
to get to a simpler and actionable prototype.

This handles the cases, on sufficiently simple examples, that were
deferred from NLLs (NLL problem case 3, lending iterators), and is still
a good step to put in people's hands without needing to wait for another
full implementation. This is a practical cut in scope, but it also
shows where are the areas of improvement, that we will explore in the
future.
These are just some sanity checks to ensure NLLs, the polonius alpha
analysis, and the datalog implementation behave the same on these common
examples.
lqd added 3 commits August 8, 2025 15:14
This test showcases the same imprecision as NLLs, unlike the datalog
implementation, when using reachability as a liveness approximation.
This is an example similar to the linked-list cursor examples
where the alpha shows the same imprecision as NLLs, but that can work due to
the loans not being live after the loop, or the constraint graph being
simple enough that the cfg/subset relationships are the same for
reachability and liveness.
- linked-list cursor-like patterns
- issue-46589

These are known-bugs for the polonius alpha, where they show the same
imprecision as NLLs, but are supported by the old datalog
implementation.
@lqd lqd force-pushed the polonius-pre-alpha branch from 1e087f2 to b99fe2b Compare August 8, 2025 15:18
@lqd
Copy link
Member Author

lqd commented Aug 8, 2025

Rebased to remove and update the tests now that #145053 has landed.

github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Aug 9, 2025
Add a lot of NLL `known-bug` tests

r? ``@jackh726``

As requested in rust-lang/rust#143093 (review) this extracts most tests from that PR and expands upon them as described.

The handful of linked-list cursor-like tests will also turn into polonius=next known-bugs in rust-lang/rust#143093 where the behavior w/r/t kills changes of course.
@jackh726
Copy link
Member

jackh726 commented Aug 9, 2025

Seems good to me.

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 9, 2025

📌 Commit b99fe2b has been approved by jackh726

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 9, 2025
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.
bors added a commit that referenced this pull request Aug 10, 2025
Rollup of 19 pull requests

Successful merges:

 - #141624 (unstable-book: Add stubs for environment variables; document some of the important ones)
 - #143093 (Simplify polonius location-sensitive analysis)
 - #144402 (Stabilize loongarch32 inline asm)
 - #144403 (`tests/ui/issues/`: The Issues Strike Back [4/N])
 - #144544 (Start reporting future breakage for `ILL_FORMED_ATTRIBUTE_INPUT` in dependencies)
 - #144739 (Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc)
 - #145089 (Improve error output when a command fails in bootstrap)
 - #145112 ([win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC)
 - #145129 ([win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC)
 - #145130 (improve "Documentation problem" issue template.)
 - #145135 (Stabilize `duration_constructors_lite` feature)
 - #145145 (some `derive_more` refactors)
 - #145147 (rename `TraitRef::from_method` to `from_assoc`)
 - #145156 (Override custom Cargo `build-dir` in bootstrap)
 - #145160 (Change days-threshold to 28 in [behind-upstream])
 - #145162 (`{BTree,Hash}Map`: add "`Entry` API" section heading)
 - #145175 (Enable limit_rdylib_exports on Solaris)
 - #145187 (Fix an unstable feature comment that wasn't a doc comment)
 - #145191 (`suggest_borrow_generic_arg`: use the correct generic args)

r? `@ghost`
`@rustbot` modify labels: rollup
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.
bors added a commit that referenced this pull request Aug 10, 2025
Rollup of 18 pull requests

Successful merges:

 - #141624 (unstable-book: Add stubs for environment variables; document some of the important ones)
 - #143093 (Simplify polonius location-sensitive analysis)
 - #144402 (Stabilize loongarch32 inline asm)
 - #144403 (`tests/ui/issues/`: The Issues Strike Back [4/N])
 - #144739 (Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc)
 - #145089 (Improve error output when a command fails in bootstrap)
 - #145112 ([win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC)
 - #145129 ([win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC)
 - #145130 (improve "Documentation problem" issue template.)
 - #145135 (Stabilize `duration_constructors_lite` feature)
 - #145145 (some `derive_more` refactors)
 - #145147 (rename `TraitRef::from_method` to `from_assoc`)
 - #145156 (Override custom Cargo `build-dir` in bootstrap)
 - #145160 (Change days-threshold to 28 in [behind-upstream])
 - #145162 (`{BTree,Hash}Map`: add "`Entry` API" section heading)
 - #145175 (Enable limit_rdylib_exports on Solaris)
 - #145187 (Fix an unstable feature comment that wasn't a doc comment)
 - #145191 (`suggest_borrow_generic_arg`: use the correct generic args)

r? `@ghost`
`@rustbot` modify labels: rollup
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.
bors added a commit that referenced this pull request Aug 10, 2025
Rollup of 17 pull requests

Successful merges:

 - #141624 (unstable-book: Add stubs for environment variables; document some of the important ones)
 - #143093 (Simplify polonius location-sensitive analysis)
 - #144402 (Stabilize loongarch32 inline asm)
 - #144403 (`tests/ui/issues/`: The Issues Strike Back [4/N])
 - #144739 (Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc)
 - #145089 (Improve error output when a command fails in bootstrap)
 - #145112 ([win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC)
 - #145129 ([win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC)
 - #145130 (improve "Documentation problem" issue template.)
 - #145135 (Stabilize `duration_constructors_lite` feature)
 - #145145 (some `derive_more` refactors)
 - #145147 (rename `TraitRef::from_method` to `from_assoc`)
 - #145156 (Override custom Cargo `build-dir` in bootstrap)
 - #145160 (Change days-threshold to 28 in [behind-upstream])
 - #145162 (`{BTree,Hash}Map`: add "`Entry` API" section heading)
 - #145187 (Fix an unstable feature comment that wasn't a doc comment)
 - #145191 (`suggest_borrow_generic_arg`: use the correct generic args)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Aug 10, 2025
Rollup of 17 pull requests

Successful merges:

 - #141624 (unstable-book: Add stubs for environment variables; document some of the important ones)
 - #143093 (Simplify polonius location-sensitive analysis)
 - #144402 (Stabilize loongarch32 inline asm)
 - #144403 (`tests/ui/issues/`: The Issues Strike Back [4/N])
 - #144739 (Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc)
 - #145089 (Improve error output when a command fails in bootstrap)
 - #145112 ([win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC)
 - #145129 ([win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC)
 - #145130 (improve "Documentation problem" issue template.)
 - #145135 (Stabilize `duration_constructors_lite` feature)
 - #145145 (some `derive_more` refactors)
 - #145147 (rename `TraitRef::from_method` to `from_assoc`)
 - #145156 (Override custom Cargo `build-dir` in bootstrap)
 - #145160 (Change days-threshold to 28 in [behind-upstream])
 - #145162 (`{BTree,Hash}Map`: add "`Entry` API" section heading)
 - #145187 (Fix an unstable feature comment that wasn't a doc comment)
 - #145191 (`suggest_borrow_generic_arg`: use the correct generic args)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit e5b98a9 into rust-lang:master Aug 10, 2025
10 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 10, 2025
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.
@lqd lqd deleted the polonius-pre-alpha branch August 10, 2025 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: polonius: None in region infer with unconditional panic
4 participants