minor: Sync from downstream #19954
Merged
minor: Sync from downstream #19954
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
Subtree update of `rust-analyzer` r? `@ghost`
update llvm-tools logic for `dist` and `install` steps First commit aligns `build_steps::compile` and `build_steps::dist` logics for copying llvm-tools, and the second commit adds the correct `should_run` condition for `LlvmTools` step as the previous one was clearly incorrect. Fixes #140913
[win][ci] Update LLVM toolchain used to build LLVM to 20 While trying to get the aarch64-msvc build working correctly (#140136), I needed to update the version of LLVM used to build LLVM in Windows CI runners to 20 (as this has improved support for Arm64 and Arm64EC on Windows). This catches Windows up to Linux which was updated to 20 by #137189 try-job: `x86_64-apple-*` try-job: `aarch64-apple` try-job: `x86_64-msvc-*` try-job: `i686-msvc-*` try-job: `x86_64-mingw-*`
…rrors Match on lang item kind instead of using an if/else chain Similar to how the new solver does this. Just noticed while I was adding a new entry to the chain 😆
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`
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
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.
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`
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
Describe lifetime of call argument temporaries passed indirectly Fixes #132014.
Subtree update of `rust-analyzer` r? `@ghost`
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`
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.
Bump rustc-perf and update PGO crates Updates rustc-perf to rust-lang/rustc-perf@8158f78, and updates the crates. r? `@Kobzol`
Make some assertions in solver into debug assertions These may or may not be expensive :> r? lcnr
rustdoc: cleanups relating to allocations These commits generally clean up the code a bit and also reduce allocation rates a bit. r? `@camelid`
rustc_codegen_llvm: use `threadlocal.address` intrinsic to access TLS Fixes #136044 r? `@nikic`
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)
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 😓)
Revert "increase perf of charsearcher for single ascii characters" This reverts commit 245bf503e2a948ac98170516d11df632e85a948b (PR rust-lang/rust#141516). It caused a large `doc` perf. regression in rust-lang/rust#141605.
Do not move thread-locals before dropping Fixes rust-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.
…yUwU Avoid over-counting of `UsePath` in the HIR stats. Currently we over-count. Details in the individual commits. r? `@BoxyUwU`
tools-aux ci runner: also cross-test doctests in Miri Miri now supports running doctests across different targets. Let's use that to run the std doctests on aarch64-apple-darwin, i686-pc-windows-msvc. try-job: x86_64-gnu-aux
Subtree update of `rust-analyzer` r? `@ghost`
[rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id This allows consumers to create collections that required an ordering relationship for their keys—e.g. a `BTreeMap`.
Disable f64 minimum/maximum tests for arm 32 This disables the f64 minimum/maximum tests for the arm-unknown-linux-gnueabihf job. The next release will be supporting cross-compiled doctests, and these tests fail on that platform. It looks like this was just fixed via llvm/llvm-project#142170, but I assume that will not trickle down to our copy of llvm in the next couple of weeks. Assuming that does get fixed when llvm is updated, then these can be removed. cc rust-lang/rust#141087
Enable triagebot `[concern]` functionality Documentation at: https://forge.rust-lang.org/triagebot/concern.html Example at: rust-lang/triagebot#2024 r? Kobzol
…li-obk Decouple "reporting in deps" from `FutureIncompatibilityReason` The reason should just be it -- the reason. It never felt right to me that it was also responsible for whatever we include the warning in cargo's reports. It gets especially unruly if you want to add non-`FutureReleaseError*` warnings which are included in the reports. I just added a field to `FutureIncompatibleInfo` to control whatever the diagnostic is included in the cargo's reports.
move `test-float-parse` tool into `src/tools` dir Obviously `test-float-parse` is a tool like any other in `src/tools`. cc `@tgross35`
Rollup of 9 pull requests Successful merges: - rust-lang/rust#141554 (Improve documentation for codegen options) - rust-lang/rust#141817 (rustc_llvm: add Windows system libs only when cross-compiling from Wi…) - rust-lang/rust#141843 (Add `visit_id` to ast `Visitor`) - rust-lang/rust#141881 (Subtree update of `rust-analyzer`) - rust-lang/rust#141898 ([rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id) - rust-lang/rust#141921 (Disable f64 minimum/maximum tests for arm 32) - rust-lang/rust#141930 (Enable triagebot `[concern]` functionality) - rust-lang/rust#141936 (Decouple "reporting in deps" from `FutureIncompatibilityReason`) - rust-lang/rust#141949 (move `test-float-parse` tool into `src/tools` dir) r? `@ghost` `@rustbot` modify labels: rollup
…ers, r=saethlin bootstrap: build std sans leaf frame pointers Sometimes leaf frame-pointers can impact LLVM inlining choices, and that can be a real problem for things like `mul_add`.
Fix `create-docs-artifacts.sh` with new bors The slashes in the branch name (`automation/bors/try`) were causing issues for this script (https://github.com/rust-lang/rust/actions/runs/15391908130/job/43303193243). r? `@marcoieni` try-job: `mingw-check*`
bootstrap: Remove `rustc_snapshot_libdir` from PATH in one more place Same as rust-lang/rust#141657 but in a different part of the build system, with the same goal of addressing [#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). It seems to work on windows-{gnu,msvc} and linux-gnu at least. r? jieyouxu
Update stdarch submodule Updates the stdarch submodule. ## Merged PRs - rust-lang/stdarch#1797 - rust-lang/stdarch#1758 - rust-lang/stdarch#1798 - rust-lang/stdarch#1811 - rust-lang/stdarch#1810 - rust-lang/stdarch#1807 - rust-lang/stdarch#1806 - rust-lang/stdarch#1812 - rust-lang/stdarch#1795 - rust-lang/stdarch#1796 - rust-lang/stdarch#1813 - rust-lang/stdarch#1816 - rust-lang/stdarch#1818 - rust-lang/stdarch#1820 - rust-lang/stdarch#1819 r? `@Amanieu` `@rustbot` label T-libs-api Closes rust-lang/rust#111137
Move coroutine_by_move_body_def_id into the big check_crate body owner loop This avoids starting a parallel loop in sequence and instead runs all the queries for a specific DefId together.
Allow `#![doc(test(attr(..)))]` everywhere This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root. This is motivated by a recent PR #140323 (by ````@tgross35)```` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module): ```rust #![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))] #![doc(test(attr(expect(internal_features))))] ``` Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before). Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred. Best reviewed commit by commit. r? ````@GuillaumeGomez````
Document representation of `Option<unsafe fn()>` https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Option.20Layout.20with.20.60fn.60.20pointers/with/520055652
…raviscross Make the `dangerous_implicit_autorefs` lint deny-by-default I intended for the `dangerous_implicit_autorefs` lint to be deny-by-default, the [T-lang nomination comment](rust-lang/rust#123239 (comment)) even clearly mentioned deny-by-default, but somehow I and other missed that it is only warn-by-default. I think the lint should still be deny-by-default as the implicit aliasing requirements can be quite dangerous. In any-case, opening this PR for T-lang awareness. `@rustbot` label +I-lang-nominated +T-lang r? `@traviscross`
…cii_case, r=Mark-Simulacrum Stabilize `const_eq_ignore_ascii_case` Tracking issue: rust-lang/rust#131719 Closes rust-lang/rust#131719 FCP Completed: rust-lang/rust#131719 (comment)
Fix bootstrap tracing imports
…BoxyUwU Treat normalizing consts like normalizing types in deeply normalize ...so that we don't end up putting a top-level normalizes-to goal in the fulfillment context, which ICEs. This basically just models the normalize-const code off of the normalize-ty code above it, which uses an alias-relate goal instead. Fixes rust-lang/rust#140571 r? lcnr
…bjorn3 compiler: Sort and doc ExternAbi variants My personal brainworms found this ordering made the most sense while writing the CanonAbi PR. It is *an* ordering, at least, unlike the current mess. There has been no particular reason for the previous order ever since rust-lang/rust#136901, despite the comment I delete here. I just didn't change it. Because I feel weird just fussing with variant ordering in the source definition, I also documented a bunch to the best of my ability.
compiler: Treat ForceWarning as a Warning for diagnostic level This silences an ICE. No idea if this is the correct solution though tbh. Fixes rust-lang/rust#142144
get rid of spurious cfg(bootstrap) r? ```@oli-obk```
Rollup of 9 pull requests Successful merges: - rust-lang/rust#140560 (Allow `#![doc(test(attr(..)))]` everywhere) - rust-lang/rust#141447 (Document representation of `Option<unsafe fn()>`) - rust-lang/rust#141661 (Make the `dangerous_implicit_autorefs` lint deny-by-default) - rust-lang/rust#142065 (Stabilize `const_eq_ignore_ascii_case`) - rust-lang/rust#142116 (Fix bootstrap tracing imports) - rust-lang/rust#142126 (Treat normalizing consts like normalizing types in deeply normalize) - rust-lang/rust#142140 (compiler: Sort and doc ExternAbi variants) - rust-lang/rust#142148 (compiler: Treat ForceWarning as a Warning for diagnostic level) - rust-lang/rust#142154 (get rid of spurious cfg(bootstrap)) r? `@ghost` `@rustbot` modify labels: rollup
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixes rust-lang/rust#121429
Don't walk into `Certainty::Yes` goals Don't walk into `Certainty::Yes` goals in the pending obligation finding code, since they will not have been stalled on an infer var anyways
Filter out universals and lifetimes from `stalled_vars` lol r? lcnr
Simplify and optimize `VecCache`'s `SlotIndex::from_index` Simplify and optimize `SlotIndex::from_index` Break out bucket 0 (containing `idx < 4096`) as an early return, which simplifies the remainder of the function, and allows optimizing the `checked_ilog2` since it can no longer return `None`. This reduces the runtime of `vec_cache::tests::slot_index_exhaustive` (which calls `SlotIndex::from_index` for every `u32`, twice) from ~15.5s to ~13.3s. Separately, simplify the test case as well. (The old and new code passes with the old and new test case.) --- Noticed because `slot_index_exhaustive` stood out as taking unusually long compared to other tests, so I started investigating what it was doing.
Atomic intrinsics : use const generic ordering, part 2 This completes what got started in rust-lang/rust#141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new. Blocked on: - rust-lang/rust#141507 - rust-lang/rust#141687 - rust-lang/stdarch#1811 - rust-lang/rust#141964 r? `@bjorn3`
const-eval error: always say in which item the error occurred I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const. r? `@oli-obk`
…orkingjubilee Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions This adds back the `unsupported_calling_conventions` lint that was removed in rust-lang/rust#129935, in order to start the process of dealing with rust-lang/rust#137018. Specifically, we are going for the plan laid out [here](rust-lang/rust#137018 (comment)): - thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32 - vectorcall should only be accepted on x86-32 and x86-64 The difference to the status quo is that: - We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32) - We stop accepting cdecl on targets that are non-x86-32 - (There is no difference for thiscall, this was already a hard error on non-x86-32) - We stop accepting vectorcall on targets that are windows && non-x86-* Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred. try-job: i686-msvc-1 try-job: x86_64-msvc-1 try-job: test-various
rustbot
added
the
S-waiting-on-review
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.
No description provided.