Skip to content
This repository was archived by the owner on Jan 24, 2022. It is now read-only.

Added so attributes and cfgs are applied on the trampolines as well#228

Merged
bors[bot] merged 10 commits intomasterfrom
attrs_cfgs_to_trampoline
Jan 16, 2020
Merged

Added so attributes and cfgs are applied on the trampolines as well#228
bors[bot] merged 10 commits intomasterfrom
attrs_cfgs_to_trampoline

Conversation

@korken89
Copy link
Copy Markdown
Contributor

@korken89 korken89 commented Dec 28, 2019

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

@korken89 korken89 requested a review from a team as a code owner December 28, 2019 14:36
@rust-highfive
Copy link
Copy Markdown

r? @thejpster

(rust_highfive has picked a reviewer for you, use r? to override)

@korken89
Copy link
Copy Markdown
Contributor Author

bors try

bors bot added a commit that referenced this pull request Dec 28, 2019
@bors
Copy link
Copy Markdown
Contributor

bors bot commented Dec 28, 2019

try

Build succeeded

@jonas-schievink
Copy link
Copy Markdown
Contributor

This will also apply attributes like #[export_name] and #[inline], which doesn't make too much sense to me. I think the most robust approach would be to use a whitelist of attributes that are propagated to the trampoline. I'll start working on one.

@korken89
Copy link
Copy Markdown
Contributor Author

Sure, should be no problem to add.
But not a blacklist? Seems like doc, inline, and export_name are the direct ones we do not want.

@korken89
Copy link
Copy Markdown
Contributor Author

@jonas-schievink I added a blacklist, works as expected. Are there more we would like to blacklist?
Or do you have a specific whitelist I should change to?

Copy link
Copy Markdown
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@korken89
Copy link
Copy Markdown
Contributor Author

korken89 commented Dec 28, 2019

Fixed your comments.

The blacklist approach should also handle #[cfg_attr(some_cfg, blacklisted_attr)].

This is already handled and I tested it as well :)

@korken89
Copy link
Copy Markdown
Contributor Author

Also, I will rebase and squash this before we merge this

@korken89
Copy link
Copy Markdown
Contributor Author

Tests added to CI as well

@korken89 korken89 force-pushed the attrs_cfgs_to_trampoline branch from b49af40 to 5a878d0 Compare December 29, 2019 12:52
@korken89
Copy link
Copy Markdown
Contributor Author

There, I think this should be ready now

@thejpster
Copy link
Copy Markdown
Contributor

Handing to @jonas-schievink as this is a bit out of my comfort zone.

Copy link
Copy Markdown
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@korken89
Copy link
Copy Markdown
Contributor Author

Sure, we can switch to a whitelist as well.
What more than doc and link_section should be allowed?

Copy link
Copy Markdown
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@korken89
Copy link
Copy Markdown
Contributor Author

korken89 commented Jan 7, 2020

Updated per your comments, ready for another review

jonas-schievink
jonas-schievink previously approved these changes Jan 7, 2020
Copy link
Copy Markdown
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@jonas-schievink
Copy link
Copy Markdown
Contributor

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).

@korken89
Copy link
Copy Markdown
Contributor Author

korken89 commented Jan 8, 2020

Sure! I added a test for that and it does catch this issue as well.

@korken89
Copy link
Copy Markdown
Contributor Author

korken89 commented Jan 8, 2020

Hmm, I should probably look into a better error messages for these

Copy link
Copy Markdown
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me unless you still want to improve the diagnostics

@korken89
Copy link
Copy Markdown
Contributor Author

I will have a look at the message, should go fast

@korken89
Copy link
Copy Markdown
Contributor Author

@jonas-schievink I added better diagnostics, please have a look again and then we can merge

@korken89
Copy link
Copy Markdown
Contributor Author

Sounds good, I committed it

@korken89 korken89 force-pushed the attrs_cfgs_to_trampoline branch from 8b2732c to 44985bc Compare January 16, 2020 12:06
Co-Authored-By: Jonas Schievink <jonasschievink@gmail.com>
    # Please enter the commit message for your changes. Lines starting

Formating fix
Copy link
Copy Markdown
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is great!

@korken89
Copy link
Copy Markdown
Contributor Author

Very true, updated and removed blacklist

@jonas-schievink
Copy link
Copy Markdown
Contributor

bors r+

bors bot added a commit that referenced this pull request Jan 16, 2020
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>
@bors
Copy link
Copy Markdown
Contributor

bors bot commented Jan 16, 2020

Build succeeded

@bors bors bot merged commit 941ed5b into master Jan 16, 2020
@bors bors bot deleted the attrs_cfgs_to_trampoline branch January 16, 2020 17:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

#[link_section] (and maybe more) should be applied to the trampoline Multiple attributes are allowed on a single function

4 participants