Repository navigation
target_feature_11 rejects code that was previously accepted #108655
Description
#[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]`
Activity
apiraino commentedon Mar 2, 2023
Hm, I think related to #108645 and #108646
LeSeulArtichaut commentedon Mar 2, 2023
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 commentedon Mar 3, 2023
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 commentedon Mar 3, 2023
But yes, I believe this code actually should be fully acceptable. Note that in #108338 that if
target_feature_11is 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 commentedon Mar 3, 2023
Assigning P-low because the regression has been contained to nightly versions due to an immediate revert, so this only blocks forward feature development.
LeSeulArtichaut commentedon Mar 3, 2023
Auto merge of rust-lang#111836 - calebzulawski:target-feature-closure…