bedrock2 fails with a syntax error on Windows about bedrock2 HOT 9 CLOSED

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.

from bedrock2.

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.

from bedrock2.

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

from bedrock2.

@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.

from bedrock2.

Removing \r does not produce an error on Linux.

from bedrock2.

OK, I will do some tests on Windows over the weekend.

from bedrock2.

Fixed in 7c6a089

from bedrock2.

@andres-erbsen : out of curiosity of a multi platform Coq maintainer: what was the root cause? It is not obvious from the fix.

from bedrock2.

There are two issues:

1. 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
2. coq/coq#16576

from bedrock2.