Stabilize `#[optimize]` attribute by veluca93 · Pull Request #2278 · rust-lang/reference

veluca93 · 2026-06-01T19:34:54Z

@nagisa

This commit stabilizes the `#[optimize]` attribute, which allows for more fine-grained control of optimization levels. Tracking issue: rust-lang#54882 Reference PRs: rust-lang/reference#2278 cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler > Describe each behavior being stabilized and give a short example of code that will now be accepted. ```rust // Instructs the optimization pipeline to prioritize smaller code size over speed. pub fn binary_size_sensitive() { // ... } // Instructs the optimization pipeline to prioritize execution speed over code size. pub fn performance_critical() { // ... } // Disables optimizations entirely for this item. pub fn debug_only() { // ... } ``` We might want to allow specifying a per-function optimization level (i.e. `#[optimize(level = 3)]`). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet). Applying the attribute on a module level is also not implemented yet. - Description of the new attribute: rust-lang/reference#2278 - https://rust-lang.github.io/rfcs/2412-optimize-attr.html - Should we also implement optimize(always)? optimize(level=x)? Not yet. - Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item). Not yet. The `optimize(none)` variant was added. The variants above were discussed here: rust-lang#54882 (comment) - `#[optimize(none)]` implies `#[inline(never)]` to be effective (rust-lang#136329) - As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: rust-lang#54882 (comment) - Applying the attribute to incompatible items emits an error: rust-lang#128458 The standard library itself uses this attribute in a few places - Wiring it up to the llvm codegen backend: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/compiler/rustc_codegen_llvm/src/attributes.rs#L416 - Catching usage on incompatible items: rust-lang#128458 - Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs - Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs Trivial changes to rust-analyzer to support the new attribute as an inert attribute (part of this PR). As far as the AM is concerned, this attribute doesn't exist. Most of the work was not done by me, I'm just writing the stabilization report :-) @nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.

ehuss

There are a few other things that need updating:

Update the list of allowed attributes on functions in items/functions.md.
Add to the list of builtin attributes.

View changes since this review

@nagisa

…eywiser Stabilize `optimize` attribute This commit stabilizes the `#[optimize]` attribute, which allows for more fine-grained control of optimization levels. # Stabilization report ## Summary Tracking issue: rust-lang#54882 Reference PRs: rust-lang/reference#2278 cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler ### What is stabilized ```rust // Instructs the optimization pipeline to prioritize smaller code size over speed. #[optimize(size)] pub fn binary_size_sensitive() { // ... } // Instructs the optimization pipeline to prioritize execution speed over code size. #[optimize(speed)] pub fn performance_critical() { // ... } // Disables optimizations entirely for this item. #[optimize(none)] pub fn debug_only() { // ... } ``` ### What isn't stabilized We might want to allow specifying a per-function optimization level (i.e. `#[optimize(level = 3)]`). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet). Applying the attribute on a module level is also not implemented yet. ## Design ### Reference - Description of the new attribute: rust-lang/reference#2278 ### RFC history - https://rust-lang.github.io/rfcs/2412-optimize-attr.html ### Answers to unresolved question - Should we also implement optimize(always)? optimize(level=x)? Not yet. - Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item). Not yet. ### Post-RFC changes The `optimize(none)` variant was added. The variants above were discussed here: rust-lang#54882 (comment) ### Key points - `#[optimize(none)]` implies `#[inline(never)]` to be effective (rust-lang#136329) - As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: rust-lang#54882 (comment) - Applying the attribute to incompatible items emits an error: rust-lang#128458 ### Nightly uses The standard library itself uses this attribute in a few places ## Implementation ### Major part - Wiring it up to the llvm codegen backend: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/compiler/rustc_codegen_llvm/src/attributes.rs#L416 - Catching usage on incompatible items: rust-lang#128458 - Implementing `optimize(none)`: rust-lang#128657 rust-lang#136358 (includes disabling MIR opts) ### Coverage - Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs - Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs ### Tool changes Trivial changes to rust-analyzer to support the new attribute as an inert attribute: rust-lang/rust-analyzer#22511 ## Type system, opsem ### Breaks the AM? As far as the AM is concerned, this attribute doesn't exist. ## Acknowledgments Most of the work was not done by me, I'm just writing the stabilization report :-) @nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.   > [!NOTE] > # Concerns (0 active) > > - ~~[are-we-happy-wiht-capability-and-scope-of-this-attribute](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > - ~~[meaning-of-optimize-size](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > - ~~[explicitly-decide-on-effect-on-nested-functions](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@nagisa

…eywiser Stabilize `optimize` attribute This commit stabilizes the `#[optimize]` attribute, which allows for more fine-grained control of optimization levels. # Stabilization report ## Summary Tracking issue: rust-lang#54882 Reference PRs: rust-lang/reference#2278 cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler ### What is stabilized ```rust // Instructs the optimization pipeline to prioritize smaller code size over speed. #[optimize(size)] pub fn binary_size_sensitive() { // ... } // Instructs the optimization pipeline to prioritize execution speed over code size. #[optimize(speed)] pub fn performance_critical() { // ... } // Disables optimizations entirely for this item. #[optimize(none)] pub fn debug_only() { // ... } ``` ### What isn't stabilized We might want to allow specifying a per-function optimization level (i.e. `#[optimize(level = 3)]`). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet). Applying the attribute on a module level is also not implemented yet. ## Design ### Reference - Description of the new attribute: rust-lang/reference#2278 ### RFC history - https://rust-lang.github.io/rfcs/2412-optimize-attr.html ### Answers to unresolved question - Should we also implement optimize(always)? optimize(level=x)? Not yet. - Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item). Not yet. ### Post-RFC changes The `optimize(none)` variant was added. The variants above were discussed here: rust-lang#54882 (comment) ### Key points - `#[optimize(none)]` implies `#[inline(never)]` to be effective (rust-lang#136329) - As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: rust-lang#54882 (comment) - Applying the attribute to incompatible items emits an error: rust-lang#128458 ### Nightly uses The standard library itself uses this attribute in a few places ## Implementation ### Major part - Wiring it up to the llvm codegen backend: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/compiler/rustc_codegen_llvm/src/attributes.rs#L416 - Catching usage on incompatible items: rust-lang#128458 - Implementing `optimize(none)`: rust-lang#128657 rust-lang#136358 (includes disabling MIR opts) ### Coverage - Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs - Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs ### Tool changes Trivial changes to rust-analyzer to support the new attribute as an inert attribute: rust-lang/rust-analyzer#22511 ## Type system, opsem ### Breaks the AM? As far as the AM is concerned, this attribute doesn't exist. ## Acknowledgments Most of the work was not done by me, I'm just writing the stabilization report :-) @nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.   > [!NOTE] > # Concerns (0 active) > > - ~~[are-we-happy-wiht-capability-and-scope-of-this-attribute](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > - ~~[meaning-of-optimize-size](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > - ~~[explicitly-decide-on-effect-on-nested-functions](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@nagisa

…eywiser Stabilize `optimize` attribute This commit stabilizes the `#[optimize]` attribute, which allows for more fine-grained control of optimization levels. # Stabilization report ## Summary Tracking issue: rust-lang#54882 Reference PRs: rust-lang/reference#2278 cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler ### What is stabilized ```rust // Instructs the optimization pipeline to prioritize smaller code size over speed. #[optimize(size)] pub fn binary_size_sensitive() { // ... } // Instructs the optimization pipeline to prioritize execution speed over code size. #[optimize(speed)] pub fn performance_critical() { // ... } // Disables optimizations entirely for this item. #[optimize(none)] pub fn debug_only() { // ... } ``` ### What isn't stabilized We might want to allow specifying a per-function optimization level (i.e. `#[optimize(level = 3)]`). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet). Applying the attribute on a module level is also not implemented yet. ## Design ### Reference - Description of the new attribute: rust-lang/reference#2278 ### RFC history - https://rust-lang.github.io/rfcs/2412-optimize-attr.html ### Answers to unresolved question - Should we also implement optimize(always)? optimize(level=x)? Not yet. - Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item). Not yet. ### Post-RFC changes The `optimize(none)` variant was added. The variants above were discussed here: rust-lang#54882 (comment) ### Key points - `#[optimize(none)]` implies `#[inline(never)]` to be effective (rust-lang#136329) - As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: rust-lang#54882 (comment) - Applying the attribute to incompatible items emits an error: rust-lang#128458 ### Nightly uses The standard library itself uses this attribute in a few places ## Implementation ### Major part - Wiring it up to the llvm codegen backend: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/compiler/rustc_codegen_llvm/src/attributes.rs#L416 - Catching usage on incompatible items: rust-lang#128458 - Implementing `optimize(none)`: rust-lang#128657 rust-lang#136358 (includes disabling MIR opts) ### Coverage - Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs - Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs ### Tool changes Trivial changes to rust-analyzer to support the new attribute as an inert attribute: rust-lang/rust-analyzer#22511 ## Type system, opsem ### Breaks the AM? As far as the AM is concerned, this attribute doesn't exist. ## Acknowledgments Most of the work was not done by me, I'm just writing the stabilization report :-) @nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.   > [!NOTE] > # Concerns (0 active) > > - ~~[are-we-happy-wiht-capability-and-scope-of-this-attribute](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > - ~~[meaning-of-optimize-size](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > - ~~[explicitly-decide-on-effect-on-nested-functions](rust-lang#157273 (comment) resolved in [this comment](rust-lang#157273 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@nagisa

Rollup merge of #157273 - veluca93:optimize-attribte, r=wesleywiser Stabilize `optimize` attribute This commit stabilizes the `#[optimize]` attribute, which allows for more fine-grained control of optimization levels. # Stabilization report ## Summary Tracking issue: #54882 Reference PRs: rust-lang/reference#2278 cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler ### What is stabilized ```rust // Instructs the optimization pipeline to prioritize smaller code size over speed. #[optimize(size)] pub fn binary_size_sensitive() { // ... } // Instructs the optimization pipeline to prioritize execution speed over code size. #[optimize(speed)] pub fn performance_critical() { // ... } // Disables optimizations entirely for this item. #[optimize(none)] pub fn debug_only() { // ... } ``` ### What isn't stabilized We might want to allow specifying a per-function optimization level (i.e. `#[optimize(level = 3)]`). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet). Applying the attribute on a module level is also not implemented yet. ## Design ### Reference - Description of the new attribute: rust-lang/reference#2278 ### RFC history - https://rust-lang.github.io/rfcs/2412-optimize-attr.html ### Answers to unresolved question - Should we also implement optimize(always)? optimize(level=x)? Not yet. - Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item). Not yet. ### Post-RFC changes The `optimize(none)` variant was added. The variants above were discussed here: #54882 (comment) ### Key points - `#[optimize(none)]` implies `#[inline(never)]` to be effective (#136329) - As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: #54882 (comment) - Applying the attribute to incompatible items emits an error: #128458 ### Nightly uses The standard library itself uses this attribute in a few places ## Implementation ### Major part - Wiring it up to the llvm codegen backend: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/compiler/rustc_codegen_llvm/src/attributes.rs#L416 - Catching usage on incompatible items: #128458 - Implementing `optimize(none)`: #128657 #136358 (includes disabling MIR opts) ### Coverage - Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs - Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs ### Tool changes Trivial changes to rust-analyzer to support the new attribute as an inert attribute: rust-lang/rust-analyzer#22511 ## Type system, opsem ### Breaks the AM? As far as the AM is concerned, this attribute doesn't exist. ## Acknowledgments Most of the work was not done by me, I'm just writing the stabilization report :-) @nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.   > [!NOTE] > # Concerns (0 active) > > - ~~[are-we-happy-wiht-capability-and-scope-of-this-attribute](#157273 (comment) resolved in [this comment](#157273 (comment)) > - ~~[meaning-of-optimize-size](#157273 (comment) resolved in [this comment](#157273 (comment)) > - ~~[explicitly-decide-on-effect-on-nested-functions](#157273 (comment) resolved in [this comment](#157273 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

rustbot · 2026-10-08T09:20:00Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@nagisa

Stabilize `optimize` attribute This commit stabilizes the `#[optimize]` attribute, which allows for more fine-grained control of optimization levels. # Stabilization report ## Summary Tracking issue: rust-lang/rust#54882 Reference PRs: rust-lang/reference#2278 cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler ### What is stabilized ```rust // Instructs the optimization pipeline to prioritize smaller code size over speed. #[optimize(size)] pub fn binary_size_sensitive() { // ... } // Instructs the optimization pipeline to prioritize execution speed over code size. #[optimize(speed)] pub fn performance_critical() { // ... } // Disables optimizations entirely for this item. #[optimize(none)] pub fn debug_only() { // ... } ``` ### What isn't stabilized We might want to allow specifying a per-function optimization level (i.e. `#[optimize(level = 3)]`). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet). Applying the attribute on a module level is also not implemented yet. ## Design ### Reference - Description of the new attribute: rust-lang/reference#2278 ### RFC history - https://rust-lang.github.io/rfcs/2412-optimize-attr.html ### Answers to unresolved question - Should we also implement optimize(always)? optimize(level=x)? Not yet. - Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item). Not yet. ### Post-RFC changes The `optimize(none)` variant was added. The variants above were discussed here: rust-lang/rust#54882 (comment) ### Key points - `#[optimize(none)]` implies `#[inline(never)]` to be effective (rust-lang/rust#136329) - As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: rust-lang/rust#54882 (comment) - Applying the attribute to incompatible items emits an error: rust-lang/rust#128458 ### Nightly uses The standard library itself uses this attribute in a few places ## Implementation ### Major part - Wiring it up to the llvm codegen backend: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/compiler/rustc_codegen_llvm/src/attributes.rs#L416 - Catching usage on incompatible items: rust-lang/rust#128458 - Implementing `optimize(none)`: rust-lang/rust#128657 rust-lang/rust#136358 (includes disabling MIR opts) ### Coverage - Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs - Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs ### Tool changes Trivial changes to rust-analyzer to support the new attribute as an inert attribute: rust-lang/rust-analyzer#22511 ## Type system, opsem ### Breaks the AM? As far as the AM is concerned, this attribute doesn't exist. ## Acknowledgments Most of the work was not done by me, I'm just writing the stabilization report :-) @nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.   > [!NOTE] > # Concerns (0 active) > > - ~~[are-we-happy-wiht-capability-and-scope-of-this-attribute](rust-lang/rust#157273 (comment) resolved in [this comment](rust-lang/rust#157273 (comment)) > - ~~[meaning-of-optimize-size](rust-lang/rust#157273 (comment) resolved in [this comment](rust-lang/rust#157273 (comment)) > - ~~[explicitly-decide-on-effect-on-nested-functions](rust-lang/rust#157273 (comment) resolved in [this comment](rust-lang/rust#157273 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

veluca93 · 2026-10-12T20:49:09Z

ping @ehuss :-)

veluca93 · 2026-10-12T21:17:42Z

Or I guess @tgross35 :-)

tgross35 · 2026-10-13T22:57:16Z

Mentioning on Zulip but usually Lang handles reference reviews :)

traviscross · 2026-10-21T10:28:11Z

Thanks for your patience here. This needs some revisions, which I've been working on. We spent much of the lang-docs call on Tuesday on this. They're close, and I hope to have these up soon.

An earlier update of this branch lost some changes that had been made in response to the review by Eric Huss. Let's restore those and also adjust the wording of the duplicates rule to follow the template.

The earlier wording, that `optimize(none)` "suggests not optimizing the function", could be read to suggest that it's asking specifically for optimizations *not* to happen rather than *not* asking for optimizations to happen. This would arguably be a tier below `-Copt-level=0`. In the lang call on 2026-07-29, the meeting consensus was that with `optimize(none)` we're not asking for optimizations to happen rather than asking for optimizations to not happen.[^1] Let's adopt this framing here. [^1]: rust-lang/rust#157273 (comment)

We need to say explicitly how the inheritance works for this attribute; we need to define the behavior for `async` blocks as well as for closures; and we need to address `const` blocks. Let's do those things.

As with `cold` and `inline`, putting the `optimize` attribute on an associated function within a trait definition only applies the effect of that attribute to the body within the trait definition, not to the bodies of function definitions within implementations of the trait. Let's say that.

It's an error to write `optimize(none)` and `inline` or `inline(always)` on the same function, though it's OK for the effect of `optimize(none)` to be inherited on a closure that is marked with `inline` or `inline(always)`. Let's make these things clear.

The `optimize` attribute suggests an optimization goal (or lack thereof); it doesn't "control" the optimization level. Let's be more clear, and let's use the Reference identifiers for the link reference definitions.

The `optimize` and `naked` attributes can't be used on the same function. Let's document that.

Describing how the `optimize` attribute has no effect when `-Copt-level=0` is set is more appropriate for a nonnormative admonition rather than in the main body of the Reference. From a language perspective, the attribute always has no effect (even if it does, as a language matter, have a certain meaning and intention).

Let's tighten the scope of the alternation within the grammar for the `optimize` attribute.

Let's add examples for `optimize` demonstrating the allowed positions and the behavior when the attribute is repeated on an item.

RalfJung · 2026-10-28T07:34:50Z

+
+- `#[optimize(size)]` suggests optimizing for smaller code, even at the cost of execution speed.
+- `#[optimize(speed)]` suggests optimizing for faster execution, even at the cost of code size.
+- `#[optimize(none)]` suggests compiling the function as though no optimization had been requested for it, whatever was requested for the crate as a whole.


Suggested change

- `#[optimize(none)]` suggests compiling the function as though no optimization had been requested for it, whatever was requested for the crate as a whole.

- `#[optimize(none)]` suggests compiling the function as though no optimization had been requested for it, disregarding what was requested for the crate as a whole.

View changes since the review

RalfJung · 2026-10-28T07:36:19Z

+```
+
+r[attributes.codegen.optimize.closures]
+Closures and [async blocks] without an `optimize` attribute of their own inherit the attribute in effect on the innermost enclosing function, closure, or async block, which may itself be one inherited rather than one written directly. The body of an [async function] inherits the attribute in effect on the function, and the body of an [async closure] inherits the attribute in effect on the closure. Items and [const blocks] within a function do not inherit the attribute in effect on the function, nor do the closures and async blocks within them.


Did someone check this against the implementation?

View changes since the review

There's an UI test about it applying to closures (and explicit code I wrote for it). Async block I guess are a side-effect of that code; I don't remember if I added a test for nested items but them not inheriting the attribute was IIRC intentional; I imagine const blocks are a consequence of that (I assume @traviscross checked the behaviour, although possibly for const blocks it would be somewhat surprising)

RalfJung · 2026-10-28T07:36:30Z

+> ```
+
+> [!NOTE]
+> For `rustc`, the attribute has no effect when optimizations are disabled (`-C opt-level=0`).


Did someone check this against the implementation?

View changes since the review

I checked this on Godbolt when you initially raised the point in the stabilization PR, but I did not check the code directly.

Does this mean when -Copt-level is not passed at all, or specifically when you pass -Copt-level=0? I thought some of the purpose of this attribute was to be able to enable optimizations regardless of opt level.

ehuss added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Jun 1, 2026

veluca93 force-pushed the optimize-attribute branch from 6b8de48 to 0765805 Compare June 1, 2026 19:54

veluca93 mentioned this pull request Jun 1, 2026

Stabilize optimize attribute rust-lang/rust#157273

Merged

veluca93 force-pushed the optimize-attribute branch from 0765805 to 59b5d8d Compare June 2, 2026 09:30

ehuss reviewed Jun 12, 2026

View reviewed changes

Comment thread src/attributes/codegen.md Resolved

Comment thread src/attributes/codegen.md Resolved

DanielEScherzer reviewed Jul 28, 2026

View reviewed changes

Comment thread src/attributes/codegen.md Resolved

veluca93 force-pushed the optimize-attribute branch 2 times, most recently from a58a16d to e9f9d99 Compare September 6, 2026 10:34

veluca93 force-pushed the optimize-attribute branch from e9f9d99 to b499fc3 Compare September 15, 2026 08:57

tgross35 reviewed Sep 30, 2026

View reviewed changes

Comment thread src/attributes/codegen.md Resolved

veluca93 force-pushed the optimize-attribute branch 2 times, most recently from 65bdfe5 to a6519b4 Compare October 2, 2026 14:52

veluca93 marked this pull request as ready for review October 8, 2026 09:19

rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Oct 8, 2026

veluca93 force-pushed the optimize-attribute branch from a6519b4 to dc63d89 Compare October 8, 2026 09:19

Stabilize #[optimize] attribute.

0686253

veluca93 force-pushed the optimize-attribute branch from dc63d89 to 0686253 Compare October 10, 2026 08:19

traviscross changed the title ~~Stabilize #[optimize] attribute~~ Stabilize #[optimize] attribute Oct 27, 2026

Restore review fixes lost from the optimize section

f1a6cbd

An earlier update of this branch lost some changes that had been made in response to the review by Eric Huss. Let's restore those and also adjust the wording of the duplicates rule to follow the template.

traviscross added 9 commits October 27, 2026 19:53

Say which bodies inherit the optimize attribute

3bdbd6e

We need to say explicitly how the inheritance works for this attribute; we need to define the behavior for `async` blocks as well as for closures; and we need to address `const` blocks. Let's do those things.

Reword optimize index entry

cd54f62

The `optimize` attribute suggests an optimization goal (or lack thereof); it doesn't "control" the optimization level. Let's be more clear, and let's use the Reference identifiers for the link reference definitions.

Document that optimize conflicts with naked

46a6fe8

The `optimize` and `naked` attributes can't be used on the same function. Let's document that.

Revise the optimize grammar

258e2a2

Let's tighten the scope of the alternation within the grammar for the `optimize` attribute.

Add examples for optimize positions and duplicates

13dcb18

Let's add examples for `optimize` demonstrating the allowed positions and the behavior when the attribute is repeated on an item.

traviscross force-pushed the optimize-attribute branch from 152d695 to 13dcb18 Compare October 27, 2026 21:37

traviscross reviewed Oct 27, 2026

View reviewed changes

Comment thread src/attributes/codegen.md Resolved

traviscross approved these changes Oct 28, 2026

View reviewed changes

traviscross removed S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository S-waiting-on-review Status: The marked PR is awaiting review from a maintainer labels Oct 28, 2026

RalfJung reviewed Oct 28, 2026

View reviewed changes

	- `#[optimize(none)]` suggests compiling the function as though no optimization had been requested for it, whatever was requested for the crate as a whole.
	- `#[optimize(none)]` suggests compiling the function as though no optimization had been requested for it, disregarding what was requested for the crate as a whole.

Conversation

veluca93 commented Jun 1, 2026 • edited by traviscross Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ehuss left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Oct 8, 2026

Uh oh!

veluca93 commented Oct 12, 2026

Uh oh!

veluca93 commented Oct 12, 2026

Uh oh!

tgross35 commented Oct 13, 2026

Uh oh!

traviscross commented Oct 21, 2026

Uh oh!

Uh oh!

RalfJung Oct 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

RalfJung Oct 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

veluca93 Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Oct 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

veluca93 Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

veluca93 commented Jun 1, 2026 •

edited by traviscross

Loading

ehuss left a comment •

edited by rustbot

Loading

RalfJung Oct 28, 2026 •

edited by rustbot

Loading

RalfJung Oct 28, 2026 •

edited by rustbot

Loading

RalfJung Oct 28, 2026 •

edited by rustbot

Loading