Added so attributes and cfgs are applied on the trampolines as well#228
Added so attributes and cfgs are applied on the trampolines as well#228
Conversation
|
r? @thejpster (rust_highfive has picked a reviewer for you, use r? to override) |
|
bors try |
tryBuild succeeded |
|
This will also apply attributes like |
|
Sure, should be no problem to add. |
|
@jonas-schievink I added a blacklist, works as expected. Are there more we would like to blacklist? |
jonas-schievink
left a comment
There was a problem hiding this comment.
The blacklist approach should also handle #[cfg_attr(some_cfg, blacklisted_attr)].
It's not strictly necessary to forbid #[inline] (it shouldn't have any effect), but #[no_mangle] might be an issue. #[must_use] might also be a problem since it might emit an unavoidable warning, and lint attributes should not be propagated or they might warn for code in the trampoline.
|
Fixed your comments.
This is already handled and I tested it as well :) |
|
Also, I will rebase and squash this before we merge this |
|
Tests added to CI as well |
b49af40 to
5a878d0
Compare
|
There, I think this should be ready now |
|
Handing to @jonas-schievink as this is a bit out of my comfort zone. |
jonas-schievink
left a comment
There was a problem hiding this comment.
Thanks! I think the tests can be merge since they just test individual blacklist entries. It would also be good to test the #[cfg_attr] case.
I'm still not convinced of the blacklist approach though. Rust itself and other crates can add attributes at any point, which might interact badly with cortex-m-rt's, so I'd prefer a whitelist instead. It's also unclear to me if these are all the problematic attributes. For example, what about lint-controlling attributes? We might want to put them only on the user function and not the trampoline. Most of the builtin attributes are at best useless, and may cause very bad compiler errors (what about #[test]?), and I don't think there's any use case for using other proc macro attributes.
|
Sure, we can switch to a whitelist as well. |
jonas-schievink
left a comment
There was a problem hiding this comment.
We also need to allow cfg and cfg_attr (and add a test for them). The lint-controlling attributes definitely shouldn't be disallowed either (like I mentioned above), that is allow, warn, deny and forbid. #[cold] should also be allowed, it can potentially affect optimization choices.
If this list is complete then these should be all.
|
Updated per your comments, ready for another review |
jonas-schievink
left a comment
There was a problem hiding this comment.
Thanks, looks good to me now!
Does someone else from @rust-embedded/cortex-m have opinions on this? This is also a breaking change, so we should probably hold off on merging this until we have a more clear plan for the next cortex-m-rt version.
|
Oh one more thing, does this happen to also fix #213 by any chance? I'm not sure if proc. macro attributes can see other proc. macro attributes, but if so this should fail the whitelist check (and if not that issue can be closed as wontfix). |
|
Sure! I added a test for that and it does catch this issue as well. |
|
Hmm, I should probably look into a better error messages for these |
jonas-schievink
left a comment
There was a problem hiding this comment.
r=me unless you still want to improve the diagnostics
|
I will have a look at the message, should go fast |
|
@jonas-schievink I added better diagnostics, please have a look again and then we can merge |
|
Sounds good, I committed it |
8b2732c to
44985bc
Compare
Co-Authored-By: Jonas Schievink <jonasschievink@gmail.com>
# Please enter the commit message for your changes. Lines starting Formating fix
jonas-schievink
left a comment
There was a problem hiding this comment.
Thanks, this is great!
|
Very true, updated and removed blacklist |
|
bors r+ |
228: Added so attributes and cfgs are applied on the trampolines as well r=jonas-schievink a=korken89 I made a first go at #223, but maybe this implementation takes things we do not want to propagate. If you come up with something that should not propagate, please comment here. Closes #223 Closes #213 Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
Build succeeded |
I made a first go at #223, but maybe this implementation takes things we do not want to propagate.
If you come up with something that should not propagate, please comment here.
Closes #223
Closes #213