Raw quoted literals

The FLS models raw string literals as follows, in §2.4.6.2 (fls_usr6iuwpwqqh):

RawStringLiteral ::= r RawStringContent

RawStringContent ::= NestedRawStringContent | " ~[\r]* "

NestedRawStringContent ::= # RawStringContent #

This is close to the form used in the Reference.

Problem 1

This model makes forms like r"a" r"b" ambiguous: there could be a single RawStringLiteral or two RawStringLiterals here (rustc says there are two).

That means a MacroInvocation like m!(r"a" r"b") is underspecified, and a "longest match" principle as suggested in #589 would give the wrong answer.

The ambiguity is still present in forms using hashes, for example r#"a"# r#"b"#.

Worse, this model accepts things that rustc rejects: it (unambiguously) accepts m!(r"a"b").

Similar things are true for raw byte string literals (§2.4.2.2, fls_jps9102q0qfi) and Raw C String Literals (§2.4.3.2, fls_g4ldypf3rl6i).

Problem 2

Rustc (since I think 1.61) has a limit of 255 hash characters on each side of NestedRawStringContent, NestedRawByteStringContent, and NestedRawCStringContent, but the FLS doesn't document that restriction.

See rust-lang/reference#1180.

Start with §2.4.6.2 and the referenced identifiers fls_usr6iuwpwqqh, fls_jps9102q0qfi, and fls_g4ldypf3rl6i. Compare the FLS productions with rustc behavior and the Rust Reference issue cited in the report. Done means the grammar no longer accepts or ambiguously parses the described forms and documents the 255-hash limit for all three literal kinds.