Skip to content

Conversation

epage
Copy link

@epage epage commented Aug 21, 2025

Tracking issue: rust-lang/rust#136889

@@ -8,6 +8,7 @@
- [Input format](input-format.md)
- [Keywords](keywords.md)
- [Identifiers](identifiers.md)
- [Frontmatter](frontmatter.md)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not stable yet: rust-lang/rust#136889

@@ -8,6 +8,7 @@
- [Input format](input-format.md)
- [Keywords](keywords.md)
- [Identifiers](identifiers.md)
- [Frontmatter](frontmatter.md)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put this under "Lexical structure" because this shebang is there

Comment on lines 7 to 8
FRONTMATTER?
InnerAttribute*
Item*
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used comments as my guide which were mostly SCREAMING_CASE. Unsure when things should be SCREAMING_CASE vs UpperCamelCase.

Comment on lines 7 to 8
FRONTMATTER?
InnerAttribute*
Item*
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite shebang's not having being here, I assumed I should put FRONTMATTER here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason shebang isn't there is that shebangs are ignored at the start of any file, not just in the file which defines a crate.

If that's true for frontmatter too, input-format.md might be a better place to say how frontmatter.md fits in.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit confusing.

input-format.md is specifically under the section for lexical analysis.

crates-and-source-files.md includes what looks like its the AST but its specifically scoped to the crate root. r[crate-items] talks generally about any rust source file.

So, like shebang, I'll leave this out but this feels like something that could be cleaned up.

Comment on lines 39 to 40
r[frontmatter.body]
The body of the frontmatter may contain any content except for a line starting with as many or more dashes (`-`) than in the fences.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This follows the RFC rather than rustc's current implementation, see rust-lang/rust#141367

@@ -4,6 +4,7 @@ r[crate]
r[crate.syntax]
```grammar,items
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside: it took me a while before I found the appropriate documentation for this.

I quickly went to CONTRIBUTING.md but skipped over the link to the authoring page because it was at the end of the intro. I skimmed the sections until I found "Adding Documentation" which seemed to describe my situation but I found no link.

Eventually I found authoring.md and thankfully I read thoroughly enough to notice the "Grammar" section at the bottom. At that point, I was mostly able to interpret the results to figure out what I needed (e.g. the limitations of ~, what to search for to understand how to do footnotes).

As noted at https://github.com/rust-lang/reference/pull/1974/files#r2292171963, it doesn't really give a style guidance on casing.

Comment on lines 6 to 19
FRONTMATTER ->
FRONTMATTER_FENCE INFOSTRING? LF
(FRONTMATTER_LINE LF )*
FRONTMATTER_FENCE[^matched-fence] LF

FRONTMATTER_FENCE -> `---` `-`*

INFOSTRING -> XID_Start ( XID_Continue | `.` )*

FRONTMATTER_LINE -> (~INVALID_FRONTMATTER_LINE_START (~INVALID_FRONTMATTER_LINE_CONTINUE)*)?

INVALID_FRONTMATTER_LINE_START -> (FRONTMATTER_FENCE[^escaped-fence] | LF)

INVALID_FRONTMATTER_LINE_CONTINUE -> LF
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was unsure whether to create a new rule for non-newline whitespace and specify that in every location or not.

@ehuss ehuss added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Aug 21, 2025
@epage epage force-pushed the frontmatter branch 2 times, most recently from 161b0fa to 61afc85 Compare August 22, 2025 13:54
Comment on lines +6 to +19
FRONTMATTER ->
FRONTMATTER_FENCE INFOSTRING? LF
(FRONTMATTER_LINE LF )*
FRONTMATTER_FENCE[^matched-fence] LF

FRONTMATTER_FENCE -> `---` `-`*

INFOSTRING -> (XID_Start | `_`) ( XID_Continue | `-` | `.` )*

FRONTMATTER_LINE -> (~INVALID_FRONTMATTER_LINE_START (~INVALID_FRONTMATTER_LINE_CONTINUE)*)?

INVALID_FRONTMATTER_LINE_START -> (FRONTMATTER_FENCE[^escaped-fence] | LF)

INVALID_FRONTMATTER_LINE_CONTINUE -> LF
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking more on this, I feel like I should be explicit where frontmatter whitespace is allowed.

I assume I should then pull out a whitespace grammar rule to build on that.

Comment on lines +6 to +19
FRONTMATTER ->
FRONTMATTER_FENCE INFOSTRING? LF
(FRONTMATTER_LINE LF )*
FRONTMATTER_FENCE[^matched-fence] LF

FRONTMATTER_FENCE -> `---` `-`*

INFOSTRING -> (XID_Start | `_`) ( XID_Continue | `-` | `.` )*

FRONTMATTER_LINE -> (~INVALID_FRONTMATTER_LINE_START (~INVALID_FRONTMATTER_LINE_CONTINUE)*)?

INVALID_FRONTMATTER_LINE_START -> (FRONTMATTER_FENCE[^escaped-fence] | LF)

INVALID_FRONTMATTER_LINE_CONTINUE -> LF
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something that i don't make explicit is CR. In most places that can be chalked up to whitespace except for INVALID_FRONTMATTER_LINE_START and INVALID_FRONTMATTER_LINE_CONTINUE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants