Add unstable frontmatter support by epage · Pull Request #137193 · rust-lang/rust (original) (raw)

There seem to be many conflicting requirements that led to this confusing situation that we're trying to understand and you're trying to explain to us.

This list doesn't seem quite right to me but perhaps I'm missing some of the details here. After reading the RFC, my understanding is that:

• Rust (the language) now supports a single frontmatter that may optionally appear after the shebang line. This has no effect whatsoever on the compiler and should be entirely ignored except for the purpose of lexing/parsing to find the closing delimiter.
• Cargo supports reading this frontmatter section and interpreting it.

The RFC says:

As cargo will be the first step in the process to parse this, the responsibility for high quality error messages will largely fall on cargo.

I agree that is true of errors originating from the content of the frontmatter block, but the block itself is a syntactic element of the language now and should be properly treated for the purposes of error reporting just like block comments are. We will want to have proper error reporting for things like unclosed frontmatter sections even if Cargo explicitly told rustc where the file content should start because a user could always place one later in the file and we want to give them a useful error message.

Therefore, I think the core requirement from the compiler side is that the frontend should recognize the frontmatter block and produce errors if the block is not immediately at the start of the file, the file contains more than one block at any position or the block is not closed. Whether that happens in the lexer or the parser, I'm not sure of the best approach.

Since Cargo also needs to locate and parse the frontmatter block, it seems wasteful to implement duplicate error reporting for malformed frontmatter. I would suggest that if Cargo cannot successfully parse the frontmatter block itself (eg it does not find 3 or more - characters immediately after the shebang line that are terminated by the same number of characters), it should just invoke rustc and let rustc handle the error reporting for the malformed block.

I agree that we need proper error reporting for syntactically invalid frontmatter blocks, but I don't personally think that has to be done in this very PR provided one or more bugs are opened to track that work and marked as open issues on the tracking issue and there is no regression in quality of other error messages.

cc @Noratrieb since you also suggested an implementation for this feature on that Zulip thread 🙂