Rollup of 12 pull requests#158570
Closed
jhpratt wants to merge 36 commits into
Closed
Conversation
Currently, rustc can emit a FatalError diagnostic during parsing of literals and tokenstreams. These are handled under the hood as a panic, which means that proc-macro code needed to catch_unwind if it wanted to fallibly parse some code. These still emit diagnostics, so in practice this isn't a full fix, but it at least makes the interface on the macro side a bit more uniform. This is primarily motivated by wasm proc macros which can't use catch_unwind and so this lets the test's output be the same with and without them.
* refactor: move attribute and keywords docs files to core * fix references to `std` * tidy fixes * ignore doc tests w/ explicit_tail_calls * revert `unsafe` example and ignore specifically WASM for `become` doc tests * add explicit note about doube including the docs in `core` and `std` * missed refactoring of doc test ignore * conditionally exclude doc-test containing threading for `wasm-wasip1` * Change exclusion to just `wasi` target_os Co-authored-by: Justin Schilleman <97192655+jschillem@users.noreply.github.com>
Before it would just show the `ensure` function
Sometimes it is necessary to group patchable function entrypoint records in distinct linker sections. This is the case for some bpf functions within the linux kernel which shouldn't be visible to ftrace. Extend `-Zpatchable-function-entry` to accept an argument of the form `prefix_nops,total_nops,record_section`, which places all entry record into a user specified section. Likewise, extend the `patchable_function_entry` attribute to accept an optional `section="name"` option to place a function into a specific section. This is made possible by llvm attribute `patchable-function-entry-section` added in llvm 21.
…ent into `PathSegment`
… r=kobzol,mark-simulacrum,bjorn3 bootstrap: fix panic when repo path contains spaces by switching to CARGO_ENCODED_RUSTFLAGS Fixes rust-lang#158052 Closes: rust-lang#156096 ## Problem `./x build` panics with a cryptic assertion error when the repository is checked out under a directory path containing spaces (e.g. `/Users/foo/Open Source/rust`): thread 'main' panicked at src/bootstrap/src/core/builder/cargo.rs:54:9: assertion left == right failed left: 2 right: 1 The root cause: when building tools in `ToolRustcPrivate` or `Codegen` mode, bootstrap calls `llvm-config --libdir` and passes the result as a `-Clink-arg=-L<path>` rustflag. The `Rustflags::arg()` method asserted that arguments contain no spaces, but if the repo path has a space the libdir path inherits it and the assertion fires. The error gives no hint that the path is the problem. A secondary bug: `llvm-config --libdir` output has a trailing newline that was previously stripped accidentally by `RUSTFLAGS` whitespace splitting. Nothing was trimming it explicitly. ## Fix Two changes in `src/bootstrap/src/core/builder/cargo.rs`: 1. **Switch `RUSTFLAGS` → `CARGO_ENCODED_RUSTFLAGS`**: Change `Rustflags` to store args as `Vec<String>` and join with `\x1f` (ASCII unit separator) when setting the env var. Cargo's `CARGO_ENCODED_RUSTFLAGS` (stable since Cargo 1.55) uses `\x1f` as delimiter, which never appears in filesystem paths, so paths with spaces are handled correctly. The space-based assertion in `arg()` is removed. 2. **Trim `llvm-config --libdir` output**: Explicitly `.trim()` the captured stdout so the trailing newline is not included in the linker search path. `RUSTDOCFLAGS` is left as-is (space-joined) since no llvm paths are added to rustdocflags. cc: @Kobzol
…, r=jieyouxu,bjorn3 Fix debuginfo compression in bootstrap Found through https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/weird.20code.20in.20fill_target_compiler/with/604588655. This PR solves a few issues with debuginfo compression in bootstrap. The main issue was that debuginfo compression through the `-gz` flag wasn't enabled, by mistake. When `cc-rs` checks if a compiler flag is supported, it tries to read `out_dir` to generate the source file in. However, when this option is not set, then the check silently fails and the flag is considered to be unsupported. Since we didn't set `out_dir`, all such added flags were simply ignored. Normally, it reads `OUT_DIR`, which is fine if `cc-rs` is used within a build script. But if it is used elsewhere, then this is a pretty gnarly footgun in `cc-rs`, because the failure is [completely silent](https://github.com/rust-lang/cc-rs/blob/main/src/lib.rs#L1483). CC @madsmtm or @NobodyXu in case you have thoughts on that :) After that was fixed, I had to change the used compression flag from `-gz` to `--compress-debug-sections`, to support both BFD and LLD linkers. And to solve it properly, and allow `dist` CI jobs to configure debuginfo compression for all targets that they build, I added a new bootstrap option to configure debuginfo compression. I wanted the flag to be configurable both globally and per target. At the same time, the flag applies both to C/C++ and Rust. We currently don't have such config area in `bootstrap.toml`, and `[build]` didn't seem like the right place, so I shoved it into `[rust]` (while documenting that it also applies to C/C++). r? @bjorn3
…g, r=bjorn3 Avoid parser panics bubbling out to proc macros Currently, rustc can emit a FatalError diagnostic during parsing of literals and tokenstreams. These are handled under the hood as a panic, which means that proc-macro code needed to catch_unwind if it wanted to fallibly parse some code. These still emit diagnostics, so in practice this isn't a full fix, but it at least makes the interface on the macro side a bit more uniform. The long-term fix should be to get rid of those FatalErrors (and in general all diagnostics that actually get emitted out during parsing, not just returned), but this seems like a reasonable improvement in the meantime. This is primarily motivated by wasm proc macros which can't use catch_unwind and so this lets the test's output be the same with and without them. r? bjorn3
…tem, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU
…e-ice, r=petrochenkov Avoid ICE when cfg_eval recovers no item from derive input Fixes rust-lang#148891 `cfg_eval` reparses derive input when it contains `#[cfg]` or `#[cfg_attr]` so it can capture cfg positions in the token stream. That reparse can emit syntax errors and return `Ok(None)` when parser recovery cannot reconstruct an item. This pr changes the reparse path to return `Option<Annotatable>` and fall back to the original annotatable when recovery produces no node.
…-perf, r=petrochenkov delegation: store child segment flag in `PathSegment` This should reduce [perf overhead](rust-lang#157960 (comment)) of checking whether path segment is a delegation's child segment. r? @petrochenkov
rust-bors
Bot
removed
the
S-waiting-on-review
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
Member
Author
|
@bors treeclosed=1 |
Contributor
|
Tree closed for PRs with priority less than 1. |
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jun 29, 2026
Rollup of 12 pull requests Successful merges: - #158073 (bootstrap: fix panic when repo path contains spaces by switching to CARGO_ENCODED_RUSTFLAGS) - #158169 (Fix debuginfo compression in bootstrap) - #158256 (Avoid parser panics bubbling out to proc macros) - #158375 (Support `DefKind::InlineConst` in `ConstKind::Unevaluated`) - #158417 (Avoid ICE when cfg_eval recovers no item from derive input) - #158556 (delegation: store child segment flag in `PathSegment`) - #158561 (Avoid building rustdoc for tests without doctests) - #158562 (Improve tracing of steps in bootstrap) - #157445 (Allow section override when using patchable-function-entries) - #158081 (trait-system: Recover deferred closure calls after errors) - #158327 (Move attribute and keyword docs from `std` to `core`) - #158468 (Include default-stability info in rustdoc JSON.)
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for 4bd48b9 failed: CI. Failed job:
|
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
rustbot
removed
the
S-waiting-on-review
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
This was referenced Jun 29, 2026
This was referenced Jun 29, 2026
Open
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
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.
Successful merges:
DefKind::InlineConstinConstKind::Unevaluated#158375 (SupportDefKind::InlineConstinConstKind::Unevaluated)PathSegment#158556 (delegation: store child segment flag inPathSegment)stdtocore#158327 (Move attribute and keyword docs fromstdtocore)r? @ghost
Create a similar rollup