[css-syntax-3] <hash-token> seems to get type ID for sequence "#-\" followed by EOF

[bathos]

In consume a token, the following steps are given for handling "#":

If the next input code point is a name code point or the next two input code points are a valid escape, then:

1. Create a <hash-token>.
2. If the next 3 input code points would start an identifier, set the <hash-token>’s type flag to "id".
3. Consume a name, and set the <hash-token>’s value to the returned string.
4. Return the <hash-token>.

The "would start an identifier" check confirms that the backslash of an escape is not followed by a newline, even if the first char is hyphen, but confirming that such a backslash is not followed by EOF is deferred to "consume an escaped codepoint", via "consume a name" (step 3). Although indicated to be an error, this still yields the name that has been processed so far, and this will happen after the type flag has already been set.

I’m not sure if it really matters in practice (perhaps this is even intentional), but it struck me as odd that (assuming I’m reading it correctly) this would mean that the sequence U+0023 U+002D U+005C EOF would produce a hash token whose type is set to ID, even though "-" isn’t a valid ID.

[tabatkins]

Hm, this seems to be a bug in check if two code points are a valid escape, actually. \EOF isn't a valid escape; it's a bare \ character. I think I need to check for that and return false.

It probably doesn't matter in practice, but it's definitely not intentional. I'll fix after getting confirmation from the WG.

[css-meeting-bot]

The Working Group just discussed <hash-token> seems to get type ID for sequence "#-\" followed by EOF, and agreed to the following resolutions:

• RESOLVED: Fix the check for a valid escape as described in #1821.

The full IRC log of that discussion

<dael> Topic: <hash-token> seems to get type ID for sequence "#-\" followed by EOF
<dael> github: https://github.com//issues/1821
<dael> TabAtkins: Def a bug, needs ahcnage. I won't do details, but if you have a malformed hash token at end of stylesheet it can sometimes report i t's valid even though it can try and escape an EOF.
<dael> TabAtkins: If you have a hash token with like a # symbol [missed]
<dael> TabAtkins: hash -/end of stylesheet it's [missed] This is a small bug to test if something is a valid escape. I don't check to see if second character is EOF. If I add that it won't have any additional consiquences.
<dael> TabAtkins: All bug were extemely minute. It's just that this is not what was intended in the spec.
<dael> florian: Go for it.
<dael> Rossen_: Any other opinions or concerns on this topic?
<dael> Rossen_: If not we can resolve.
<dael> Rossen_: obj?
<dael> RESOLVED: Fix the check for a valid escape as described in #1821.

[tabatkins]

Thanks for the report, @bathos! Fixed.

[astearns]

Syntax is in CR, so we should keep the issue open until we have a test.

Also the change, even though it's really minor, should be listed in the changes section.

[tabatkins]

Ah, right, it does belong in Changes.

(And yeah, as Elika expressed elsewhere, GitHub's natural flow of auto-closing issues based on commit message makes this "keep it open until testcase" thing kinda annoying. You have to tiptoe around mentioning the issue so as to not trigger one of the closing phrases.)