https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2025-07-21T16:54:28+00:00 2025-07-21T16:54:28+00:00 许杰友 Jieyou Xu (Joe) 39484203+jieyouxu@users.noreply.github.com 2025-07-21T16:54:28+00:00 urn:sha1:ef4a7fb1b7f398565a038c1eb84da30e53006599 Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression rust-lang/rust#143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to rust-lang/rust#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](https://github.com/rust-lang/rust/issues/143834#issuecomment-3084415277), 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. 2025-07-18T17:42:30+00:00 Jieyou Xu jieyouxu@outlook.com 2025-07-17T16:10:46+00:00 urn:sha1:69b71e44107b4905ec7ad84ccb3edf4f14b3df69 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. 2025-07-18T17:14:42+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-18T17:14:42+00:00 urn:sha1:61285e211bf3d323d2c5d649c99207c500cc0cc2 Distinguish delim kind to decide whether to emit unexpected closing delimiter Fixes #138401 2025-07-18T12:34:58+00:00 xizheyin xizheyin@smail.nju.edu.cn 2025-07-10T08:27:40+00:00 urn:sha1:181c1bda0ef33c36e59628de6dd5c6ddf95f599f Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn> 2025-07-18T02:27:52+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-07-18T02:27:52+00:00 urn:sha1:03734ae794443b435dd58e177b57d053fb06fad0 Port `#[coverage]` to the new attribute system r? ``````@jdonszelmann`````` 2025-07-17T10:06:26+00:00 Deadbeef ent3rm4n@gmail.com 2025-07-13T08:49:19+00:00 urn:sha1:69326878eeabb713e2d4a85215b87f18e498313c 2025-07-16T13:51:18+00:00 Sasha Pourcelot sasha.pourcelot@protonmail.com 2025-07-13T09:51:22+00:00 urn:sha1:4e054fc4c4809a3c1df60ea99077f4d662b79750 2025-07-15T11:42:55+00:00 bors bors@rust-lang.org 2025-07-15T11:42:55+00:00 urn:sha1:e27f16a499074ba9a87f7f7641d9f64c572863bc Rollup of 13 pull requests Successful merges: - rust-lang/rust#142301 (tests: Fix duplicated-path-in-error fail with musl) - rust-lang/rust#143630 (Drop `./x suggest`) - rust-lang/rust#143736 (Give all bytes of TypeId provenance) - rust-lang/rust#143752 (Don't panic if WASI_SDK_PATH not set when detecting compiler) - rust-lang/rust#143837 (Adjust `run_make_support::symbols` helpers) - rust-lang/rust#143878 (Port `#[pointee]` to the new attribute parsing infrastructure) - rust-lang/rust#143905 (Recover and suggest to use `;` to construct array type) - rust-lang/rust#143907 (core: make `str::split_at_unchecked()` inline) - rust-lang/rust#143910 (Add experimental `backtrace-trace-only` std feature) - rust-lang/rust#143927 (Preserve constness in trait objects up to hir ty lowering) - rust-lang/rust#143935 (rustc_type_ir/walk: move docstring to `TypeWalker` itself) - rust-lang/rust#143938 (Update books) - rust-lang/rust#143941 (update `cfg_select!` documentation) Failed merges: - rust-lang/rust#143926 (Remove deprecated fields in bootstrap) r? `@ghost` `@rustbot` modify labels: rollup 2025-07-15T10:52:44+00:00 Samuel Tardieu sam@rfc1149.net 2025-07-15T10:52:44+00:00 urn:sha1:010e3ef1137b313eb6aad8c4044b491b8b9f84dc update `cfg_select!` documentation tracking issue: https://github.com/rust-lang/rust/issues/115585 After rust-lang/rust#143461, and with an eye on a soon(ish) stabilization, I think the docs need some work. The existing text read more like a motivation for the feature existing to me, so I've tried to now be a bit more descriptive. Still, suggestions are very welcome. I also added a test for an empty `select! {}` because it's just the sort of thing that might break. r? ``@traviscross`` 2025-07-15T10:52:40+00:00 Samuel Tardieu sam@rfc1149.net 2025-07-15T10:52:40+00:00 urn:sha1:281990eb16494ca72fe81e6ebe225d3298baae1f Recover and suggest to use `;` to construct array type Fixes rust-lang/rust#143828 r? compiler