-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Associated types can be specified multiple times in trait objects #50589
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: