Rollup of 18 pull requests - #161488
Closed
JonathanBrouwer wants to merge 48 commits into
Closed
Conversation
The supposed output path was incorrect. Using `-Zdump-dep-graph` does NOT emit to `/tmp/dep_graph.gv`, but to 2 files, one being `dep_graph.txt` and the other `dep_graph.dot` in the current directory
This requires moving PanicPayload to alloc.
Canonical type-op queries discard NextGen constraints, so function-body failures never reached NLL. Evaluate those ops locally under -Zassumptions-on-binders and preserve the origin span on the resulting outlives constraints.
Keep this branch focused on reporting solver region constraints. The type-op behavior and its borrowck coverage are handled separately.
While this won't change much for rustc and rustc-dev, it should make codegen backends a bit smaller by omitting their crate metadata. In addition it should reduce disk usage while compiling.
Add some documentation for `rustc_type_ir` and `SolverDelegate`.
`from_immediate` calls left over from refactor d3d3485 can create invalid LLVM IR
… use symbolic links in `copy_link_internal`
These fields served to query the bitwidth for both and whether an integer is signed or not. The bitwith is now provided by `TypeId::bits` while the signedness can be gotten trough the earlier introduces `TypeId::is_signed`.
* Add Arc/Rc::strong_count_from_raw * Drop the global allocator requirement from strong_count_from_raw The clause came from increment_strong_count and decrement_strong_count, where it holds because those rebuild an Arc<T, Global> through from_raw_in and the decrement path frees through the global allocator. Reading the strong count never builds or drops one, and the allocator lives on the Arc rather than in the allocation, so it does not carry over. * std: refine docs for strong_count_from_raw
There seems to be very little reason to use Vec of bools, the whole map allocates space for every element anyway.
and force libRustOffload to use our LLVM submodule
The field is set from `llvm.offload-clang-dir` and only used in the offload build, so adjust accordingly.
Remove trivial bounds Panic on NaN Make assert messages consistent with field names Add clamp_to coretests Update to fmt style Use target_has_reliable_fN_math Change existing clamp tests to use reliable_math
…obzol bootstrap: (offload) be stricter about selected compiler and paths Disclaimer: I used an llm to implement the fixes, since I had more than enough fun with cmake in the past. I confirm that on a high-level these are the right fixes as far as I can tell, and I reviewed/refactored it. @sgasho and @Sa4dUs can you two please confirm that it doesn't break the build for you? Setup: I started building rustc on a server where cc was pointing to gcc 9, which is too old to build our llvm submodule. I managed to have gcc point to a newer gcc 13. I had to set all the cc/cxx etc. in bootstrap.toml to the path to our gcc 13, as it would otherwise pick the gcc 9. I also build myself clang-24 in a separate folder. There are unfortunately enough servers out there that default to ancient gcc's, so I think it's worth handling that and make offload bootstrap a bit stricter. Changes: Opennmp/Offload currently requires clang since they generate bitcode during bootstrap. Any older (or newer?) clang and especially gcc are unable to do so. We'll drop the bitcode generation soon, but add libc-for-gpu in a follow-up pr, which has effectively the same requirement, so it's worth fixing. We now derive the path to clang from either the explicit clang_dir which a user can pass if they have a pre-built clang, or (preferably) our submodule clang, if we build it ourselves. I first had an issue with bootstrap building `RustOffload-24`, since cmake found the external llvm-24 instead of our submodule with llvm-23, so that was obviously incompatible. I changed it to force the usage of our LLVM submodule. I also added code to make clang use the same `libstdc++` which we used when building our llvm submodule (so in my case, the one from gcc-13). Without the code, it picks the `libstdc++` from the (much older) system cc (9.4), which is incompatible and runs into glibcxx_assert. I _think_ this should be a strict improvement, and it fixes the 3 bugs I ran into. r? kobzol
…ering-dtors-in-fibers, r=ChrisDenton Avoid arming the Windows TLS destructor guard in fibers After rust-lang#157645, we use FLS to trigger destructors for thread locals. In bytecodealliance/wasmtime#14184, it turned out that there's an edge case we didn't cover: if `thread_local/guard/windows.rs::enable` is called from a fiber and later, in a different fiber: (1) the fiber is converted back to a thread and (2) the thread deletes the original fiber, we incorrectly triggers the FLS destructors prematurely. The fix is simple - avoid arming the FLS slot (setting it to 1) if the calling thread is a fiber. The issue happened on mingw because it does have target thread local. Tested locally by forcing `registered = false` and checked that the new test fails without the fix. r? @ChrisDenton
Add myself to mailmap
…use-data, r=folkertdev Use bitset for locals_with_use_data There seems to be very little reason to use Vec of bools, the whole map allocates space for every element anyway. Not sure how is impactful this is, I noticed it randomly in the code, but this seems like cleaner way to do it (and more common in the compiler codebase)
rustbot
added
A-LLVM
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 21, 2026
Rollup of 18 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple-1 try-job: aarch64-apple-2 try-job: x86_64-mingw-1 try-job: i686-msvc-1 try-job: i686-msvc-2
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #159318, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for ea6686c failed: CI. Failed jobs:
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
Successful merges:
Defaultimplementation forstd::sync::Once#160136 (AddDefaultimplementation forstd::sync::Once)rustc_type_ircomments #161444 (Add somerustc_type_ircomments)symlink_dirto create junctions on Windows instead of trying to use symbolic links incopy_link_internal#152433 (Usesymlink_dirto create junctions on Windows instead of trying to use symbolic links incopy_link_internal)-Zdump-dep-graph#159282 (Update documentation for-Zdump-dep-graph)Failed merges:
r? @ghost
Create a similar rollup