Opened 7 years ago

Closed 15 months ago

Last modified 15 months 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 Difficulty: Unknown
Test Case: T984 Blocked By:
Blocking: Related Tickets:

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 7 years ago by simonmar

  • Architecture changed from x86 to Multiple
  • Milestone set to _|_
  • Operating System changed from Linux to Multiple
  • Priority changed from normal to low
  • severity changed from normal to minor

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 7 years ago by igloo

  • Test Case set to N/A

comment:3 Changed 7 years ago by simonmar

See also #999.

comment:4 Changed 6 years ago by simonmar

See also #459

comment:5 Changed 6 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:6 Changed 6 years ago by simonmar

  • Operating System changed from Multiple to Unknown/Multiple

comment:7 Changed 15 months ago by morabbin

  • Type of failure set to 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 15 months 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 15 months ago by igloo

  • Resolution set to fixed
  • Status changed from new to closed

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 15 months ago by igloo

  • Test Case changed from N/A to T984
Note: See TracTickets for help on using tickets.