fix(parse): Limit frontmatter fences to 255 dashes

[epage]

Like raw string literals. As discussed on #148051.

Part of #136889

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
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

[Kivooeo]

Looks good, but... This error message seems a bit verbose, maybe we shouldn't show all this "-"'s or something, like, just say something "hey, this line is a bit longer than it should be, can you fix it"

[epage]

For raw string literals, we show

error: too many `#` symbols: raw strings may be delimited by up to 255 `#` symbols, but found 256
  --> $DIR/too-many-hash.rs:4:19
   |
LL | ... = r###################################################...######################################;
   |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

I'm assuming this isn't being collapsed down because it is multi-line (@Muscraft maybe a potential future change for annotate-snippets).

Maybe if I switch the span to just the opening, it will look better.

[epage]

I tried only showing the one line and it doesn't get snipped in the middle like too-many-hash.rs.

Is there a way for me to have the span without it getting rendered in my error or are you recommending I remove the span completely?

[Kivooeo]

Is there a way for me to have the span without it getting rendered in my error or are you recommending I remove the span completely?

Honestly I don't have exact or better solution that I can suggest you here, just wondering about how can we make it less verbose

Can you show output without span completely to just see how it looks

[epage]

I just pushed

error: too many `-` symbols: frontmatter openings may be delimited by up to 255 `-` symbols, but found 256
  --> $DIR/fence-too-many-dashes.rs:1:1
   |
LL | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

I'll now update it to no span

[Kivooeo]

upd to prev message:

I like the output from too-many-hash.rs, it looks like a good solution for this PR as well!

But again, I can't help you with implementing or something since I don't know much about this in particular

[epage]

Without a span

error: too many `-` symbols: frontmatter openings may be delimited by up to 255 `-` symbols, but found 256

error: aborting due to 1 previous error

not pushed yet as I'm looking how to handle this in the ui test

[epage]

Found it, ~?

[Kivooeo]

I personally think that no span is fine in case we couldn't adopt approach from fence-too-many-dashes.rs

I may take a look tomorrow on how it was made in there for hashes, it's really looks cool

I also have a conjecture about how it was made (but it's just a wild guess): it was just hard coded - suggestion always have 38 hashes on right side and 58 on left side despite amount of actual hashes, the only thing is depends on amount of hashes is last part in error message

error: too many `#` symbols: raw strings may be delimited by up to 255 `#` symbols, but found 256

But still, it looks like an actual span, maybe some magic with BytePos... Yeah I will take a look on implementation for this just out of curiosity

[epage]

the error emitter / annotate-snippets has logic to shrink code snippets to fit on a screen. I'm unsure why it isn't activating in this case. I had wondered if there is an issue with the emitter assuming an infinite screen size for tests but I didn't see too-many-hash.rs overriding a screen size.

[davidtwco]

LGTM - this is an pretty niche error so I don't think it needs to be perfectly worded and we can always improve it in future

View changes since this review

[davidtwco]

@bors r+ rollup

[bors]

📌 Commit 70b6d77 has been approved by davidtwco

It is now in the queue for this repository.