Uh oh!
There was an error while loading. Please reload this page.
Check for known but incorrect attributes - #49291
Conversation
rust-highfive
commented
Mar 23, 2018
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
tejom
commented
Mar 23, 2018
bors
commented
Mar 23, 2018
☔ The latest upstream changes (presumably #49308) made this pull request unmergeable. Please resolve the merge conflicts. |
abonander
commented
Mar 23, 2018
@tejom so that PR was a rollup which added code for another attribute to The preferred approach is to rebase on top of master ( |
tejom
commented
Mar 24, 2018
Alright cool. The commit doesn't look to crazy to deal with. Thanks! |
There was a problem hiding this comment.
I don't understand what is the logic here.
How attributes on #[attr] my_fn_call() could be handles by items or statements?
There was a problem hiding this comment.
I think I got confused reading the comments on the Expr_ enum. I think only ExprAssign overlaps with statements then.
let a = 1 seems to be both an expression and statement?
I can take this section out and everything seems to work fine still. The error that appears for
#[repr]let _y = "123";is attribute should not be applied to statements with and without this match.
There was a problem hiding this comment.
let a = 1 is not an expression, ExprAssign is a = b.
If you have a statement with one expression, like
a = b;
then it's represented roughly like StmtExpr(ExprAssign) and attributes are attached to the outer statement and not inner expression.
There was a problem hiding this comment.
Oh Ok. I see. Thanks for the clarification.
petrochenkov
commented
Mar 26, 2018
LGTM beside one comment (also needs rebase). |
- Change nested_visit_map so it will recusively check functions - Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect inline and repr attributes on staements and expressions - Add regression test for isssue rust-lang#43988
7bf1158 to
48825bcCompare| attr.span, | ||
| stmt.span, | ||
| &format!("attribute should not be applied to statements"), | ||
| &format!("attribute should not be applied a statement"), |
| #[inline(ABC)] | ||
| foo(); | ||
| //~^^ ERROR attribute should be applied to function |
There was a problem hiding this comment.
All the tests are for statements, could you add a test for an expression too?
Something like let x = #[repr] y;
There was a problem hiding this comment.
I added this example. I needed to add a feature in the tests to get it to actually run.
Otherwise error[E0658]: attributes on non-item statements and expressions are experimental. (see issue #15701) stopped all of the tests early.
petrochenkov
commented
Mar 27, 2018
r=me after addressing comments |
petrochenkov
commented
Mar 27, 2018
@bors r+ |
bors
commented
Mar 27, 2018
📌 Commit 4957a40 has been approved by |
kennytm
commented
Mar 28, 2018
@bors p=3 |
bors
commented
Mar 29, 2018
…, r=petrochenkov Check for known but incorrect attributes fixes#43988 - Change nested_visit_map so it will recursively check functions - Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect inline and repr attributes on staements and expressions - Add regression test for issue #43988
bors
commented
Mar 29, 2018
☀️ Test successful - status-appveyor, status-travis |
kivikakk
commented
Mar 31, 2018
Hey there, I'm investigating pest-parser/pest#218, where pest fails to build on nightly 2018-03-29; it looks like this merge is the change that did it. I'm not sure exactly why, but one suspicion is that fnmain(){#[inline] || {};}This compiles without any warning or error on e5277c1 2018-03-28, but on ae544ee 2018-03-29: $ rustc test.rserror[E0518]: attribute should be applied to function --> test.rs:2:2 |2 | #[inline] || { }; | ^^^^^^^^^ ------ not a functionerror: aborting due to previous errorFor more information about this error, try `rustc --explain E0518`.Is this intentional? |
Yes, |
kivikakk
commented
Mar 31, 2018
Good to know, thank you! ❤️ |
Amanieu
commented
Apr 3, 2018
Actually, |
Amanieu
commented
Apr 3, 2018
The generated LLVM IR (in debug builds) for this example is different if you remove #![feature(stmt_expr_attributes)]#![crate_type="rlib"]pubfnmain(){let x = #[inline(always)] || {};x();} |
tejom
commented
Apr 3, 2018
It looks like the code generated for your example with |
Amanieu
commented
Apr 3, 2018
That's because the closure is inlined anyways in release builds. You only notice the difference in debug builds where inline hint are ignored unless they are forced. My point is that |
tejom
commented
Apr 4, 2018
I'm just asking because I'm curious, would this be bug with the compiler not inlining closures when not using one of the higher optimization levels? Seems like that is what the expected behavior was? |
Amanieu
commented
Apr 4, 2018
The inlining works fine. The bug is that your PR is too strict: |
fixes#43988
Change nested_visit_map so it will recursively check functions
Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
Add regression test for issue Known but incorrect attributes over statements/expressions are ignored. #43988