bedrock2 fails with a syntax error on Windows
JasonGross opened this issue · 9 comments
See https://github.com/mit-plv/fiat-crypto/runs/8126696409?check_suite_focus=true#step:10:1216:
COQDEP VFILES
File "D:/a/fiat-crypto/fiat-crypto/rupicola/bedrock2/bedrock2/src/bedrock2/Bytedump.v", characters 2646-2646: Syntax error
This might or might note be related to coq/platform#178 (comment)
I've created #272 to test compatibility with Windows and Mac
Character 2646 on master is 0x1a, "substitute". Why this is a syntax error on Windows is beyond me.
More generally, that file is indeed burdensome because it contains all 256 bytes, verbatim, as notations for the corresponding bytes in coq.
It might be a git issue. On Windows with default git settings of most Windows git distributions I came across a checkout will do LF -> CRLF replacement. So unless you (or someone else) did something to avoid this, you wont get the same file as on Linux. You can try on Linux with the file run through linux to dos conversion. In CI you might want to compute a hash of the file to see if it is unmodified.
https://github.com/mit-plv/bedrock2/runs/8252014741?check_suite_focus=true#step:6:191 2646 == 0xa50 + 6 -- looks like it's 0x1a on Windows as well, with just a LF at the end of that line as far as cygwin hexdump is concerned.
Edit: sha256 computed by windows tools on CI and linux tools on my computer also matches https://github.com/mit-plv/bedrock2/runs/8252328897?check_suite_focus=true#step:3:14
@andres-erbsen : Looks indeed good. Github has reasonable defaults then and we can exclude this as root cause (which is important since it can also lead to local / CI deviations).
Another thought: it might be that coq reads files on Windows in text mode (which is the default for all character based I/O on WIndows - one has to give special, from Unix deviating options, to avoid this). I always though that this replaces CR/LF with LF, which would not hurt since this file has no CR/LF combinations (only a single CR). But it might be that it just strips CR characters altogether. Can you see if you get the same error on Linux if you strip the CR character in the file?
If this is the root cause, one could either escape the CR somehow or one would have to disable text mode in Coq.
Removing \r does not produce an error on Linux.
OK, I will do some tests on Windows over the weekend.
Fixed in 7c6a089
@andres-erbsen : out of curiosity of a multi platform Coq maintainer: what was the root cause? It is not obvious from the fix.
There are two issues:
- coq/coq#16470 It seems like Coq isn't capable of parsing files containing ASCII substitute, IIRC (charcter 26 / 0x1A), or ends the file at Escape (27 / 0x1B) on Windows
- coq/coq#16576