Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#2046 closed feature request (duplicate)

Parse errors for mismatched brackets are awful

Reported by: NeilMitchell Owned by:
Priority: normal Milestone:
Component: Compiler (Parser) Version: 6.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


ghci> [foo
<interactive>:1:4: parse error (possibly incorrect indentation)

The parser error messages for incorrect brackets are awful. A much better message would be:

ghci> [foo
<interative>:1:1: bracket opened but not shut

i.e. refer to bracket issues, and say where the bracket started.

I realise this may be difficult within the current parser, but a simple post-processor for syntax errors could perhaps detect such errors. Also, while the { character and reasonably be about indentation, the others are much less likely to be.

Change History (5)

comment:1 Changed 10 years ago by tim

I agree with Neil. It has been a lifelong annoyance for me to not know whether that error message is *actually* due to incorrect indentation, or to mismatched brackets. I have no idea how hard it would be to improve this in the current parser, but from a user point of view, it can be enormously frustrating.

comment:2 Changed 10 years ago by simonmar

Component: CompilerCompiler (Parser)
difficulty: Unknown
Resolution: duplicate
Status: newclosed

This is a long-standing problem, see #459 :-)

The "possibly incorrect indentation" message arises because the token the parser is looking at is one that was generated by layout. I honestly don't know whether there's anything we can easily do to improve matters in the context of the current parser, but I suspect not.

Anyway, I propose to look at it next time I'm in the area.

comment:3 Changed 10 years ago by NeilMitchell

A simple fix would be that if the parsing fails with a "possibly incorrect indentation" style warning, you rerun the lexer over the original file, without inserting symbols based on indentation. After you have this raw lexical stream, you do a simple scan with a bracket stack and check everything matches up. If it doesn't, you give a very precise error indicating exactly which bracket was not match. If it does, you fall back to the same situation we have now.

Assuming the lexer is sufficiently modular, this should be easy (at a guess), and not complicate any other part of the compiler.

comment:4 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:5 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple
Note: See TracTickets for help on using tickets.