-
Notifications
You must be signed in to change notification settings - Fork 39
Description
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.