[ ghc-Bugs-412524 ] String gap fails for some chars

[noreply@sourceforge.net]

Bugs item #412524, was updated on 2001-03-30 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=108032&aid=412524&group_id=8032

Category: Compiler
Group: None
>Status: Closed
Priority: 5
Submitted By: Andrew Moran (morabbin)
Assigned to: Nobody/Anonymous (nobody)
Summary: String gap fails for some chars

Initial Comment:
String gap fails with "error in character literal" 
when the first char on the new line after the '\' is
not alphanumeric (I think; I haven't done a detailed 
study).  For example, this is okay:

    "jkaehfjhsdg\
    \hgshgt"

but this is not:

    "kjsdhgkjhrtht\
    \(kjsdhkghgh"

I've attached a program with three putStrLns.  The 
first fail under 4.08.2; the last succeeds.


----------------------------------------------------------------------

>Comment By: Simon Marlow (simonmar)
Date: 2001-04-02 03:16

Message:
Logged In: YES 
user_id=48280

The examples work for me, with both 4.08.2 and 4.11.  One 
example causes an 'error in character literal', but it 
really is an error:

	  putStrLn "abc\
		   \hkjfxhhgfh"  -- \

the '\h' isn't a valid escape sequence.

Perhaps you are using CPP on the file?  CPP is known to 
have bad interactions with string gaps, see

http://www.haskell.org/ghc/docs/latest/set/options-
phases.html#C-PRE-PROCESSOR

----------------------------------------------------------------------

Comment By: Andrew Moran (morabbin)
Date: 2001-03-30 10:04

Message:
Logged In: YES 
user_id=184906

A little more testing reveals that the first example above 
(not in StringGapBug.hs) probably wouldn't work.  It seems 
that it only works for n, t, b, and other legal escape 
characters.  I have attached another program demonstrating 
this; it has 12 putStrLns whose arguments are gappy 
strings.  The first 11 each begin the new line with a 
character legal according charesc in the report; the last 
begins with a 'c'.  Only the last fails with "error in 
character literal".  So it seems pretty clear that the 
lexer is checking whether \<char> is a legal escape when it 
should be recignizing the \ as beginning the next segment 
of a gappy string.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=108032&aid=412524&group_id=8032