Skip to content

Rollup of 14 pull requests #144261

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 72 commits into from
Closed

Conversation

jieyouxu
Copy link
Member

@jieyouxu jieyouxu commented Jul 21, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

beepster4096 and others added 30 commits July 8, 2025 20:00
Mistake in section serialization in rustc
From `#[align]` -> `#[rustc_align]`. Attributes starting with `rustc`
are always perma-unstable and feature-gated by `feature(rustc_attrs)`.

See regression RUST-143834.

For the underlying problem where even introducing new feature-gated
unstable built-in attributes can break user code such as

```rs
macro_rules! align {
    () => {
        /* .. */
    };
}

pub(crate) use align; // `use` here becomes ambiguous
```

refer to RUST-134963.

Since the `#[align]` attribute is still feature-gated by
`feature(fn_align)`, we can rename it as a mitigation. Note that
`#[rustc_align]` will obviously mean that current unstable user code
using `feature(fn_aling)` will need additionally `feature(rustc_attrs)`,
but this is a short-term mitigation to buy time, and is expected to be
changed to a better name with less collision potential.

See
<https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-07-17/near/529290371>
where mitigation options were considered.
ognevny and others added 15 commits July 21, 2025 15:47
...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some
intermediate steps fail due to path being relative to an active directory
gpu offload host code generation

r? ghost

This will generate most of the host side code to use llvm's offload feature.
The first PR will only handle automatic mem-transfers to and from the device.
So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch.
Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening.

A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU.
A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues.

I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work.
This work will also be compatible with std::autodiff, so one can differentiate GPU kernels.

Tracking:
- rust-lang#131513
…i-obk

Lower extra lifetimes before normal generic params.

Fixes rust-lang#143413
… r=oli-obk

Fix Box allocator drop elaboration

New version of rust-lang#131146.

Clearing Box's drop flag after running its destructor can cause it to skip dropping its allocator, so just don't. Its cleared by the drop ladder code afterwards already.

Unlike the last PR this also handles other types with destructors properly, in the event that we can have open drops on them in the future (by partial initialization or DerefMove or something).

Finally, I also added tests for the interaction with async drop here but I discovered rust-lang#143658, so one of the tests has a `knownbug` annotation. Not sure if it should be in this PR at all though.

Fixes rust-lang#131082

r? wesleywiser - prev. reviewer
Constify Try, From, TryFrom and relevant traits
…jieyouxu

Implement `check` for compiletest and RA using tool macro

Small cleanup to reduce the number of places that require custom check steps. Of course I had to include one mini hack because of Rust Analyzer.. but I think it's worth it here.

r? ``@jieyouxu``
rustc_public: de-StableMIR-ize

This PR updates relevant docs about StableMIR, basically just rewording StableMIR/SMIR to rustc_public/rustc_public's IR.

The README.md in the `rustc_public` crate is out-dated. I plan to rewrite it after we fork rustc_public into its own repository.

This PR doesn't change the fact that we still use `-Z unpretty=stable-mir` as a rustc parameter for printing the IR, since I feel it's a bit verbose and weird if we use `-Z unpretty=rustc-public-ir`. I was wondering if we can have a short and easy alias for rustc_public's IR.
clippy: make tests work in stage 1

This finally fixes rust-lang#78717 :)

Similar to what Miri already does, the clippy test step needs to carefully consider  which compiler is used to build clippy and which compiler is linked into clippy (and thus must be used to build the test dependencies). On top of that we have some extra complications that Miri avoided by using `cargo-miri` for building its test dependencies: we need cargo to use the right rustc and the right sysroot, but rust-lang/cargo#4423 makes this quite hard to do. See the long comment in `src/tools/clippy/tests/compile-test.rs` for details.

Some clippy tests tried to import rustc crates; that fundamentally requires a full bootstrap loop so it cannot work in stage 1. I had to kind of guess what those tests were doing so I don't know if my changes there make any sense.

Cc `@flip1995` `@Kobzol`
Mitigate `#[align]` name resolution ambiguity regression with a rename

Mitigates beta regression rust-lang#143834 after a beta backport.

### Background on the beta regression

The name resolution regression arises due to rust-lang#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as

```rs
macro_rules! align {
    () => {
        /* .. */
    };
}

pub(crate) use align; // `use` here becomes ambiguous
```

### Mitigation approach

This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:

1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.

This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).

### Alternative mitigation options

[Various mitigation options were considered during the compiler triage meeting](rust-lang#143834 (comment)), and those consideration are partly reproduced here:

- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
    - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
    - This avoids backing out a whole implementation.

### Review advice

This PR is best reviewed commit-by-commit.

- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.

This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.
…-obk

Add approval blocking labels for new bors

If a PR contains these labels, new bors won't let anyone approve it. We don't merge PRs using new bors yet, ofc, but I wanted to prepare this so that I don't forget about it.

This was proposed here: [#t-lang/meetings > Triage meeting 2025-07-23 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-07-23/near/529407150) and implemented [here](rust-lang/bors#367).

CC ``@RalfJung``

r? ``@oli-obk``
fix handling of base address for TypeId allocations

This fixes the problems discovered by ``@theemathas`` in rust-lang#142789:
- const-eval would sometimes consider TypeId pointers to be null
- the type ID is different in Miri than in regular executions

Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations).

r? ``@oli-obk``
…oli-obk

Remove the ptr_unique lang item

Miri no longer uses it since rust-lang/miri#4307.
Subtree update of `rust-analyzer`

r? `@ghost`
rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@cca2337.

Created using https://github.com/rust-lang/josh-sync.

r? `@ghost`
…obzol

opt-dist: make `artifact-dir` an absolute path for `opt-dist local`

...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some intermediate steps fail due to path being relative to an active directory

r? Kobzol

try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc F-autodiff `#![feature(autodiff)]` 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-clippy Relevant to the Clippy team. 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 Jul 21, 2025
@jieyouxu
Copy link
Member Author

I managed to miss the one PR I wanted to include...

@jieyouxu jieyouxu closed this Jul 21, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 21, 2025
@jieyouxu jieyouxu deleted the rollup-o2gijcn branch July 21, 2025 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc F-autodiff `#![feature(autodiff)]` rollup A PR which is a rollup T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-clippy Relevant to the Clippy team. 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.