Uh oh!
There was an error while loading. Please reload this page.
Properly reimplement unsafe-code lint to honor changing lint attributes - #22752
Conversation
rust-highfive
commented
Feb 24, 2015
(rust_highfive has picked a reviewer for you, use r? to override) |
oli-obk
commented
Feb 24, 2015
the lint is there to detect unsafe code. If your project forbids unsafe code, don't use it. Allowing to disable the lint after it has been enabled breaks this "contract" imho. This is becoming a somewhat circular argument then. [sarcasm] If this is implemented, i want a lint checking for attributes that disable the lint. [/sarcasm] [edit] oh sorry, you are not changing the behavior. it already is the current behavior... oh well... don't mind me |
ipetkov
commented
Feb 24, 2015
@oli-obk yeah in my previous update of the lint's functionality caused it to not behave correctly according to the linting system the way any user (including myself) would expect it to behave, and this patch is meant to fix that. Also a project can always use the |
alexcrichton
commented
Feb 24, 2015
…hton This allows selectively disabling the lint for individual methods or traits.
bors
commented
Feb 25, 2015
⌛ Testing commit fcf7023 with merge 4818d9a... |
bors
commented
Feb 25, 2015
💔 Test failed - auto-linux-64-x-android-t |
This allows selectively disabling the lint for individual methods or traits.