-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Deny rust_2018_idioms globally #60133
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Looks like |
This comment has been minimized.
This comment has been minimized.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
r? @Centril |
I'm not sure if there are alternatives to 8e55559. Apart from that, I think this PR is ready. |
@bors r+ |
📌 Commit 8e55559 has been approved by |
⌛ Testing commit 8e55559 with merge 5452576bb46d2a07c49410acf86898e1f9790883... |
💔 Test failed - checks-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors retry |
Deny rust_2018_idioms globally cc #58099 (comment)
@@ -7,6 +7,7 @@ | |||
#![feature(try_reserve)] | |||
#![feature(unboxed_closures)] | |||
#![feature(vecdeque_rotate)] | |||
#![deny(rust_2018_idioms)] |
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 don't understand why it's denied here if it was denied in rustbuild already.
Also, why aren't all the deny(rust_2018_idioms)
s in specific crates removed?
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.
We can remove them in a follow up. However, I personally prefer to keep them as it works better when you cargo check
a crate without x.py
.
☀️ Test successful - checks-travis, status-appveyor |
|
||
extern crate core; | ||
extern crate test; |
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.
Any idea why you didn't also have to remove this line? It causes a build failure when building the tests "from the outside" at https://travis-ci.org/RalfJung/miri-test-libstd/builds/523334973.
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'm not really sure. Do you maybe have to pass --test
in order for the crate to be used?
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.
Hm, no... removing it actually makes it fail in x.py
. But somehow it is considered redundant when compiled in a less magic environment?
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 adding #[allow(unused_extern_crates)]
before extern crate test;
should fix it (like here), but I won't be able to actually try it out until later today.
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.
This should also work: #60201
cc #58099 (comment)