-
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
Add functionality for epoch lints; add epoch lint for dyn-trait #48461
Conversation
FutureIncompatibleInfo { | ||
id: LintId::of(lint::builtin::BARE_TRAIT_OBJECT), | ||
reference: "issue #48457 <https://github.com/rust-lang/rust/issues/48457>", | ||
epoch: Some(session::config::Epoch::Epoch2018), |
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 could potentially reuse the epoch on the lint
we do need something for lints which need to be removed on the next epoch (because the stuff they lint doesn't exist anymore)
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 trying to imagine when we would want to make a distinction between the "epoch on the lint" and the "epoch in the future compat info". I'm not really sure -- indeed -- what the "epoch on the lint" means, if not that it is an epoch lint of this kind. Maybe another way of saying this is that "future incompatibility" feels distinct from epochs, and might want to be a different mechanism. In particular, future incompatible changes change for everyone, whereas epochs are opt-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.
The lint may become Deny on a different epoch than the one it is linting for, basically.
One of the settings is "when this becomes Deny", the other is "which lint group this belongs to".
In the future we may also provide a way for the lint to go away completely.
c618b0f
to
76a2705
Compare
We also need a lint for the |
src/librustc/lint/levels.rs
Outdated
@@ -1,4 +1,4 @@ | |||
// Copyright 2017 The Rust Project Developers. See the COPYRIGHT | |||
// Copyright 2017 The Rust Project ~velopers. See the COPYRIGHT |
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.
accidental replace
src/librustc/session/mod.rs
Outdated
} | ||
|
||
pub fn buffer_lint_with_diagnostic<S: Into<MultiSpan>>(&self, | ||
lint: &'static lint::Lint, |
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.
indentation is weird here. Maybe use rustfmt style?
@@ -74,25 +75,46 @@ pub struct Lint { | |||
/// | |||
/// e.g. "imports that are never used" | |||
pub desc: &'static str, | |||
|
|||
/// Deny lint after this epoch | |||
pub epoch_deny: Option<config::Epoch>, |
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.
Further down you state that the lint should be removed after the epoch, here it seems to suggest it should be deny
.
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.
Where is this? It used to say this, but that changed.
This specific lint becomes Deny in Rust2018. Other lints may wish to disappear entirely because they are no longer lints.
76a2705
to
177271f
Compare
A bug is that it will currently suggest |
I've got the rustfix stuff running at #48477 |
#48481 fixes the |
5484cf9
to
1c99be5
Compare
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 all looks quite good. I'm wondering about the idea of distinguish epochal vs non-epochal future incompatibility. Thoughts?
r=me modulo nits and this question though.
for info in lints { | ||
self.future_incompatible.insert(info.id, info); | ||
|
||
for epoch in config::ALL_EPOCHS { |
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.
comment plz
"Create a lint group for each epoch corresponding to the future compatibility warnings targeting that epoch"
(Do you think that this ought to include the lints for "all previous epochs", since they are additive?)
(Also, are these lint groups insta-stable?)
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 could. I think having them separate is cleaner, Rust doesn't do well with overlapping lint groups.
Rust lint stability is a very low bar, you just need to not remove the lint (aside from register_removed_lint()
or whatever it's called). I think it's fine to insta-stable lint groups.
FutureIncompatibleInfo { | ||
id: LintId::of(lint::builtin::BARE_TRAIT_OBJECT), | ||
reference: "issue #48457 <https://github.com/rust-lang/rust/issues/48457>", | ||
epoch: Some(session::config::Epoch::Epoch2018), |
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 trying to imagine when we would want to make a distinction between the "epoch on the lint" and the "epoch in the future compat info". I'm not really sure -- indeed -- what the "epoch on the lint" means, if not that it is an epoch lint of this kind. Maybe another way of saying this is that "future incompatibility" feels distinct from epochs, and might want to be a different mechanism. In particular, future incompatible changes change for everyone, whereas epochs are opt-in.
src/librustc/lint/builtin.rs
Outdated
Err(_) => format!("dyn <type>") | ||
BuiltinLintDiagnostics::BareTraitObject(span, is_global) => { | ||
let sugg = match (sess.codemap().span_to_snippet(span), is_global) { | ||
(Ok(s), true) => format!("dyn ({})", s), |
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.
Nit: this would (imo) be slightly easier to read as
let sugg = match sess.codemap().span_to_snippet(span) {
Ok(s) if is_global => ...
Ok(s) => ...
_
}
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 do that, perhaps you're reviewing an earlier commit?
src/librustc/lint/builtin.rs
Outdated
Ok(s) => format!("dyn {}", s), | ||
Err(_) => format!("dyn <type>") | ||
}; | ||
db.span_suggestion(span, "use `dyn`", sugg); |
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.
can we have a test or two, particularly of the suggestions?
6ac8093
to
a4ebd4a
Compare
a4ebd4a
to
0cb3672
Compare
@bors r=nmatsakis (r+d over IRC) |
📌 Commit 0cb3672 has been approved by |
@Manishearth any chance you could link the point in the log? It sounds like you two discussed some things, the justification would be nice to have saved in-context in the PR. :) |
…sakis Use `dyn trait` everywhere Based on rust-lang#48461 do not land unless both are reviewed.
This makes it possible for lints to specify an epoch after which they become Deny, as well as automatically creating lint groups for these.
This had to be done as a hardwired lint because we lose information about whether
TyTraitObject
nodes were from dyn trait in the HIR, and in the AST we don't know ifTyPath
s are type-y or trait-y.Still need to write tests and fix up all the new warnings (though I may wait for contributors to do that -- @killercup is it possible to run rustfix on a crate-by-crate basis for rustc?). Also, #48457 needs to get some contents.
Still, worth getting review for what I have so far.
r? @nmatsakis
fixes #48447