-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Associated types can be specified multiple times in trait objects #50589
Comments
Implementing a lint for this would be a good beginner's task I think. |
I'd like to work on this starting from Tuesday, if that's ok. Never hacked on a compiler before, anything I need to know besides the rustc guide for this particular issue? Would appreciate any help! |
Hi @abonander , I find it is easier to implement this warning based on normal diagnostics than lint in We just need to add a new argument Is this solution acceptable? |
@F001 Hardcoded warnings are strongly discouraged, but it's not that difficult to create a lint anyway. This should get you started; add the following to declare_lint! {
// we can bikeshed the lint name
DUP_ASSOC_TYPE_BINDING,
Warn,
"warns about duplicate associated type bindings in generics, e.g. `Iterator<Item = (), Item = ()>`"
}
pub struct DupAssocTypeBinding;
impl LintPass for DupAssocTypeBinding {
fn get_lints(&self) -> LintArray {
lint_array!(DUP_ASSOC_TYPE_BINDING)
}
}
impl EarlyLintPass for DupAssocTypeBinding {
fn check_path(&self, ctxt: &EarlyContext, path: &ast::Path) {
// could be `Iterator` or `std::iter::Iterator` or `Iterator<Item = ()>::next`
// need to check all segments
for segment in &path.segments {
// if its `Iterator<..>` or `Iterator(...)` (for closure traits)
if let Some(ref params) = segment.parameters {
// if it's `Iterator<...>`
if let ast::AngleBracketed(ref params_data) = &**params {
// in `params_data.bindings`, if two elements have the same
// `ident` and `ty` fields but differing `id` fields,
// emit a lint message with:
ctxt.span_lint(DUP_ASSOC_TYPE_BINDING,
vec![param_span_1, param_span_2],
"duplicate associated type binding");
}
}
}
}
} We can bikeshed the lint message. Also, try to avoid emitting a lint for the same pair twice if you're doing a nested And then in Then you'll need to implement a UI test (which you would need to implement if you were emitting the warning in the parser anyway). I can add instructions for that if you need it. |
Wow, what an informative instruction. Thanks very much. I will create a merge request tomorrow. |
@F001 I had to edit my comment because |
Add lint for multiple associated types Fix #50589. cc @abonander
Take supertraits into account when calculating associated types Fixes rust-lang#24010 and rust-lang#23856. Applies to trait aliases too. As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See rust-lang#50589 for more info. I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+. N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this. CC @carllerche @theemathas @durka @mbrubeck
It seems rather surprising that the above code actually compiles. Making it an error wouldn't be backwards compatible but a warning would be nice (the same happens with
impl Future<Item = (), Item = ()>
which is where I got burnt, thinking I had specified theError
type).The text was updated successfully, but these errors were encountered: