-
Notifications
You must be signed in to change notification settings - Fork 718
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
Wrap unsafe function's bodies in unsafe blocks #2266
Wrap unsafe function's bodies in unsafe blocks #2266
Conversation
79e1051
to
953ca92
Compare
☔ The latest upstream changes (presumably 8b29355) made this pull request unmergeable. Please resolve the merge conflicts. |
953ca92
to
d4ba612
Compare
☔ The latest upstream changes (presumably 4b006da) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
I think code looks good, after a rebase. I'm not quite sure about the feature, in the sense that it doesn't add any real benefit over saving the user typing #[allow(..)]
for a feature they need to opt-into anyways.
I think it'd be good to move all these post-processing operations to their own file since putting it in lib.rs feels a bit odd and creates a lot of rightward drift. But that can be a follow-up I suppose.
I implemented this because I thought you agreed to it 😬 That being said, I think it is not unheard of cc @ojeda just because they requested the feature and might want to give their opinion |
aca0a08
to
225eeca
Compare
It is definitely not critical, but it allows a project to call the compiler with a global Moreover, considering that the language is evolving towards not implying unsafe blocks in |
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.
Thank you
☔ The latest upstream changes (presumably #2282) made this pull request unmergeable. Please resolve the merge conflicts. |
66be332
to
07d6134
Compare
@emilio you approved this PR but from your comments it is not clear to me that you want this actually merged. |
☔ The latest upstream changes (presumably #2284) made this pull request unmergeable. Please resolve the merge conflicts. |
07d6134
to
e2d471f
Compare
☔ The latest upstream changes (presumably 9c32b46) made this pull request unmergeable. Please resolve the merge conflicts. |
e3cf0d7
to
dfd69e2
Compare
☔ The latest upstream changes (presumably bae6170) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
Assuming there are no warnings for redundant unsafe blocks etc this looks good!
dfd69e2
to
eadaa39
Compare
@pvdrz you've been on a roll recently! Thanks for pushing through so many tickets I've been subscribed to! |
Unfortunately, this broke building with -Dwarnings on rustc < 1.65. |
Do you have any reduced case so we can add it to the tests? |
Any of the test files that were touched in e8ffb42 shows the warning with rustc < 1.65. |
#2354 should fix this |
This PR adds a new option
--unsafe-blocks
which wraps all the bodies of generatedunsafe
functions inunsafe
blocks.Fixes: #2063
Blocked by: #2265