-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Fix setting inline hint based on InstanceDef::requires_inline
#79106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit d21c26de759749074fa06ccb72acd35311920870 with merge 215cffaf2348b072fbf45e176795ee5c10645ea8... |
☀️ Try build successful - checks-actions |
Queued 215cffaf2348b072fbf45e176795ee5c10645ea8 with parent f5230fb, future comparison URL. |
Finished benchmarking try commit (215cffaf2348b072fbf45e176795ee5c10645ea8): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
For instances where `InstanceDef::requires_inline` is true, an attempt is made to set an inline hint though a call to the `inline` function. The attempt is ineffective, since all attributes will be usually removed by the second call. Fix the issue by applying the attributes only once, with user provided attributes having a priority when provided.
The perf results look quite promising. This fixes a bug where inline hint was |
InstanceDef::requires_inline
unless overriddenInstanceDef::requires_inline
LGTM, cc @nagisa @wesleywiser @alexcrichton |
Attribute::AlwaysInline.unapply_llfn(Function, val); | ||
Attribute::NoInline.unapply_llfn(Function, val); | ||
} | ||
None if requires_inline => Attribute::InlineHint.apply_llfn(Function, val), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the intended behaviour here when requires_inline == true
and inline != None
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If its not something that can happen, maybe bug!()
it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requires inline instances are mostly auto-generated. Closures are the exception, so it is possible but unlikely. As far as what should take priority, no idea what the intent was, if it was considered at all (although the order of calls would suggest respecting user provided attributes).
r? @nagisa |
@bors r=nagisa,eddyb |
📌 Commit 4ea25da has been approved by |
⌛ Testing commit 4ea25da with merge d91d08d88d83f418d20b15d79d093c7d85644e96... |
💥 Test timed out |
@bors retry |
☀️ Test successful - checks-actions |
For instances where
InstanceDef::requires_inline
is true, an attemptis made to set an inline hint though a call to the
inline
function.The attempt is ineffective, since all attributes will be usually removed
by the second call.
Fix the issue by applying the attributes only once, with user provided
attributes having a priority when provided.
Closes #79108.