Skip to content

Conversation

@JonathanBrouwer
Copy link
Contributor

@JonathanBrouwer JonathanBrouwer commented Dec 18, 2025

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GrigorenkoPV and others added 30 commits November 11, 2025 23:08
There are major questions remaining about the reentrancy that this
allows. It doesn't have any users on github outside of a single project
that uses it in a panic=abort project to show backtraces. It
can still be emulated through #[alloc_error_handler] or
set_alloc_error_hook depending on if you use the standard library or
not. And finally it makes it harder to do various improvements to the
allocator shim.
…o filtering

Reading the manifest doesn't work when running in the context of the
rust build system.
Using a defaulted `CodegenBackend` method that querying for zstd support should
automatically print a safe value of `false` on any backend that doesn't
specifically indicate the presence or absence of zstd.
Remove -Zoom=panic

There are major questions remaining about the reentrancy that this allows. It doesn't have any users on github outside of a single project that uses it in a panic=abort project to show backtraces. It can still be emulated through `#[alloc_error_handler]` or `set_alloc_error_hook` depending on if you use the standard library or not. And finally it makes it harder to do various improvements to the allocator shim.

With this PR the sole remaining symbol in the allocator shim that is not effectively emulating weak symbols is the symbol that prevents skipping the allocator shim on stable even when it would otherwise be empty because libstd + `#[global_allocator]` is used.

Closes rust-lang#43596
Fixes rust-lang#126683
Make `--print=backend-has-zstd` work by default on any backend

Using a defaulted `CodegenBackend` method that querying for zstd support should automatically print a safe value of `false` on any backend that doesn't specifically indicate the presence or absence of zstd.

This should fix the compiletest failures reported in rust-lang#149666 (comment), which can occur when LLVM is not the default codegen backend.
…elmann

Remove uses of `cfg({any()/all()})`

~~This implements the followup warning suggested in rust-lang/rfcs#3695
~~Lint against an empty `cfg(any/all)`, suggest the boolean literal equivalents.~~
rust-lang#149791 (comment)

Tracking issue: rust-lang#131204
Remove `[no-mentions]` handler in the triagebot config
Overhaul filename handling for cross-compiler consistency

This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).

This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang#148328).

In order to achieved consistency multiple steps are being taken by this PR:
 - by making `RealFileName` immutable
 - by only having `SourceMap::to_real_filename` create `RealFileName`
   - currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
 - by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
   - this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename

In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.

This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.

Unblocks rust-lang#147611
Fixes rust-lang#148328
* Add `llvm.x86.vcvtps2ph.128`

* `cargo fmt`

* Test `_mm_cvtps_ph`
…m, r=jdonszelmann

Simplify how inline asm handles `MaybeUninit`

This is just better, but this is also allows it to handle changes from rust-lang#149614 (i.e. `ManuallyDrop` containing `MaybeDangle`).
This synchronizes the list with the current state of `sysctl` on macOS “Tahoe” 26.2.


r? @Amanieu
Rustfmt used to be optional for nightlies long ago, but it is now
always present. Also rename rust-toolchain to rust-toolchain.toml.
… r=wesleywiser

Set -Cpanic=abort in windows-msvc stack protector tests

I ran into a test failure with the 32-bit windows test on rust-lang#117192, one of the tests has been incorrectly passing (until my change!) because it is picking up the stack protector from another function. I've tried to prevent that happening again by adding CHECK-DAGs for the start and end of each function.

I've also done my best to correct the comments, some were based on the fact that we used to run these tests with unwinding panics, but LLVM doesn't add protectors to function with SEH funclets so it's must more straightforward for these tests to use `-Cpanic=abort`.
…-branches, r=jdonszelmann

`cfg_select!`: parse unused branches

tracking issue: rust-lang#115585

Emit parse errors that are found in the branches that are not selected, like e.g. how `#[cfg(false)] { 1 ++ 2 }` still emits a parse error even though the expression is never used by the program. Parsing the unused branches was requested by T-lang rust-lang#149783 (comment).
…on, r=kobzol

Generate macro expansion for rust compiler crates docs

This enables the `--generate-macro-expansion` rustdoc flag, generating possibility to expand macros directly in source code pages (rust-lang#137229).

Needed this new feature when I was working on rust-lang#149919 and I thought "why not enable it by default?". So here we go.

Not too sure who to r? here so:

r? `@kobzol`
…r=petrochenkov

Support recursive delegation

This PR adds support for recursive delegations and is a part of the delegation feature rust-lang#118212.

r? `@petrochenkov`
std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features

This synchronizes the list with the current state of `sysctl` on macOS “Tahoe” 26.2.

r? `@Amanieu`
…ivooeo

tests/run-make-cargo/same-crate-name-and-macro-name: New regression test

Closes rust-lang#71259 which just **E-needs-test**. See rust-lang#71259 (comment) for a good description of what we should test (which we do in this PR).

The project we add fails with an old nightly without the fix:

```console
$ cargo +nightly-2020-03-10 run
   Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer)
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/consumer`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"version 1"`,
 right: `"version 2"`', src/main.rs:6:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

and passes with a recent toolchain:

```console
$ cargo run
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
   Compiling mylib v2.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2)
   Compiling mylib v1.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1)
   Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/consumer`
```

in other words, the test tests what it should and will catch regressions.
Fixed ICE for EII with multiple defaults due to duplicate definition in nameres

r? `@jieyouxu` (since you looked at the other one)

Fixes rust-lang#149982

Previously a [fix was proposed](rust-lang#149985) by `@SATVIKsynopsis` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR.

Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined.

Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption.

The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error.

Thanks to `@SATVIKsynopsis` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3
Also thanks to `@yaahc` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3

The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)
…enkov

unstable.rs: fix typos in comments (implementatble -> implementable)
…field_access, r=JonathanBrouwer

Port `#[rustc_lint_opt_deny_field_access]` to attribute parser

r? `@JonathanBrouwer`
…bjorn3

Subtree sync for rustc_codegen_cranelift

Nothing too exciting since the last sync.

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 18, 2025
@JonathanBrouwer
Copy link
Contributor Author

Made a larger rollup, the CI seems to be running ok for a bit, lets give it another try I suppose?

@bors r+ rollup=never p=1001

@bors
Copy link
Collaborator

bors commented Dec 18, 2025

📌 Commit ee56ef6 has been approved by JonathanBrouwer

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Dec 18, 2025

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 18, 2025
@bors
Copy link
Collaborator

bors commented Dec 18, 2025

⌛ Testing commit ee56ef6 with merge 567c266...

bors added a commit that referenced this pull request Dec 18, 2025
…uwer

Rollup of 11 pull requests

Successful merges:

 - #145933 (Expand `str_as_str` to more types)
 - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests)
 - #149925 (`cfg_select!`: parse unused branches)
 - #150022 (Generate macro expansion for rust compiler crates docs)
 - #150024 (Support recursive delegation)
 - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features)
 - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test)
 - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres)
 - #150124 (unstable.rs: fix typos in comments (implementatble -> implementable))
 - #150125 (Port `#[rustc_lint_opt_deny_field_access]` to attribute parser)
 - #150126 (Subtree sync for rustc_codegen_cranelift)

Failed merges:

 - #150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Collaborator

bors commented Dec 18, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 18, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 18, 2025
@rust-log-analyzer
Copy link
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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs rollup A PR which is a rollup T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.