Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

folkertdev
Copy link
Contributor

Tracking issue: #146177

#![feature(static_align)]

#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;

We need a different attribute than rustc_align because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as #[rustc_align].

r? @traviscross

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 3, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 3, 2025

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

@RalfJung
Copy link
Member

RalfJung commented Sep 3, 2025

we can't have two unstable features use the same unstable attribute

What do you mean by "use"? How does a feature "use" an attribute?
All rustc_ attributes are unstable anyway...

),
// FIXME(#82232, #143834): temporarily renamed to mitigate `#[align]` nameres ambiguity
gated!(rustc_align, Normal, template!(List: &["alignment"]), DuplicatesOk, EncodeCrossCrate::No, fn_align, experimental!(rustc_align)),
gated!(rustc_align_static, Normal, template!(List: &["alignment"]), DuplicatesOk, EncodeCrossCrate::No, static_align, experimental!(rustc_align_static)),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RalfJung this is where the attribute gets declared, and the feature name on this line (static_align in this case) must be unique

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's very odd, why does it have to be unique? That's not how features work anywhere else in the compiler, AFAIK.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, sorry, what I meant by unique is that an attribute must be tied to one unstable feature. #[rustc_align] is already tied to fn_align, so it can't also be used for static_align.

So, one unstable feature can "contain" multiple attributes, but an attribute always is tied to only one unstable feature.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, by "attribute used for feature" you mean "attribute is gated by feature". That's a rather confusing and non-standard way of saying things.^^

So what you want is to have a separate feature gate for aligning functions vs aligning statics, and the attribute registration macro isn't flexible enough to allow that. rustc_align is for functions only, despite its name sounding more general.

Since these are all temporary names anyway, I guess it doesn't matter too much, but when it comes to stabilization we very much might need the ability to stabilize an attribute in some positions while leaving it unstable elsewhere. Otherwise we have no way of unstably extending where an existing stable attribute can be used. So this limitation of attribute feature gating seems like it could become problematic. Cc @jdonszelmann

@Jules-Bertholet
Copy link
Contributor

This needs tests for:

  • Thread locals (#[thread_local] and thread_local!)
  • extern block statics

@rust-log-analyzer

This comment has been minimized.

@folkertdev
Copy link
Contributor Author

extern

Is there any interesting behavior to test here? (I'll add a test for the attribute being valid).

thread_local!

hmm, the thread_local! macro actually applies the attribute to a constant

($(#[$attr:meta])* $vis:vis $name:ident, $t:ty, $($init:tt)*) => {
$(#[$attr])* $vis const $name: $crate::thread::LocalKey<$t> =
$crate::thread::local_impl::thread_local_inner!(@key $t, $($init)*);
},

@traviscross traviscross changed the title implement #[rustc_align_static(N)] on statics Implement #[rustc_align_static(N)] on statics Sep 3, 2025
@traviscross traviscross added the F-static_align #![feature(static_align)] label Sep 3, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Jules-Bertholet
Copy link
Contributor

Here is an implementation for thread_local!: Jules-Bertholet@ad038e6

@rustbot
Copy link
Collaborator

rustbot commented Sep 5, 2025

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

@rust-log-analyzer

This comment has been minimized.

@folkertdev
Copy link
Contributor Author

That's odd, the miri tests pass for me locally. Do those somehow cache the standard library even when you don't pass --keep-stage?

@RalfJung
Copy link
Member

RalfJung commented Sep 5, 2025

Miri has its own standard library build but it should usually be recompiled automatically when anything changed.

@RalfJung
Copy link
Member

RalfJung commented Sep 5, 2025

The error might only occur after merging the branch with latest master (which happens implicitly in CI).

@Jules-Bertholet
Copy link
Contributor

Jules-Bertholet commented Sep 5, 2025

which happens implicitly in CI

Doesn’t that apply only to Bors CI? (E.g. Bors try or Bors r+)

@jdonszelmann
Copy link
Contributor

some minor questions: @rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 9, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 9, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
@folkertdev
Copy link
Contributor Author

so it's not entirely clear to me why this is a different attribute from fn_align. I guess it's cause fn align is much further in its stabilization etc. But these feel like the same feature to me. At the risk of bikeshedding, maybe we should rename both to rustc_item_align or something like that?

Keeping them separate seemed most flexible in terms of what/how to stabilize. What we'll do exactly is a bit up in the air, pending a path forward for making #[align] a builtin attribute. Just making that change causes ecosystem breakage, and properly performing name resolution on builtin attributes will require an edition bump.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 9, 2025
@jdonszelmann
Copy link
Contributor

@bors r=jdonszelmann,ralfjung

@bors
Copy link
Collaborator

bors commented Sep 9, 2025

📌 Commit cbacd00 has been approved by jdonszelmann,ralfjung

It is now in the queue for this repository.

@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 Sep 9, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 10, 2025
…lmann,ralfjung

Implement `#[rustc_align_static(N)]` on `static`s

Tracking issue: rust-lang#146177

```rust
#![feature(static_align)]

#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```

We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.

r? `@traviscross`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 10, 2025
…lmann,ralfjung

Implement `#[rustc_align_static(N)]` on `static`s

Tracking issue: rust-lang#146177

```rust
#![feature(static_align)]

#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```

We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.

r? ``@traviscross``
@traviscross
Copy link
Contributor

@bors r=jdonszelmann,ralfjung,traviscross

@bors
Copy link
Collaborator

bors commented Sep 10, 2025

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Collaborator

bors commented Sep 10, 2025

📌 Commit cbacd00 has been approved by jdonszelmann,ralfjung,traviscross

It is now in the queue for this repository.

@RalfJung
Copy link
Member

Keeping them separate seemed most flexible in terms of what/how to stabilize. What we'll do exactly is a bit up in the air, pending a path forward for making #[align] a builtin attribute. Just making that change causes ecosystem breakage, and properly performing name resolution on builtin attributes will require an edition bump.

Note that a stabilization PR should just swap the feature gate, not rename anything. (That makes it easier to review, easier to revert, and ensures the thing we had on nightly is actually what we are stabilizing.) So if in the stable form, the attributes should have the same name, then that rename should happen separately from stabilization.

But IIUC, in this case the name itself is still subject to bikeshedding.

bors added a commit that referenced this pull request Sep 10, 2025
Rollup of 6 pull requests

Successful merges:

 - #144765 (inclusive `Range`s: change `end` to `last`)
 - #145177 (std: move `thread` into `sys`)
 - #146178 (Implement `#[rustc_align_static(N)]` on `static`s)
 - #146368 (CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits)
 - #146378 (Update wasm-component-ld to 0.5.17)
 - #146391 (Trim paths less in MIR dumping)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Sep 10, 2025
Rollup of 5 pull requests

Successful merges:

 - #144765 (inclusive `Range`s: change `end` to `last`)
 - #146178 (Implement `#[rustc_align_static(N)]` on `static`s)
 - #146368 (CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits)
 - #146378 (Update wasm-component-ld to 0.5.17)
 - #146391 (Trim paths less in MIR dumping)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Sep 10, 2025
Rollup of 5 pull requests

Successful merges:

 - #144765 (inclusive `Range`s: change `end` to `last`)
 - #146178 (Implement `#[rustc_align_static(N)]` on `static`s)
 - #146368 (CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits)
 - #146378 (Update wasm-component-ld to 0.5.17)
 - #146391 (Trim paths less in MIR dumping)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 422c76a into rust-lang:master Sep 10, 2025
10 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Sep 10, 2025
rust-timer added a commit that referenced this pull request Sep 10, 2025
Rollup merge of #146178 - folkertdev:static-align, r=jdonszelmann,ralfjung,traviscross

Implement `#[rustc_align_static(N)]` on `static`s

Tracking issue: #146177

```rust
#![feature(static_align)]

#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```

We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.

r? `@traviscross`
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Sep 11, 2025
Rollup of 5 pull requests

Successful merges:

 - rust-lang/rust#144765 (inclusive `Range`s: change `end` to `last`)
 - rust-lang/rust#146178 (Implement `#[rustc_align_static(N)]` on `static`s)
 - rust-lang/rust#146368 (CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits)
 - rust-lang/rust#146378 (Update wasm-component-ld to 0.5.17)
 - rust-lang/rust#146391 (Trim paths less in MIR dumping)

r? `@ghost`
`@rustbot` modify labels: rollup
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. F-static_align #![feature(static_align)] I-lang-radar Items that are on lang's radar and will need eventual work or consideration. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants