Rollup of 19 pull requests - #161489
Open
JonathanBrouwer wants to merge 51 commits into
Open
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
…s as a note, not a label
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
Add `Default` implementation for `std::sync::Once`
resolver diagnostics: don't swallow labels and point out similar items as a note, not a label This was also swallowing labels from `diagnostic:on_unknown`; a typo suggestion would override it.
…they Improve the ABI between the panic runtime and libstd * Use the Rust ABI rather than C ABI * Mark some extern functions as safe * Move `PanicPayload` from libcore to liballoc and directly reference `Box<dyn Any>` instead of `*mut dyn Any` * Avoid an unnecessary allocation with panic=abort Follow up to rust-lang#160440
…nthey Add safety comments in alloc::Wtf8 This PR follow up rust-lang#160824 and add some safety section for unsafe APIs. This PR focus on Wtf8 in alloc and fix every `Untriged` mentioned in rust-lang#160824. Before this PR, rust-lang#161271 had add some safety sections for Wtf8 in core. I'm looking forward to your review and give me any feedback to improve this PR.
Add some `rustc_type_ir` comments This PR adds a few comments to `rustc_type_ir`, some of its key components, and `SolverDelegate`. These are the most important and common traits one encounters and some docs will be helpful. Most of it is coming from the prose in https://rustc-dev-guide.rust-lang.org/solve/sharing-crates-with-rust-analyzer.html
Remove leftover immediate creation `from_immediate` calls left over from refactor d3d3485 can create invalid LLVM IR
Use `symlink_dir` to create junctions on Windows instead of trying to use symbolic links in `copy_link_internal` Symbolic links require extra privileges on Windows, so this falls back to creating junctions in `symlink_file` when operating on a directory.
…om-raw, r=Mark-Simulacrum Add Arc/Rc::strong_count_from_raw Tracking issue: rust-lang#157021 Accepted ACP: rust-lang/libs-team#792 Adds `strong_count_from_raw` to `Arc` and `Rc`: read the strong count directly from a raw pointer, without reconstructing the smart pointer. The existing workaround is `ManuallyDrop::new(Arc::from_raw(ptr))` + `strong_count`, which takes ownership of a reference the caller doesn't own and could cause a double free if not using it properly, the detailed motivation of this in the ACP. This PR implements strong count only, libs-api deferred weak count until there's a concrete use case. The body reads the counter by walking back `data_offset` the way `from_raw_in` does, instead of materializing a temporary `Arc`/`Rc`, the call can't accidentally take ownership, and the `Relaxed` load matches `strong_count`. Lives next to `increment_strong_count`/`decrement_strong_count`. Safety doc: pointer to the value of a live allocation with valid metadata (feeds `data_offset`), such as pointer returned by `into_raw`, `into_raw_with_allocator`, `as_ptr`. `T` aligned like that value, strong count ≥ 1 for the duration of the call.
…h726 Update documentation for `-Zdump-dep-graph` 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 r? @jackh726 :: Because kinda related to Incremental Systems Rethought.
… r=oli-obk Remove fields from TypeKind: Bool, Char, Float and Int Tracking issue rust-lang#146922 r? @oli-obk Part of [Refactoring to many methods](https://rust-lang.zulipchat.com/#narrow/channel/572285-goals.2Freflection/topic/Refactoring.20to.20many.20methods/with/592226560) reflection subgoal. See that for the context.
…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
Contributor
|
⌛ Trying commit a36a1bd with merge 3ca8dda… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/32534767441 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 21, 2026
Rollup of 19 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
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
19 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