suggest ! instead of erroneous not on if/while block parse failure

[zackmdavis]

Impressing confused Python users with magical diagnostics is probably
worth this very slight (only 25ish lines) extra complexity in the
parser?

FIXME comments have been left to note that the formatting after
autofixing the suggestion (with rustfix or an RLS-powered IDE) won't
be optimal. (It doesn't look like any of the existing CodeMap methods
make it easy to adjust the span.)

Unfortunately, the parser doesn't seem smart enough to know which of the "try placing this code inside a block" and ! suggestions is correct. (Also, the function that sets the "inside a block" suggestion doesn't and shouldn't know about the condition, so canceling that suggestion if the ! suggestion is issued would require a new clear-suggestions method on Diagnostic/DiagnosticBuilder, which I didn't want to write until we're convinced it's necessary.) The last function in the new UI test demonstrates a case in which the "block" suggestion is right and the ! suggestion is wrong.

Resolves #46836.

r? @estebank

[estebank]

LGTM, minor suggestions.

[estebank]

Can you also modify parse_block so that this suggestion is not given if the next token is an open brace, like in these cases? The suggestion as is is more likely to be wrong than right.

[estebank]

You could merge the cond.span with the next span, get the snippet and synthesize a span that does include the whitespace (in a similar way as suggested in #47574 (comment)).

[estebank]

re: span, same as below

[bjorn3]

Could you please place the try replacing identifier `not` with the negation operator help message first, as I think it is the most likely solution when you use not.

[petrochenkov]

This is a quite limited ad hoc way to check for not used as !.
I'd expect it to work as normal parsing would work.

• You start parsing an expression (priority is important, should be the same as for ! EXPR, i.e. parse_prefix_expr).
• If the current token is not and ...
• The next token is not in the "can continue expression after ident" set (you can look through enum Token and make this set, or I can do it tomorrow), then ...
• Report a non-fatal error, recover not as ! and continue parsing.

This would cover tests from this PR and more.

[petrochenkov]

Looks a bit too wordy for a label, I'd personally use something "try replacing not with !", but as a minimum the word "identifier" can be removed here.

[zackmdavis]

The motivation was to emphasize that not has no special meaning in Rust-the-language (it's just another ordinary variable/identifier), even if rustc-the-compiler is (after this PR) nice enough to try to figure out notice what you meant, but I agree that ceteris paribus, longer messages are worse.

[petrochenkov]

The next token is not in the "can continue expression after ident" set

So, the set (already inverted) is Pound | Ident(..) | Literal(..) | NtIdent(..) | NtExpr(..) | NtBlock(..) | NtPath(..) (this is a subset of fn can_begin_expr).

[zackmdavis]

This is a quite limited ad hoc way to check for not used as !. I'd expect it to work as normal parsing would work.

Yeah, that's a good point.

You start parsing an expression [...] So, the set (already inverted) is

Thanks for the pointer! I can probably look into doing it this way later today or tomorrow.

[zackmdavis]

I've made some exciting progress on the parse-prefix approach, but in addition to producing awesome diagnostics, my code also misparses some legitimate uses of not as a variable name. 😞

I'm pretty busy with a new dayjob lately, so I likely won't be able to look at this again for a week.

[petrochenkov]

@zackmdavis

also misparses some legitimate uses of not as a variable name

For example?
I certainly could miss something when making that token list.
Maybe something in macros?

[zackmdavis]

@petrochenkov

For example?

zmd@ReflectiveCoherence:~/Code/rust$ cat correct.rs 
fn main() {
    let not = 2;
    let _really = not;
}
zmd@ReflectiveCoherence:~/Code/rust$ rustc correct.rs # sane rustc
zmd@ReflectiveCoherence:~/Code/rust$ echo $?
0
zmd@ReflectiveCoherence:~/Code/rust$ rustc +stage1 correct.rs # my delusional work-in-progress build
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, or an operator, found `}`
 --> correct.rs:4:1
  |
3 |     let _really = not;
  |                      - expected one of 7 possible tokens here
4 | }
  | ^ unexpected token

error: aborting due to previous error

I certainly could miss something when making that token list.

I think it's more likely to be an off-by-one-token error in my recovery logic, an error which we can pray will be revealed in the cold light of info! statements and careful thought. (But not tonight.)

(This commit is only using ident/literal/pound as the can't-continue-expression-after-ident set, because of the conjunction of my not feeling confident that I understand how the Nts work, and their being a different enum which would require another match and the fact that leaving tokens out of the set should only decrease the number of situations in which we recover without affecting the correctness of the cases where we do try to recover.)

[petrochenkov]

an off-by-one-token error

Ah, of course, the next token lookup is done with look_ahead, not next_tok.

[zackmdavis]

continued: #49258