Source lines

Some of the FLS's legality rules work with a notion of lines in a source file:

First, there are three rules in §2.2 (fls_fgnllgz5k3e6) which provide definitions:

§2.2:3 The text of a source file is divided into lines.

§2.2:4 A line is a sequence of zero or more characters followed by an end of line.

§2.2:5 The representation of an end of line is tool-defined.

Then the section on comments (§2.5, fls_q8l2jza7d9xa) makes use of them as follows:

§2.5:2 A block comment is a comment that spans one or more lines.

§2.5:3 A line comment is a comment that spans exactly one line.

§2.5:12 Block comments, inner block docs, and outer block docs shall extend one or more lines.

§2.5:13 Line comments, inner line docs, and outer line docs shall extend exactly one line.

As I understand it, the aim of the FLS is currently understood to be to model the behaviour of one particular version of rustc, not to define more general rules for implementations of Rust.

If that's right, I think §2.2:5 (fls_go25sisi5fdp) should give a more explicit rule rather than saying "tool-defined".

It isn't clear to me whether the section on comments is assuming that rustc defines the end of line to be LF, or to be either LF or CRLF, so I think in any case the paragraph should be modified to be explicit about that. See also #592.

The syntax rules provided for comments don't make use of this notion of lines (the rules are very close to those in the Reference, which doesn't include such a notion). Possibly it would be clearer to drop this aspect of the FLS altogether.

I think §2.5:2 (fls_qsbnl11be35s) and §2.5:12 (fls_uze7l7cxonk1) are content-free: they can't mean to say that these comments must take up whole lines (because that isn't true), but that leaves them not providing any information or imposing any restriction.

I think §2.5:3 (fls_nayisy85kyq2) and §2.5:13 (fls_gy23lwlqw2mc) should also be unnecessary if the syntax rules are written carefully: what those paragraphs say should follow directly from those rules. But at present I think that isn't quite true.

§2.5 (fls_q8l2jza7d9xa) has the following syntax rules:

InnerLineDoc ::= //! ~[\n \r]*

OuterLineDoc ::= /// (~[/] ~[\n \r]*)?

These are treating CR as parallel to LF; they are saying that the line comment stops before the first CR, rather than treating a CR on the line as an error (as rustc does).

So at the moment the syntax says that /// a ␍ b (where ␍ indicates a CR control character) is analysed as a line comment followed by an identifier b. That means the program has an outer line doc which does not span exactly one line and the legality rule §2.5:13 (fls_gy23lwlqw2mc) says the program is non-conforming, which is the right answer.

(The Reference has equivalent syntax rules and no equivalent of §2.5:13, so it has a bug here.)

Start with the cited §2.2 and §2.5 rules, especially the four line-comment and documentation paragraphs, and review related issue #592. Compare the stated line-ending behavior with the shown comment syntax rules and rustc behavior. Done means the FLS either explicitly defines the relevant line endings and consistent comment constraints or removes the unnecessary notion of lines.