fix(parser): Disallow CR in frontmatter

[epage]

T-lang came back on the stabilization PR (#148051) asking for CR to be disallowed
with the intention of preventing confusing situations where a stray CR
looks like a line break.

If need arises for it, this could always be turned into a lint at a
later point.

Part of #136889

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[joshtriplett]

Given that text-direction-codepoint-in-literal and text-direction-codepoint-in-comment are lints, I do think it makes sense for this and the similar error in raw strings to be a lint as well. I doubt that anyone is going to allow it, but I still think it makes sense to not be a hard error.

That said, I don't think switching this from a hard error to a lint should be a blocker. Let's go ahead with the simple version of this change to unblock stabilization.

[epage]

@joshtriplett this only prevents the use of CR and not the text direction code points.

However, this is making me more against doing CR in the first place if CR as an error is just a "simple version" of what we actually want.

If these should be lints, they should be lints in the tool that owns processing the frontmatter. If we have them as lints in rustc, we then have both tools running those lints as they likely have a format outside of the frontmatter that should also lint and that would be generic code across the files. Having both lint can lead to a bad user experience including:

• disagreeing on lint levels and the user having to manage that
• potentially showing duplicate warnings

If we error on CR now and then remove it because tools should do it, that is a subtle change that could easily get lost in communicating back out to those tools.

[epage]

I've moved this to a draft until this is sorted out so we don't accidentally merge this

[Kivooeo]

r? me