Allow specifying alignment for functions

[repnop]

Fixes #75072

This allows the user to specify alignment for functions, which can be useful for low level work where functions need to necessarily be aligned to a specific value.

I believe the error cases not covered in the match are caught earlier based on my testing so I had them just return None.

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[repnop]

Not sure how that submodule got added, but removed 🤔

[lcnr]

nominating for t-lang for now, I expect us to land this unstably first if we want to do so, but it does seem desirable to do so imo.

[joshtriplett]

This seems reasonable to me, to add on an unstable basis. (There needs to be a feature-gate added.)

I also think many codebases will want to set this for all functions using a compiler option (e.g. set in a Cargo profile). But supporting it on individual functions seems reasonable as well.

EDIT: We discussed this in today's lang-team meeting, and this was the general consensus:

• Please add a feature-gate (e.g. func_align)
• When this is merged, we'll need a tracking issue

[repnop]

Awesome! I should hopefully have some time soon to do that :)

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting, and we're in favor of adding this to nightly, for experimentation, as soon as there's a feature-gate added.

@rfcbot fcp merge
@rfcbot concern feature-gate

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

Concerns:

• feature-gate resolved by Allow specifying alignment for functions #81234 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[repnop]

I think I added all the requests, any other changes that need made?

[joshtriplett]

@rfcbot resolve feature-gate

Thank you!

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

☔ The latest upstream changes (presumably #82443) made this pull request unmergeable. Please resolve the merge conflicts.

[Havvy]

Shouldn't this be going through the RFC process?

[lcnr]

if ci passes, please squash your commits

after that r=me

@bors delegate+

[bors]

✌️ @repnop can now approve this pull request

[repnop]

@bors r=lcnr

[bors]

📌 Commit 448d076 has been approved by lcnr

[bors]

⌛ Testing commit 448d076 with merge a6e7a5a...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing a6e7a5a to master...

[RalfJung]

What are the language-level effects of this? Is this mainly a hint for how to put the compiled binary code together, or is his somehow observable inside Rust (e.g. by adding new kinds of UB)?

[repnop]

Is this mainly a hint for how to put the compiled binary code together

yes, its not intended to introduce any visible effects from within Rust, but to allow telling LLVM that the function needs to be aligned to a specific boundary for situations in which that's necessary and you can't rely on the native alignment placing it at an appropriate address (e.g. so it can be inserted into a hardware register, in my case)

by adding new kinds of UB

I think the only thing that may have been glossed over in this PR as it stands right now is being able to under-align functions, which I'll need to investigate to see if we need to add some additional checks to the #[repr(align(...))] as to not allow that to happen, or if LLVM will ignore the alignment hint and force it up to the native alignment since it would fulfill the request anyways (which seems like it may be the case? at least with some limited test in the playground)