rustc-pull #1950
Merged
rustc-pull #1950
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
Automatic Rustup
./miri toolchain: no need to run 'cargo metadata'
re-balance CI jobs
Remove leaky synchronisation objects.
Automatic Rustup
Add tracing spans to borrow tracker functions
Add std::hint::spin_loop() to tests
minor: Sync from downstream
chore: Cleanup cargo config queries
examples: add `minimal_lsp.rs` and FIFO test script
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: b56aaec52bc0fa35591a872fb4aac81f606e265c Filtered ref: 12f5e3255df658296af9fc953d8c1ab79ba91ea3 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
Miscellaneous fixes for tracing
Add support for building and linking against genmc
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 733dab558992d902d6d17576de1da768094e2cf3 Filtered ref: 8f0faf94fb41d4e2a85ef2d23e5495f6bea1f31d This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
Fix gen panics doc template for debug_assert
fix: Do not require all rename definitions to be renameable
fix: In generate_mut_trait_impl, don't add a tabstop if the client does not support snippets
Improve settings tree title and descriptions
fix: When displaying a projection into a type parameter that has bounds as `impl Trait`, collect only the bounds of this projection
…_to_named_struct Migrate `convert_tuple_struct_to_named_struct` assist to use `SyntaxEditor`
…_syntax_editor Migrate `inline_type_alias` assist to use `syntax_editor`
Reorganize proc-macro-srv more, add `--format` and `--version` args
Perform check_private_in_public by module. Based on rust-lang/rust#116316
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@0c62c01. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
…ol,jieyouxu Ignore tests in `tests/ui/abi` for the GCC backend Needed for rust-lang/rust#146414. Currently we ignore them in the GCC backend and until this situation changes, it'll block rust-lang/rust#146414. r? `@Kobzol`
Mark float intrinsics with no preconditions as safe Note: for ease of reviewing, the list of safe intrinsics is sorted in the first commit, and then safe intrinsics are added in the second commit. All *recently added* float intrinsics have been correctly marked as safe to call due to the fact that they have no preconditions. This adds the remaining float intrinsics which are safe to call to the safe intrinsic list, and removes the unsafe blocks around their calls. --- Side note: this may want a try run before being added to the queue, since I'm not sure if there's any tier-2 code that uses these intrinsics that might not be tested on the usual PR flow. We've already uncovered a few places in subtrees that do this, and it's worth double-checking before clogging up the queue.
Rollup of 5 pull requests Successful merges: - rust-lang/rust#146795 (Enable `limit_rdylib_exports` on wasm targets) - rust-lang/rust#146828 (fix a crash in rustdoc merge finalize without input file) - rust-lang/rust#146848 (Add x86_64-unknown-motor (Motor OS) tier 3 target) - rust-lang/rust#146884 (Fix modification check of `rustdoc-json-types`) - rust-lang/rust#146887 (Remove unused #![feature(get_mut_unchecked)] in Rc and Arc examples) r? `@ghost` `@rustbot` modify labels: rollup
Add panic=immediate-abort MCP: rust-lang/compiler-team#909 This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts. In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`. The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large. `-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing. The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature. To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it. I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
…Urgau,davidtwco Extends AArch64 branch protection support to include GCS Extends existing support for AArch64 branch protection to include support for [Guarded Control Stacks](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022#guarded-control-stack-gcs:~:text=Extraction%20or%20tracking.-,Guarded%20Control%20Stack%20(GCS),-With%20the%202022).
Avoid invalidating CFG caches from MirPatch::apply. Small effort to reduce invalidating CFG caches.
Extended temporary argument to format_args!() in all cases Fixes rust-lang/rust#145880 by removing the special case.
…, r=Kobzol Make cargo test work for bootstrap self test This PR enables the bootstrap self-test to run via cargo test. I have removed the detect_src_and_out test for now, but it will be reintroduced in a follow-up PR where all bootstrap tests will be migrated to use testCtx. r? `@Kobzol` try-job: aarch64-apple
…uillaumeGomez,notriddle If a trait item appears in rustdoc search, hide the corrosponding impl items fixes rust-lang/rust#138251 cc `@notriddle`
…ono1, r=saethlin Fix normalization overflow ICEs in monomorphization Fixes rust-lang/rust#92004 Fixes rust-lang/rust#92470 Fixes rust-lang/rust#95134 Fixes rust-lang/rust#105275 Fixes rust-lang/rust#105937 Fixes rust-lang/rust#117696-2 Fixes rust-lang/rust#118590 Fixes rust-lang/rust#122823 Fixes rust-lang/rust#131342 Fixes rust-lang/rust#139659 ## Analysis: The causes of these issues are similar. They contain generic recursive functions that can be instantiated with different args infinitely at monomorphization stage. Ideally this should be caught by the [`check_recursion_limit`](https://github.com/rust-lang/rust/blob/c0bb3b98bb7aac24a37635e5d36d961e0b14f435/compiler/rustc_monomorphize/src/collector.rs#L468) function. The reality is that normalization can reach recursion limit earlier than monomorphization's check because they calculate depths in different ways. Since normalization is called everywhere, ICEs appear in different locations. ## Fix: If we abort on overflow with `TypingMode::PostAnalysis` in the trait solver, it would also catch these errors. The main challenge is providing good diagnostics for them. So it's quite natural to put the check right before these normalization happening. I first tried to check the whole MIR body's normalization and `references_error`. (As elaborate_drop handles normalization failure by [returning `ty::Error`](https://github.com/rust-lang/rust/blob/c0bb3b98bb7aac24a37635e5d36d961e0b14f435/compiler/rustc_mir_transform/src/elaborate_drop.rs#L514-L519).) It turns out that checking all `Local`s seems sufficient. These types are gonna be normalized anyway. So with cache, these checks shouldn't be expensive. This fixes these ICEs for both the next and old solver, though I'm not sure the change I made to the old solver is proper. Its overflow handling looks convoluted thus I didn't try to fix it more "upstream".
Offload host2 r? `@oli-obk` A follow-up to my previous gpu host PR. With this, I can (in theory) run a sufficiently simple Rust function on GPUs. I tested it on AMD, where the amdgcn tartget of rustc causes issues due to Addressspace castings, which might not be valid. If I (manually) fix them, I can run the generated IR on an AMD GPU. This should conceptually also work on NVIDIA or Intel. I updated the dev-guide acordingly: https://rustc-dev-guide.rust-lang.org/offload/usage.html I am unhappy with the amount of standalone functions in my offload code, so in my second commit I bundled some of the code around two structs which are Rust versions of the LLVM/Offload structs which they represent. The structs themselves only have doc comments. Since I directly lower everything to llvm-ir I didn't saw a big value in modelling the struct member variables.
rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.
Move wasm `throw` intrinsic back to `unwind` Fixes rust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner. r? `@bjorn3` --- rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function. rustc was taught to recognize this condition since rust-lang/rust#144225 and prevented such linkage, but this caused regressions in rust-lang/rust#148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std. The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.
Allow check builds with binaries for the dummy codegen backend This is likely the last part necessary for rust-lang/miri#4648. Miri needs to be able to do a regular check build for compile_fail doc tests to work.
Revert "Auto merge of #146186 - dpaoliello:cc, r=jieyouxu" This reverts rust-lang/rust#146186. This will mean regressing whichever `cc` fixes were needed for > fixes when compiling the Rust compiler for Arm64EC. It's not clear which `cc` change causes the across-the-board perf regression, I suspect it's a change in how certain compiler flags are handed. But I can immediately tell this is a rabbit hole to investigate, so let's revert for now to return-to-baseline and alleviate time pressure.
Adjust successor iterators. Because rust-lang/rust#148054 was a slight perf regression. The problem was seemingly because this iterator structure: ``` slice_iter.chain(Option_iter.chain(Option_iter)) ``` changed to this: ``` slice_iter.chain(Option_iter).chain(Option_iter) ``` The commit also tweaks the `slice_iter` part, changing `into_iter` to `iter` and using `[]` instead of `(&[])`, for conciseness and consistency. r? `@saethlin`
smart pointer (try_)map Tracking issue: rust-lang/rust#144419
Return `Option` from `exact_div` and inherit overflow checks According to rust-lang/rust#139911 (comment), `exact_div` should return `Option::None` if `self % rhs != 0`, panic if `rhs == 0`, and handle overflow conditionally (panic in debug, wrap in release). rust-lang/rust#147771 should rename `exact_div` to `div_exact`.
This updates the rust-version file to 73e6c9ebd9123154a196300ef58e30ec8928e74e.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 73e6c9ebd9123154a196300ef58e30ec8928e74e Filtered ref: e8bb3ca Upstream diff: rust-lang/rust@32e7a4b...73e6c9e This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
folkertdev
reviewed
Nov 2, 2025
Comment on lines
-176
to
-204
|
|
||
| unsafe extern "C-unwind" { | ||
| #[link_name = "llvm.wasm.throw"] | ||
| fn wasm_throw(tag: i32, ptr: *mut u8) -> !; | ||
| } | ||
|
|
||
| /// Generates the [`throw`] instruction from the [exception-handling proposal] for WASM. | ||
| /// | ||
| /// This function is unlikely to be stabilized until codegen backends have better support. | ||
| /// | ||
| /// [`throw`]: https://webassembly.github.io/exception-handling/core/syntax/instructions.html#syntax-instr-control | ||
| /// [exception-handling proposal]: https://github.com/WebAssembly/exception-handling | ||
| #[cfg_attr(test, assert_instr(throw, TAG = 0, ptr = core::ptr::null_mut()))] | ||
| #[inline] | ||
| #[unstable(feature = "wasm_exception_handling_intrinsics", issue = "122465")] | ||
| // FIXME: Since this instruction unwinds, `core` built with `-C panic=unwind` | ||
| // cannot be linked with `-C panic=abort` programs. But that's not | ||
| // entirely supported anyway, because runtimes without EH support won't | ||
| // be able to handle `try` blocks in `-C panic=unwind` crates either. | ||
| // We ship `-C panic=abort` `core`, so this doesn't affect users | ||
| // directly. Resolving this will likely require patching out both `try` | ||
| // and `throw` instructions, at which point we can look into whitelisting | ||
| // this function in the compiler to allow linking. | ||
| // See https://github.com/rust-lang/rust/issues/118168. | ||
| #[allow(ffi_unwind_calls)] | ||
| pub unsafe fn throw<const TAG: i32>(ptr: *mut u8) -> ! { | ||
| static_assert!(TAG == 0); // LLVM only supports tag 0 == C++ right now. | ||
| wasm_throw(TAG, ptr) | ||
| } |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
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.
Perform a pull, as it hasn't happened for a while.