Excessive number of parser errors displayed

[jakobnissen]

The following (invalid) Julia program:

==????======??

Gives the following parser error on 1.9:

ERROR: LoadError: syntax: "==" is not a unary operator
Stacktrace:
 [1] top-level scope
   @ /tmp/foo.jl:1
in expression starting at /tmp/foo.jl:1

But unnecessarily throws multiple errors after #46372:

ERROR: LoadError: ParseError:
# Error @ /tmp/foo.jl:1:1
==????======??
└┘ ── not a unary operator
# Error @ /tmp/foo.jl:1:3
==????======??
# ╙ ── not a unary operator
# Error @ /tmp/foo.jl:1:4
==????======??
#  ╙ ── not a unary operator
# Error @ /tmp/foo.jl:1:5
==????======??
#   ╙ ── not a unary operator
# Error @ /tmp/foo.jl:1:6
==????======??
#    ╙ ── not a unary operator
# Error @ /tmp/foo.jl:1:7
==????======??
#     └─┘ ── not a unary operator
# Error @ /tmp/foo.jl:1:10
==????======??
#        └─┘ ── not a unary operator
# Error @ /tmp/foo.jl:1:13
==????======??
#           ╙ ── not a unary operator
# Error @ /tmp/foo.jl:1:14
==????======??
#            ╙ ── invalid identifier
Stacktrace:
 [1] top-level scope
   @ /tmp/foo.jl:1
in expression starting at /tmp/foo.jl:1

Although it can be debated, I think only displaying the first parser error is less confusing than displaying them all. In particular, I can imagine an input file which could throw hundreds of parser errors.
cc @c42f

[c42f]

We could just display the first one. That would generally be equivalent to the error emitted by the existing parser (except with precise source location info).

It's common that the latter errors aren't terribly useful (unless parser recovery is very, very good. Which obviously I'd like to do but it's a pile work which hasn't been done yet.) So maybe this would be better.

Maybe we could enable more verbose errors with a IOContext setting or something?

[jakobnissen]

I'm not too knowledgeable about this thing, so take my view with a grain of salt, but: I think there are three major use cases:

• Normal use: User does not want to configure anything. We should pick the overall nicest default, i.e. showing the first one to avoid spamming the terminal.
• Some power users may want to learn all syntax errors in a file, so they don't have to fix them one by one.
• For tooling, it's necessary to get all errors. However, these tools presumably will not rely on catching ParseErrors, but instead get the internal JuliaSyntax representation.

Perhaps the (hypothetical, and probably few) people in the second group should just use JuliaSyntax directly and not rely on the built-in parser if they want to customize parser errors?