Opened 11 years ago

Closed 4 years ago

Last modified 4 years ago

#984 closed bug (fixed)

Syntax error shows in the wrong position

Reported by: guest Owned by:
Priority: low Milestone:
Component: Compiler (Parser) Version: 6.4.2
Keywords: syntax parse case do Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: T984
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

This bug concerns the behaviour of GHC on erroneous programs. GHC recognizes the illegal syntax, but shows an unrelated error.

This problem is best illustrated in the following code:

f _ = do
        x <- computation
        case () of
                _ ->
                        result <- computation
                        case () of () -> undefined

The error in this code is the missing "do" keyword on line 5, and the compiler should suspect this when seeing the "<-" on line 6. However, GHC gives the following error:

bug.hs:3:8: Parse error in pattern

This is misleading, since the line number is incorrect, and the syntax error (as well is line 3) is unrelated to patterns.

Change History (10)

comment:1 Changed 11 years ago by simonmar

Architecture: x86Multiple
Milestone: _|_
Operating System: LinuxMultiple
Priority: normallow
severity: normalminor

In a sense, GHC is telling you something completely sensible here, but it wasn't what you were expecting. Let me add some parentheses to your code:

f _ = do
        x <- computation
        (case () of
                _ ->
                        result) <- computation
                        case () of () -> undefined

See now? You've written a binding statement (pattern <- expr), where the pattern is in fact a case expression, so GHC complains that the case expression is not a valid pattern. Indeed, if you use -ferror-spans, you'll see that the span of the error covers the parenthesised case expression.

It might be difficult for us to do anything better here. We kind-of want the case expression to eliminate the possibility of a binding statement from the parser, but there's no easy way to do that in GHC's parser.

comment:2 Changed 11 years ago by igloo

Test Case: N/A

comment:3 Changed 11 years ago by simonmar

See also #999.

comment:4 Changed 9 years ago by simonmar

See also #459

comment:5 Changed 9 years ago by simonmar

Architecture: MultipleUnknown/Multiple

comment:6 Changed 9 years ago by simonmar

Operating System: MultipleUnknown/Multiple

comment:7 Changed 4 years ago by morabbin

Type of failure: None/Unknown

Confirmed behavior is still in GHC 7.6.1:

Orac:~/work/ghc $ cat > test.hs
f _ = do
        x <- computation
        case () of
                _ ->
                        result <- computation
                        case () of () -> undefined
Orac:~/work/ghc $ ghci test.hs
GHCi, version 7.6.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( test.hs, interpreted )

test.hs:3:9: Parse error in pattern: case () of { _ -> result }
Failed, modules loaded: none.
Prelude> 

Mark as dup of #459?

comment:8 Changed 4 years ago by ian@…

commit d2169af1b312c698ade627c26416a7527f1c46b1

Author: Ian Lynagh <ian@well-typed.com>
Date:   Fri Feb 1 15:23:39 2013 +0000

    Improve an error message; fixes #984
    
    This code:
        f _ = do
                x <- computation
                case () of
                        _ ->
                                result <- computation
                                case () of () -> undefined
    Now gives this error:
        Parse error in pattern: case () of { _ -> result }
        Possibly caused by a missing 'do'?

 compiler/parser/Parser.y.pp  |   22 +++++----
 compiler/parser/RdrHsSyn.lhs |  108 ++++++++++++++++++++++--------------------
 2 files changed, 70 insertions(+), 60 deletions(-)

comment:9 Changed 4 years ago by igloo

Resolution: fixed
Status: newclosed

We now get the error above. Only time will tell whether this causes more confusion (in cases where the suggestion is wrong) than it resolves.

comment:10 Changed 4 years ago by igloo

Test Case: N/AT984
Note: See TracTickets for help on using tickets.