Distinguish delim kind to decide whether to emit unexpected closing delimiter

[xizheyin]

Fixes #138401

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

r? compiler

[chenyukang]

I changed this part last year, will review this PR later.

r? @chenyukang

[chenyukang]

I think this solution introduces some kind of regression on other scenarios(such as the cases I commented).

Maybe we should consider this as a special corner case and provide a special diagnostic for it, it is the pattern that one delimiter is missing the openning delimiter(it's in the inner part), except for this everything is ok, so we should suggest something like "missing openning delimiter ....".

such as:

{ ... {. ) ... }...} missing a inner (
{ ... [ ], ] ...} missing a inner [

[chenyukang]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[xizheyin]

Thanks, I will revise it soon!

[xizheyin]

This seems like quite a lot of changes, I'll comment in the code to make it easier to REVIEW.

In the first commit, I added the test.

In the second commit I did some clean. I changed a variable name, the original name was inaccurate, I used open_delimiters instead of open_braces for identifying blocks, one should compare spans, not just brace'{'.

In the third commit, I make a distinction between the different delimiters before triggering a unexpected closing delimiter error. But I found that missing open delim note is what triggers in unexpected closing delimiter error.
Therefore, to emit missing open delim note, I also moved missing open delim note to
mismatched closing delimiter error, which can be emitted without delaying to
unexpected closing delimiter error.
And I moved function make_unclosed_delims_error
to src/lexer/diagnostics.rs for clean. And some other clean.

[xizheyin]

I've combined them into one line so it's more aesthetically pleasing.

mismatched closing delimiter, may missing open `(`

Since the mismatched closing delimiter note and the unclosed delimiter note are related, it may be the better to keep it.

[xizheyin]

Thanks for the guidance, I've learned much, this diagnosis involves a lot of regression testing so it's a little harder to deal with.

[chenyukang]

this new hint is unnecessary, how can we remove it?
since the root cause is only a missing '(', which we have already reported.

[xizheyin]

estebank suggest me to add some hint. the closing ) may match this {, so we can get the general scope of how to add [. But I understood it. It should be "the mismatched closing ) may be meant for this opening delimiter".
See #138554 (comment) #138554 (comment)

[chenyukang]

even if we change the words into the mismatched closing ) may be meant for this opening delimiter, it will also make a similar confusion like the origin issue #138401 described?

user will be confused why ')' meant for this opennning '{' ?

[chenyukang]

this remind me maybe we should reconsider whether the original issue is worth to be resolved, the original hint in the issue description:

error: mismatched closing delimiter: `)`
 --> ...\test.rs:1:27
  |
1 | pub fn foo(x: i64) -> i64 {
  |                           ^ unclosed delimiter
2 |     x.abs)
  |          ^ mismatched closing delimiter

seems somehow confused, but it helps narrow the scope of span, if there are multiple nested scope, I think it's helpful in those scenarios.

[chenyukang]

similar one.
it's better to remove it.

[chenyukang]

this hint may makes user try to add a '}', while the root cause is we should remove the { where old diagnostic reported.

[xizheyin]

This is because we merged the mismatched diagnostic into another diagnostic. The old diagnostic gave the wrong information because the real reason was the missing {} in { [].len() }. However, I think this PR is meant to address the duplicate error message, this false message can be addressed in another PR. :)

[xizheyin]

I need to clarify the direction of the modification.
As I understand it, for the current modification, I need to change the hint as suggested in this #138554 (comment) .
For the other, such as #138554 (comment) , it seems to need to be addressed in another PR, as this is not what #138401 is proposing, and it seems to be a new issue.

[chenyukang]

I need to clarify the direction of the modification. As I understand it, for the current modification, I need to change the hint as suggested in this #138554 (comment) . For the other, such as #138554 (comment) , it seems to need to be addressed in another PR, as this is not what #138401 is proposing, and it seems to be a new issue.

per my understanding, the issue #138554 (comment) refers to is introduced by the code in this PR, not a old one?

[xizheyin]

Oh! That makes sense. This seems to require finer control.

[xizheyin]

There should be no regression this time.

The only thing I did was this: if the missing open hint is reported in report_missing_open_delim, it will not generate a separate mismatched error, reducing a lot of confusing errors. Meanwhile, this doesn't eat up the information in the mismatched error.

[xizheyin]

This time, I reserve the mismatched error when the situation is like {[)}.
And I remove the mismatched error only when close_delim_err, which means double close delims.

Meanwhile, I remove duplicate missing open ... for this delimiter in this file contains an unclosed delimiter error because mismatched errors have already emitted it.