/(?<foo>A)\k<foo>/ is a syntax error unless using Annex B

[mysticatea]

Description: Adding 1 and 1 is two, but it should be...

From mysticatea/regexpp#23.

This is about /(?<foo>A)\k<foo>/ without u flag and without Annex B.

• 22.2.3.2.3 Static Semantics: ParsePattern ( patternText, u ) says "if no u flag, parse the pattern without N parameter, then if no syntax errors exist and named capturing groups exist, re-parse the pattern with N parameter."
• \k is a syntax error if no N parameter and no Annex B.

As a result, named capturing groups without u flag are always a syntax error.

I think IdentityEscape requires [~N] k or something like that in order to allow named capturing groups with no u flag.

eshost Output:

(I'm not sure about the environment without Annex B)

[bakkot]

It's a syntax error on the first pass, I agree, but that means that it will re-parse with the N parameter set, and when parsing with the N parameter we have the production AtomEscape :: k GroupName, which matches \k<foo> as in this example. Since it parses successfully on the second pass, it's allowed.

Edit: oh, except that it has to parse successfully on the first pass in order for the second pass to happen, I see. I think that's a spec bug, yes. (I wish we didn't have two grammars. As far as I'm aware every major implementation uses the Annex B grammar; the non-Annex B one is basically irrelevant and therefore does not get maintained properly.)

[mysticatea]

Yes, it skips the second pass if the first pass had a syntax error, and \k in the first pass is a syntax error.

Maybe, should both the N parameter and two passes parsing move to Annex B? Those look to be for Annex B behaviors.

[devsnek]

I think this is correct as specified. The first pass will parse \k<foo> as the atoms k < f o o >, not a syntax error.

[mysticatea]

@devsnek That's right in Annex B. But it's a syntax error in the spec core because the sequence \ k is not allowed.

[devsnek]

hm... is that the "but not UnicodeIDContinue" in the spec? i must have a bug in engine262

[bakkot]

is that the "but not UnicodeIDContinue" in the spec?

Yes. Keep in mind that's only there for the non-Annex B grammar, i.e. the one which is not used in actual implementations. (The Annex B variant does not have that restriction.)

[mysticatea]

mysticatea@7579276

That may be a candidate to patch this issue.

1. Remove two passes parsing from 22.2.3.2.3 Static Semantics: ParsePattern ( patternText, u ). It parses the pattern with [+N] always. This should be no problem because there are no other differences than allowing named backreferences.
2. Add an Annex B section to extend 22.2.3.2.3 Static Semantics: ParsePattern ( patternText, u ) to introduce two passes parsing for backward compatibility about \k.

[scole66]

This is also #1888, sort of.