-
Notifications
You must be signed in to change notification settings - Fork 272
Avoid unsafe
in const macro translations except where necessary
#1339
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
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.
See #1335 (review), too, but in general, what's the difference between the unsafe
block for a const
and the unsafe
on an unsafe fn
(which in the latest edition is meant to also be an unsafe
block in the unsafe fn
, too)? They seem exactly the same to me, and I think we should approach them the same. So a change like this (which I haven't looked through all of the details of yet) makes sense to me if it also applies to an unsafe fn
. Note that there are often a bunch of unsafe fn
s that are fully safe and don't need the unsafe
, and removing the unsafe
for a const
that doesn't need it and remove the unsafe
for a fn
that doesn't need it seem like the exact same problem.
The difference is that there is no unsafe block surrounding definitions of When we change the edition we target, it will make sense to use |
81551c0
to
ecddc95
Compare
23b03d6
to
190860a
Compare
190860a
to
0ba0195
Compare
History is cleaned up now; this should be good to merge. |
0ba0195
to
b06febb
Compare
…for `--translate-const-macros conservative`" This reverts commit 3635b4e.
b06febb
to
7dbe6b1
Compare
Atop #1306, as I'd rather not regress all const translations to be
unsafe
in master now that we translate const macros by default.