rust/tests/ui/nll, branch lcnr/rustc-dev-guide

Point at the `Fn()` or `FnMut()` bound that coerced a closure, which caused a move error

2025-08-10T19:22:49+00:00

When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error. ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:15:25 | 14 | fn do_stuff(foo: Option) { | --- ----------- move occurs because `foo` has type `Option`, which does not implement the `Copy` trait | | | captured outer variable 15 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 16 | if foo.map_or(false, |f| f.foo()) { | --- variable moved due to use in coroutine | help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once --> f111.rs:12:53 | 12 | fn require_fn_trait>(_: impl Fn() -> F) {} | ^^^^^^^^^ help: consider cloning the value if the performance cost is acceptable | 16 | if foo.clone().map_or(false, |f| f.foo()) { | ++++++++ ```

Rollup merge of #143093 - lqd:polonius-pre-alpha, r=jackh726

2025-08-10T09:45:46+00:00

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 fixes rust-lang/rust#135646, a diagnostics ICE from the previous implementation.

Rollup merge of #145050 - lcnr:add-opaque-type-tests, r=lqd

2025-08-09T03:58:48+00:00

add member constraints tests taken from rust-lang/rust#139587.

mark polonius=next's NLL imprecisions as known-bugs

2025-08-08T15:15:09+00:00

- 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.

add cursor-like example that works

2025-08-08T15:14:51+00:00

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.

add NLL-like imprecision example

2025-08-08T15:14:51+00:00

This test showcases the same imprecision as NLLs, unlike the datalog implementation, when using reachability as a liveness approximation.

add some test cases for overlapping yielded items

2025-08-08T15:14:51+00:00

These are just some sanity checks to ensure NLLs, the polonius alpha analysis, and the datalog implementation behave the same on these common examples.

new impl fixes crash test

2025-08-08T15:14:51+00:00

add multiple known-bugs for the linked-list cursor-like pattern of 46859/48001

2025-08-07T13:33:35+00:00

these are fixed by polonius=legacy, are currently accepted by polonius=next but won't be by the alpha analysis

add filtering lending iterator known-bug

2025-08-07T13:06:35+00:00