Rollup of 10 pull requests #144245
Closed
Rollup of 10 pull requests #144245
Conversation
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
triagebot welcome message for new users
Automatic Rustup
allow using different cargo binary
triagebot: tweak welcome message
Automatic Rustup
make native-lib support compile-time-optional, and centralize cfg usage
and ensure we don't unwind out of the "weird state" during tracing
move page protection logic inside native_lib
This test depends on the target-specific behavior of crt-static for musl targets. However, running the testsuite on a musl host requires setting `crt-static` to `false`, as it wouldn't otherwise be possible to build rustc. This in turn will enable `-Ctarget-feature=-crt-static` for all tests, mismatching the expected `+crt-static` for the musl target tested in this testcase. Since this test specifically tests the default value of `crt-static` for the musl target, ignoring it entirely makes more sense than manually setting `-Ctarget-feature=+crt-static` here, but both would be valid approaches. Signed-off-by: Jens Reidel <[email protected]>
…sion See RUST-143834.
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.
…ost) code generation
Automatic Rustup
make it configurable so users can set build.build-dir option in bootstrap.toml
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
…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`
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.
…=compiler-errors tests: Skip supported-crate-types test on musl hosts This test depends on the target-specific default of crt-static for musl targets. However, running the testsuite on a musl host requires setting `crt-static` to `false`, as it wouldn't otherwise be possible to build rustc. This in turn will enable `-Ctarget-feature=-crt-static` for all tests, mismatching the expected `+crt-static` for the musl target tested in this testcase. Since this test specifically tests the default value of `crt-static` for the musl target, ignoring it entirely makes more sense than manually setting `-Ctarget-feature=+crt-static` here, but both would be valid approaches.
opt-dist: change build_dir field to be an actual build dir make it configurable so users can set build.build-dir option in bootstrap.toml r? Kobzol try-job: dist-x86_64-msvc try-job: dist-x86_64-linux
…_impls, r=compiler-errors
Debug impls for DropElaborators
It's a little weird that these just have a completely empty Debug impl. Now they're `ElaborateDropsCtxt { .. }` and `DropShimElaborator { .. }`.
…-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`
Miri subtree update r? ``@ghost``
rustbot
added
A-attributes
|
Ugh I missed the other rollup |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
checkfor compiletest and RA using tool macro #143816 (Implementcheckfor compiletest and RA using tool macro)#[align]name resolution ambiguity regression with a rename #144080 (Mitigate#[align]name resolution ambiguity regression with a rename)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup