#[inline] is no longer accepted on closures

Since #49291 #[inline] is no longer accepted on closures, despite the fact that this attribute does have an effect on code generation.

The generated LLVM IR (in debug builds) for this example is different if you remove #[inline(always)]:

#![feature(stmt_expr_attributes)] 
#![crate_type="rlib"]

pub fn main() {
    let x = #[inline(always)] || {};
    x();
}

While I think this should be fixed, this is not exactly a regression, since stmt_expr_attributes is unstable and this code never worked on stable.

I can make a change, since I wrote that original patch. I'm curious if a better change would be to have closures always inlined? That seems like it might have been the expected behavior and the reason why it was suggested to me to write the check like this in the first place?

I believe closures are currently always effectively #[inline]. However in some cases I need to force inlining with #[inline(always)] even when LLVM thinks it is a bad idea.

I would just change the check_expr_attributes function in librustc/hir/check_attr.rs to check the variant of hir::Expr passed in when the attribute is inline. if its ExprClosure then don't emit an error. But Id prefer to have someone who does the reviews say this is what they want instead of having a surprise at the pull request stage.

Rollup merge of rust-lang#50273 - Amanieu:issue-49532, r=alexcrichton

Navigation Menu

Repository navigation

#[inline] is no longer accepted on closures #49632

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

#[inline] is no longer accepted on closures #49632

Description

Activity

sanxiyn commented on Apr 5, 2018

tejom commented on Apr 6, 2018

Amanieu commented on Apr 6, 2018

tejom commented on Apr 6, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions