C-string literals

Problem 1

The definition of SimpleCStringContent seems to have become garbled.

The definition is as follows:

SimpleCStringContent ::=
    AsciiEscape
  | SimpleStringCharacter
  | StringContinuation
  | UnicodeEscape

while §2.4.3.1:1 (fls_fnwQHo7twAom) reads:

A simple c string literal is any Unicode character except characters 0x0D (carriage return), 0x22 (quotation mark), 0x5C (reverse solidus) and 0x00 (null byte).

I think the intent was for SimpleStringCharacter to read SimpleCStringCharacter, and for §2.4.3.1:1 to define "simple c string character".

See also #604 for a problem with using AsciiEscape here.

Problem 2

It isn't sufficient to exclude character 0x00 from the definition of a simple c string character: a \u or \x escape that represents character 0x00 is also a lexing-time error.

Problem 3

RawCStringContent should also exclude character 0x00. This is already filed as part of #532.

Problem 4

§2.4.3.1:3 (fls_Ae7LM4Wg0NA7) reads:

The type of a simple string literal is &'static core::ffi::CStr.

§2.4.3.2:2 (fls_9nJHsg9dCi66) reads:

The type of a simple string literal is &'static core::ffi::CStr.

I think these paragraphs were intended to say "the type of a simple c string literal" and "the type of a raw c string literal", respectively.

Start by locating the definitions of SimpleCStringContent and RawCStringContent, then read §2.4.3.1 and §2.4.3.2 at anchors fls_fnwQHo7twAom, fls_Ae7LM4Wg0NA7 and fls_9nJHsg9dCi66. Compare the related context in #604 and #532. Done means the C-string grammar, null-character handling, and literal type descriptions consistently match the intended distinctions.