target_feature_11 rejects code that was previously accepted

[tmiasko]

#[target_feature(enable = "sse2")]
pub unsafe fn test() {
    ({
        #[inline(always)]
        move || {}
    })();
}

The preceding code used to compile successfully. Since the stabilization of
#![feature(target_feature_11)] in #99767 the compilation fails with:

error: cannot use `#[inline(always)]` with `#[target_feature]`

[apiraino]

Hm, I think related to #108645 and #108646

[LeSeulArtichaut]

Based on #73631 (comment), I'm guessing it would be fine to allow #[inline(always)] with #[target_feature] on closures, at least from a language perspective, even if it still trips up LLVM?

[workingjubilee]

Technically, inline(always) is "just a hint" and thus one solution is and always was to accept the inline annotation and then simply ignore the request.

[workingjubilee]

But yes, I believe this code actually should be fully acceptable. Note that in #108338 that if target_feature_11 is enabled, the attributes do get applied to the closure and inlining is done normally by LLVM due to a full match. No hint required.

[workingjubilee]

Assigning P-low because the regression has been contained to nightly versions due to an immediate revert, so this only blocks forward feature development.