Do not move thread-locals before dropping
Fixesrust-lang/rust#140816. I also (potentially) improved the speed of `get_or_init` a bit by having an explicit hot/cold path.
We still move the value before dropping in the event of a recursive initialization (leading to double-initialization with one value being silently dropped). This is the old behavior, but changing this to panic instead would involve changing tests and also the other OS-specific `thread_local/os.rs` implementation, which is more than I'd like in this PR.
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 😓)
bootstrap: Remove `bin_root` from `PATH`
It's not currently load bearing in typical setups on typical targets.
Basically, if it passes the standard CI, then we can remove it, I think.
If someone later reports this breaking the build, then we can address it in a more fine grained way.
E.g. add it to `PATH` last and not first, only on specific targets, and only if specific files are not already found in `PATH` directories.
Fixes [#t-infra/bootstrap > Build broken in MSYS2 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Build.20broken.20in.20MSYS2/near/520709527)
Do not get proc_macro from the sysroot in rustc
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
add additional `TypeFlags` fast paths
Some crates, e.g. `diesel`, have items with a lot of where-clauses (more than 150). In these cases checking the `TypeFlags` of the whole `param_env` can be very beneficial.
This adds `fn fold_clauses` to mirror the existing `fn visit_clauses` and then uses this in folders which fold `ParamEnv`s.
Split out from rust-lang/rust#141451, depends on rust-lang/rust#141442.
r? `@compiler-errors`
This does not fully fix things, but it introduces a function that can be used to fix occurences.
When using `to_def` functionality, the input node needs to come from the macro expanded include, not the real file that was included.
This does unfortunately add more caller burden, but there is not really a way around it.
`concat_idents!` was deprecated in [1] and will be removed in the near
future. rust-analyzer's support is independent of rustc's, so drop RA
support now to make syncing easier.
[1]: https://github.com/rust-lang/rust/pull/137653
Implement `advance_by` via `try_fold` for `Sized` iterators
When `try_fold` is overriden, it is usually easier for compilers to optimize.
Example difference: https://iter.godbolt.org/z/z8cEfnKro
Use the fn_span when emitting function calls for better debug info.
This especially improves the developer experience for long chains of function calls that span multiple lines, which is common with builder patterns, chains of iterator/future combinators, etc.
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: arm-android
r? `@jieyouxu`
Update IDEs to use rustfmt 2024, fix Zed settings
Update IDEs to use rustfmt 2024, fix Zed settings
- Update IDE `rust-analyzer` settings to use 2024 rather than 2021.
- Fix Zed settings by removing `${workspaceFolder}/` from paths.
Fast path for processing some obligations in the new solver
Fast path applies to:
- Dyn compatibility predicates
- Region and type outlives predicates
- Trivially sized predicates
Emit a warning if the doctest `main` function will not be run
Fixes#140310.
I think we could try to go much further like adding a "link" (ie UI annotations) on the `main` function in the doctest. However that will require some more computation, not sure if it's worth it or not. Can still be done in a follow-up if we want it.
For now, this PR does two things:
1. Pass the `DiagCtxt` to the doctest parser to emit the warning.
2. Correctly generate the `Span` to where the doctest is starting (I hope the way I did it isn't too bad either...).
cc `@fmease`
r? `@notriddle`
