Improve mismatched delimiter error message

[josevalim]

Stealing from Rust:

error: mismatched closing delimiter: `)`
   --> /Users/jose/OSS/explorer/native/explorer/src/encoding.rs:120:12
    |
120 |     unsafe { Term::new(env, list)) }
    |            ^ unclosed delimiter  ^ mismatched closing delimiter

[lucassouzamatos]

Hello @josevalim I am currently working on this improvement, okay?

[lucassouzamatos]

I am thinking about that improvement, and I have a question about short lines. In this example foo(() make sense has an indicator to column on top, like above?

    |      ˇ another error here
  1 | foo(()
    |    ˆ random error here

[josevalim]

Good point. I would probably always have the opening one on top and the closing one on the bottom.

[lucassouzamatos]

@josevalim that example makes sense for the case?

** (TokenMissingError) nofile:1:7: missing terminator: ) (for "(" starting at line 1)
    |    ˇ unclosed delimiter
  1 | foo(()
    |       ˆ missing delimiter

I am working under the currently mismatching error message, but with the example about Rust, we don't have a similar case.

** (SyntaxError) nofile:1:8: unexpected token: )
    |
  1 | foo(()))
    |        ˆ

[josevalim]

Missing delimiter is tricky because if item happens at very distinct lines. I would rather focus on the mismatched ones. We may need to add an special exception for them.

[lucassouzamatos]

@josevalim I made some tests using the "end" delimiter, and my results were this, looks good?
If it is good I will create a PR with my changes and you can follow my changes in other clauses too.

defmodule MyApp do
  def one do
  end

  def two
  end
end

nofile:6:2: mismatched closing delimiter: end
HINT: it looks like the "end" on line 6 does not have a matching "do" defined before it

    |
  6 |   end
    |  ^ mismatched delimiter

[josevalim]

@lucassouzamatos this issue is not about the case you brought up because in your case we got a token when none was expected. This issue is about the case where we expected one and we got another! :)

[lucassouzamatos]

@josevalim of course, i did not notice that, I will follow on this side. But, it is a good improvement adding the snippet in that cases like I specified?
Maybe for other PR? Or can I just ignore it?

[josevalim]

I am not sure because in those cases we are just guessing the error is there and we could be pointing at the wrong thing.

[viniciusmuller]

Hey @josevalim, what do you think the diagnostic we would print for this should look like?

[josevalim]

@viniciusmuller i think for this one we will need to show a very specific snippet/diagnostic without reusing the existing infrastructure.