On Jul 19, 2007, at 4:59 PM, Ian Lynagh wrote:
On Thu, Jul 19, 2007 at 04:17:28PM -0400, Peter Tanski wrote:
With no changes to the build system affecting Happy, I am getting
errors from compiler/parser/Parser.hs when using the Windows binary
of Happy 1.16. First, there is a parse error for the CPP #include
statement on line 6 (ghc is given the option -cpp, of course).
Can you please send the exact command line, error(s) and the Parser.hs
file?
Also, the output of running the same command with the -v flag may be
useful.
I don't know exactly what verbose option you wanted for Happy. I
added -v to ghc. Here is a summary:
[Original commands]:
/c/Haskell/happy-1.16/happy +RTS -K2m -RTS -agc parser/Parser.y
shift/reduce conflicts: 33
reduce/reduce conflicts: 1
/c/Haskell/happy-1.16/happy +RTS -K2m -RTS -agc parser/ParserCore.y
< snip ... >
/c/ghc/ghc-6.6.1/bin/ghc -H16m -O -istage1/utils -istage1/
basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -
istage1/rename -istage1/typecheck -istage1/deSugar -istage1/
coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore
-istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/
codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/
cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -
istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-
timing -I. -Iparser -ignore-package lang -recomp -Rghc-timing -H16M
'-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package
Cabal -fno-warn-incomplete-patterns -Onot -fno-ignore-interface-
pragmas -c parser/Parser.hs -o stage1/parser/Parser.o -ohi stage1/
parser/Parser.hi
parser/Parser.hs:6:1: parse error on input `#'
Notes:
* '-cpp' is hidden in '-Istage1 -cpp -fglasgow-exts', above.
* the parse error was caused by a space in front of #include
"HsVersions.h" in Parser.hs (note the error: parser/Parser.hs:6:1 --
column 1). Deleting the space removed that error.
* the version of gcc used by ghc-6.6.1 is gcc-3.4.2(mingw special);
cpp errors here are unrelated to the other errors I mentioned from
gcc 3.5 (gcc-3.5 (mingw special) does not seem to have a '-
traditional' flag).
[Modified Command]:
additions: -v
/c/ghc/ghc-6.6.1/bin/ghc -H16m -O -istage1/utils -istage1/
basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -
istage1/rename -istage1/typecheck -istage1/deSugar -istage1/
coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore
-istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/
codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/
cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -
istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-
timing -I. -Iparser -ignore-package lang -recomp -Rghc-timing -H16M
'-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package
Cabal -fno-warn-incomplete-patterns -Onot -fno-ignore-interface-
pragmas -c parser/Parser.hs -o stage1/parser/Parser.o -ohi stage1/
parser/Parser.hi -v
Note: there are some repeated commands in here, such as '-O' AND '-
Onot', but those were there before I made any Windows-native
modifications (I might have fixed them but those spidery Makefiles
are hard to debug).
[output]:
Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by
GHC version 6.6.1
Using package config file: c:\ghc\ghc-6.6.1\package.conf
wired-in package base mapped to base-2.1.1
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.1
package ghc-6.6.1 will be ignored due to missing dependencies:
Cabal-1.1.6.2
Hsc static flags: -static
Created temporary directory: C:/DOCUME~1/Sakon/LOCALS~1/Temp/ghc500_0
*** C pre-processor:
c:\ghc\ghc-6.6.1\gcc -Bc:\ghc\ghc-6.6.1\gcc-lib/ -E -undef -
traditional -v -I stage1 -I . -I parser -I c:/ghc/ghc-6.6.1\include -
I c:/ghc/ghc-6.6.1\include\mingw -D__HASKELL1__=5 -
D__GLASGOW_HASKELL__=606 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -
DUSING_COMPAT -Dmingw32_BUILD_OS=1 -Di386_BUILD_ARCH=1 -
Dmingw32_HOST_OS=1 -Di386_HOST_ARCH=1 -x c parser/Parser.hs -o C:
\DOCUME~1\Sakon\LOCALS~1\Temp\ghc500_0\ghc500_0.hscpp
Reading specs from c:/ghc/ghc-6.6.1/gcc-lib/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-
as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --
disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-
win32-registry --disable-shared --enable-sjlj-exceptions --enable-
libgcj --disable-java-awt --without-x --enable-java-gc=boehm --
disable-libgcj-debug --enable-interpreter --enable-hash-
synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
c:/ghc/ghc-6.6.1/gcc-lib/cc1.exe -E -traditional-cpp -quiet -v -I
stage1 -I . -I parser -I c:/ghc/ghc-6.6.1\include -I c:/ghc/ghc-6.6.1
\include\mingw -iprefix c:\ghc\ghc-6.6.1\../lib/gcc/mingw32/3.4.2/ -
isystem c:/ghc/ghc-6.6.1/gcc-lib/include -D__HASKELL1__=5 -
D__GLASGOW_HASKELL__=606 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -
DUSING_COMPAT -Dmingw32_BUILD_OS=1 -Di386_BUILD_ARCH=1 -
Dmingw32_HOST_OS=1 -Di386_HOST_ARCH=1 parser/Parser.hs -o C:\DOCUME~1
\Sakon\LOCALS~1\Temp\ghc500_0\ghc500_0.hscpp -undef
ignoring nonexistent directory "c:/ghc/ghc-6.6.1/../lib/gcc/
mingw32/3.4.2/../../../../include"
ignoring nonexistent directory "c:/ghc/ghc-6.6.1/../lib/gcc/
mingw32/3.4.2/include"
ignoring nonexistent directory "c:/ghc/ghc-6.6.1/../lib/gcc/
mingw32/3.4.2/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.2/include"
ignoring nonexistent directory "/mingw/mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
stage1
.
parser
c:/ghc/ghc-6.6.1/include
c:/ghc/ghc-6.6.1/include/mingw
c:/ghc/ghc-6.6.1/gcc-lib/include
End of search list.
*** Checking old interface for main:Parser:
*** Parser:
parser/Parser.hs:4536:6:
The last statement in a 'do' construct must be an expression
----------------
The above error is from the lines:
case happyOut77 happy_x_3 of { happy_var_3 ->
( do s <- checkValSig happy_var_1 happy_var_3;
return (sL (comb2 happy_var_1 happy_var_3) $ unitOL (sL
(comb2 happy_var_1 happy_var_3) $ SigD s)))}}
) (\r -> happyReturn (happyIn121 r))
Changing them to this:
case happyOut77 happy_x_3 of { happy_var_3 ->
( do s <- checkValSig happy_var_1
happy_var_3;
return (sL (comb2
happy_var_1 happy_var_3) $ unitOL (sL (comb2 happy_var_1 happy_var_3)
$ SigD s)))}}
) (\r -> happyReturn (happyIn121 r))
eliminates the incorrect indentation and the error. Note that the
only reasonably sure way of doing this is in Emacs.
Repeating the above command results in this error:
Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by
GHC version 6.6.1
Using package config file: c:\ghc\ghc-6.6.1\package.conf
< snip ... same output as before >
*** Checking old interface for main:Parser:
*** Parser:
parser/Parser.hs:5403:7: parse error on input `where'
The original code is (5400:5406):
(case unLoc happy_var_1 of
[qs] -> sL (getLoc happy_var_1) qs
qss -> sL (getLoc happy_var_1) [sL (getLoc happy_var_1)
(ParStmt stmtss)]
where
stmtss = [ (reverse qs, undefined)
| qs <- qss ]
)}
Changing it (again, in Emacs):
(case unLoc happy_var_1 of
[qs] -> sL (getLoc happy_var_1) qs
qss -> sL (getLoc happy_var_1) [sL (getLoc happy_var_1)
(ParStmt stmtss)]
where
stmtss = [ (reverse qs, undefined)
| qs <- qss ]
)}
Removes the error and gets me back to a recurrent problem I have been
having but is not related to this issue (Make, yes, version 3.81,
does not seem to be following the .depends files all the time so it
sometimes builds things out of order. Laborious process. I haven't
tried going back to Make 3.79.1 to see if that solves the problem.)
To sum up, it seems like Happy seems to output a few extra spaces in
odd places. I don't know if Happy varies depending on whether there
are embedded spaces in the original file (compiler/parser/Parser.y)
but that might be an issue. The reason I asked about this was that I
ran this build from source from HEAD, fully updated as of yesterday
morning. No one else seems to have encountered this problem but none
of the recent buildbots seem to have run under Mingw.
Thanks for looking into this.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc