Description
This is a tracking issue for the RFC "frontmatter" (rust-lang/rfcs#3503).
The feature gate for the issue is #![feature(frontmatter)].
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
- Implement the RFC for rustc: in progress
- Implement the RFC for r-a
- Adjust documentation (see instructions on rustc-dev-guide)
- Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
- Stabilization PR (see instructions on rustc-dev-guide)
Test coverage prior to stabilization
In the following, the RFC text in its accepted form will be referred to as the "accepted text".
- (Before stabilization) we should add a
run-maketest that exercises how cargo and rustc works together w.r.t. frontmatter, depending on what the final cooperation scheme we end up using. - (Before stabilization) we should add a positive smoke test to check that
rustfixis able to account for frontmatters (or properly ignore), i.e.//@ run-rustfix.
Unresolved Questions
- What level of quality of error messages is a blocker for stabilization? See also Add unstable frontmatter support #137193 (comment)
- In Implement RFC 3503: frontmatters #140035, the initial (compiler) impl already tries to provide diagnostics for the most common erroneous usages.
- However, it might be worth refining how the diagnostics responsibility of reporting invalid frontmatters get shared between
$tools<-> rustc.
- How does frontmatter interact with
-Zunpretty? See discussions in Add unstable frontmatter support #137193 (comment). - How will various tools (
rust-analyzer,rustfmt,cargo,clippy) handle frontmatter (and interop w/rustc)? Will parsing support (or ability to ignore frontmatter) be a stabilization blocker (re. toolchain UX)? For all of them, for a subset of the tools? - Should frontmatter be outright banned in doctests? Consider these examples: Implement RFC 3503: frontmatters #140035 (comment).
- (Needs explicit design decision prior to stabilization) Should whitespace be permitted between the starting dashes and the infostring? E.g. would
--- cargobe accepted? In Implement RFC 3503: frontmatters #140035 and the accepted text, whitespace between starting dashes and the infostring is permitted.
Implementation history
Initial implementations
(Significant) changes since the RFC was accepted
Frontmatter opener vs infostring starting with - character grammar ambiguity
The accepted text has a grammar ambiguity in the case where the infostring starts with a -.
- The same
-character is used to delimit the frontmatter "opener"---. - The opener can have more than 3
-characters to support escaping nesting of---s within the frontmatter. - However, infostrings described in the accepted text can also begin with
-, making it ambiguous as to whether it's a 3--opener +--starting infostring, or if it is a 4--opener + infostring.
Remedy: we can require the infostring to begin with Unicode XID_Start, then permit subsequently characters in the set { XID_Continue, . }. I.e. (illustrative)
- infostring = term *
- term = { all characters - ( whitespace | ',' ) }
+ infostring = XID_Start , { (XID_Continue | '.') } * ;See discussions at #140035 (comment).
- This can be further relaxed in the future (carefully) if it does not introduce more ambiguities.
- RFC initially required infostring to consist of identifier, but was relaxed to support
.in e.g.file.ext(see RFC: Syntax for embedding cargo-script manifests rfcs#3503 (comment)).
Illustrative grammar
#140035 (comment) (with start and end dashes >3 - characters and must match in - count):
frontmatter_start = dashes , { whitespace } * , infostring , { whitespace } * , '\n' ;
frontmatter_end = dashes , { whitespace } * , '\n' ;
infostring = XID_Start , { (XID_Continue | '.') } * ;
dashes = "---" , { '-' } * ;