`optimize` attribute applied to things other than methods/functions/c…

[tnuha]

…losures gives an error (#128488)

Duplicate of #128943, which I had accidentally closed when rebasing.

cc. @jieyouxu @compiler-errors @nikomatsakis @traviscross @pnkfelix.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tnuha]

@rustbot label +T-compiler +T-lang

[workingjubilee]

@jieyouxu: The RFC says:

#[optimize] attribute applied to non function-like items (such as struct) or non function-like expressions (i.e. not closures) is considered “unused” as of this RFC and should fire the unused_attribute lint (unless the same attribute was used for a function-like item or expression, via e.g. propagation). Some future RFC may assign some behaviour to this attribute with respect to such definitions.

And niko said:

In general I prefer to give a hard error so that we can change the meaning rather than silently change behavior in the future,

And speaking for T-lang, TC said:

We discussed this today in triage, and our general feeling is that conservatively giving a hard error is our preference.

We talked about how, in defense of allowing these attributes liberally, that strictly speaking this is just an optimization, and so an unheeded attribute doesn't affect things in a language specification sense. But we still preferred to just give an error for now.

So my understanding of the gestalt is that this attribute should

1. only be accepted where it explicitly has a behavior of some kind
2. be given a behavior in certain places according to the RFC and the whims of T-lang

The former need not await the latter.

[jieyouxu]

Fair enough. In that sense I would recommend rejecting the mod case and only accept function-like targets.

[traviscross]

Note also the comment from pnkfelix here:

I'll just jot a follow-up note here that one place where we probably do want to continue accepting #[optimize] is on async blocks, with the semantics that the attribute is applied to the poll method of the generated future.

(This is based on lang-team discussion here.)

This would apply to nightly gen blocks also.

[jieyouxu]

@rustbot author

[tnuha]

Thank you for your mentorship in getting this thing in. Here's to future collaboration.

@rustbot review

[jieyouxu]

@bors r+ rollup

[bors]

:pushpin: Commit 080103f1edeea36827a51a9f663cf86638b44cb5 has been approved by jieyouxu

It is now in the queue for this repository.