`feature(frontmatter)` allows vertical whitespace where only horizontal whitespace is intended

[epage]

I tried this code:

---\vcargo
---

fn main() {}

I expected to see this happen: error

Instead, this happened: its accepted

This is a shortcoming of the RFC which used a loose term "whitespace" which tends to mean to rustc Pattern_White_Space when only the sub-category of horizontal whitespace was intended

Meta

rustc --version --verbose:

rustc 1.91.0-nightly (54c581243 2025-08-25)
binary: rustc
commit-hash: 54c581243c977c7662c949b5795c31147f8a60ed
commit-date: 2025-08-25
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

Backtrace

<backtrace>

[epage]

In fixing this, I'll need to update rust-lang/reference#1974

Unicode breaks Pattern_White_Space into three categories

• Line endings
• ignorables
• horizontal whitespace

Between the opening code fence and the info string and as trailing characters after the infostring or the closing code fence, I would presume we should only accept horizontal whitespace.

The question then is what to do about detecting line endings. I'm assuming we should have a clear definition so we

• Don't have multiple visual newlines where some look like part of the frontmatter but aren't (ie don't just allow whitespace+)
• Properly handle CR LF

I tried going through Newline Guidelines but I was lost in the generality.

We could start with just accepting (CR LF) | LF. Pattern_White_Space warns against using a subset of line endings. That warning eventually follows to line ending spoofing. The problem there sounds like its only an issue if any character is allowed but you only interpret a subset as line endings. Here, the code fences will have a defined set of allowed characters, so we should avoid that problem.

[mattheww]

Note that CRLF normalisation has already happened by the time frontmatter is being interpreted.