This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Co-authored-by: Travis Cross <tc@traviscross.com>
This commit breaks out the logic of placheolder rewriting
into its own preprocessing step.
The only functional change from this is that the preprocessing
step (where extra `r: 'static` constraints are added) is
performed upstream of Polonius legacy, finally affecting
Polonius. That is mostly a by-product, though.
Fix borrowck mentioning a name from an external macro we (deliberately) don't save
Most of the info is already in the title 🤷Closesrust-lang/rust#141764
Drive-by refactor: use `OnceCell` for the reverse region SCC graph
During region inference, the reverse SCC region graph is sometimes computed lazily. This changes the implementation for that from using an `Option` to a `OnceCell` which clearly communicates the intention and simplifies the code somewhat.
There shouldn't be any performance impact, except that this pulls the computation of the reverse SCC graph slightly later than before, and so may avoid computing it in some instances.
Note that this changes a mutable reference into an immutable (interior mutable) one.
Add fast path for maybe-initializedness in liveness
r? `@matthewjasper`
Correct me if I'm wrong Matthew, but my understanding is that
1. `MaybeInitializedPlaces` is currently eagerly computed, in `do_mir_borrowck`
2. but this data is only used in liveness
3. and `liveness::trace` actually only uses it for drop-liveness
This PR moves the computation to `liveness::trace` which looks to be its only use-site. We also add a fast path there, so that it's only computed by drop-liveness.
This is interesting because 1) liveness is only computed for relevant live locals, 2) drop-liveness is only computed for relevant live locals with >0 drop points; 0 is the common case from our benchmarks, as far as I can tell, so even just computing the entire data lazily helps.
It seems possible to also reduce the domain here, and speed up the analysis for the cases where it has to be computed -- so I've left a fixme for that, and may look into it soon.
(I've come upon this while doing implementation work for polonius, so don't be too enamored with possible wins: the goal is to reduce the eventual polonius overhead and make it more palatable 😓)
Only drop-liveness checks for maybe-initializedness of move paths, and
it does so only for the relevant live locals that have drop points.
This adds a fast path by computing this dataflow analysis only when checking for such
initializedness. This avoids this expensive computation for the common
case.
For example, it avoids computing initializedness for 20K locals in the
`cranelift-codegen` benchmark, it has 7K relevant live locals but none
with drop points. That saves 900ms on end-to-end compilation times.
Handle regions equivalent to 'static in non_local_bounds
`non_local_bounds` would only find non local bounds that strictly bound a given region, but it's possible that a local region is equated to 'static when showing a type referencing a locally bound lifetime, such as `dyn Any + 'a` in the tests added, is well-formed. In this case we should return 'static.
closes#122704closes#139004
Only prefer param-env candidates if they remain non-global after norm
Introduce `CandidateSource::GlobalParamEnv`, and dynamically compute the `CandidateSource` based on whether the predicate contains params *post-normalization*.
This code needs some cleanup and documentation. I'm just putting this up for review.
cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/179
r? lcnr
Separate dataflow analysis and results
`Analysis` gets put into `Results` with `EntryStates`, by `iterate_to_fixpoint`. This has two problems:
- `Results` is passed various places where only `Analysis` is needed.
- `EntryStates` is passed around mutably everywhere even though it is immutable.
This commit mostly separates `Analysis` from `Results` and fixes these two problems.
r? `@davidtwco`
`fn check_opaque_type_parameter_valid` defer error
Will be used in #139587 to silence opaque type errors if there are other borrowck failures. I think it can be merged separately.
r? `@compiler-errors`
Don't name variables from external macros in borrow errors.
This came up as part of the expansion of format_args. However, it's a more general problem (and now solution).
I noticed that this does change another test, moving out of fields in derives on packed struct. However, I think this is a better error simply because it used to refer to `other.0` which is an implementation detail which doesn't really make sense.
cc `@m-ou-se`
Decouple SCC annotations from SCCs
This rewires SCC annotations to have them be a separate, visitor-type data structure. It was broken out of #130227, which needed them to be able to remove unused annotations after computation without recomputing the SCCs themselves.
As a drive-by it also removes some redundant code from the hot loop in SCC construction for a performance improvement.
r? lcnr
This rewires SCC annotations to have them be a separate,
visitor-type data structure. It was broken out of #130227,
which needed them to be able to remove unused annotations
after computation without recomputing the SCCs themselves.
As a drive-by it also removes some redundant code from
the hot loop in SCC construction for a performance improvement.
Some drive-by housecleaning in `rustc_borrowck`
This commit picks up a few odd ends discovered during the work on #130227. It adds some documentation and renames a few methods with too generic names to describe what they actually do. It also adds some debug output that was helpful during bug hunting and generally cleans up a few things (for my values of "clean").
r? lcnr
Make #![feature(let_chains)] bootstrap conditional in compiler/
Let chains have been stabilized recently in #132833, so we can remove the gating from our uses in the compiler (as the compiler uses edition 2024).
This commit picks up a few odd ends discovered during the work on #130227.
It adds some documentation and renames a few methods with too generic names
to describe what they actually do. It also adds some debug output that was
helpful during bug hunting.
`Results` contains and `Analysis` and an `EntryStates`. The unfortunate
thing about this is that the analysis needs to be mutable everywhere
(`&mut Analysis`) which forces the `Results` to be mutable everywhere,
even though `EntryStates` is immutable everywhere.
To fix this, this commit renames `Results` as `AnalysisAndResults`,
renames `EntryStates` as `Results`, and separates the analysis and
results as much as possible. (`AnalysisAndResults` doesn't get much use,
it's mostly there to facilitate method chaining of
`iterate_to_fixpoint`.)
`Results` is immutable everywhere, which:
- is a bit clearer on how the data is used,
- avoids an unnecessary clone of entry states in
`locals_live_across_suspend_points`, and
- moves the results outside the `RefCell` in Formatter.
The commit also reformulates `ResultsHandle` as the generic `CowMut`,
which is simpler than `ResultsHandle` because it doesn't need the
`'tcx` lifetime and the trait bounds. It also which sits nicely
alongside the new use of `Cow` in `ResultsCursor`.
Use `is_lang_item` and `as_lang_item` instead of handrolling their logic
Various cleanups and deduplication. Most notably `if is_lang_item(foo, bar) {} else if is_lang_item...` chains are turned into matches. No behaviour changes intended beyond turning ICEs into fatal "lang item not found" errors
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
