Recover invalid assoc type bounds using ==
#87566
Conversation
rust-highfive
added
the
S-waiting-on-review
JohnCSimon
added
S-waiting-on-review
inquisitivecrystal
added
the
T-compiler
| @@ -1933,7 +1933,19 @@ impl<'a> Parser<'a> { | |||
| } | |||
| match self.parse_expr_res(Restrictions::CONST_EXPR, None) { | |||
| Ok(expr) => { | |||
| if token::Comma == self.token.kind || self.token.kind.should_end_const_arg() { | |||
| // Find a mistake like `MyTrait<Assoc == S::Assoc>`. | |||
| if token::EqEq == snapshot.token.kind { | |||
There was a problem hiding this comment.
I feel like this is the wrong place for this. Haven't dug into this, but I would have expected this to be in the same place as the associated type parsing code? There, we just "accept" with an error == when we really want =.
I guess this is potentially "ambiguous" if Assoc == S::Assoc gets treated as a const arg, which I guess is what currently happens.
Is there anything we can to be smarter here? Would we theoretically be allowed to have a variable named Assoc? I'm trying to think of if we had complete knowledge of all traits, types, variables, etc. in scope, are there any cases where we can know if this should be a bracketed const expr arg or an associated type binding?
There was a problem hiding this comment.
I got somewhat confused as to why we didn't have a == binop here, but looking at the surrounding code I can now see that we discard whatever op this was and what is being parsed here is the RHS, namely a single path. So I'm getting around to thinking that this is not a bad place to make this check.
| err.span_suggestion( | ||
| snapshot.token.span, | ||
| "replace `==` with `=`", | ||
| "=".to_string(), | ||
| Applicability::MaybeIncorrect, | ||
| ); |
There was a problem hiding this comment.
If this does stay here, it might be worth mentioning something like "if you meant to use an associated type binding"
| "=".to_string(), | ||
| Applicability::MaybeIncorrect, | ||
| ); | ||
| let value = self.mk_expr_err(expr.span); |
There was a problem hiding this comment.
Shouldn't this be self.mk_expr_err(start.to(expr.span))? We'd want this to cover the whole Foo == Bar instead of just Bar.
JohnTitor
force-pushed
the
find-eqeq-on-assoc-type-bounds
branch
from
8625e34 to
ee99bb3
Compare
|
@bors r+ |
|
📌 Commit ee99bb3 has been approved by |
bors
added
S-waiting-on-bors
|
Just realized that we should probably also check that the rhs is a path (because |
…laumeGomez Rollup of 10 pull requests Successful merges: - rust-lang#86422 (Emit clearer diagnostics for parens around `for` loop heads) - rust-lang#87460 (Point to closure when emitting 'cannot move out' for captured variable) - rust-lang#87566 (Recover invalid assoc type bounds using `==`) - rust-lang#88666 (Improve build command for compiler docs) - rust-lang#88899 (Do not issue E0071 if a type error has already been reported) - rust-lang#88949 (Fix handling of `hir::GenericArg::Infer` in `wrong_number_of_generic_args.rs`) - rust-lang#88953 (Add chown functions to std::os::unix::fs to change the owner and group of files) - rust-lang#88954 (Allow `panic!("{}", computed_str)` in const fn.) - rust-lang#88964 (Add rustdoc version into the help popup) - rust-lang#89012 (Suggest removing `#![feature]` for library features that have been stabilized) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fix #87493
r? @estebank