Skip to content

Scrabsha/html errors #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Scrabsha/html errors #1

wants to merge 12 commits into from

Conversation

scrabsha
Copy link
Owner

@scrabsha scrabsha commented Sep 7, 2021

No description provided.

Our goal is to generate HTML pages representing the error emitted by the
compiler.

This commit adds a -Z html-output flag to rustc. When passed, the
compiler will emit its errors in HTML format in stderr. This flag
conflicts with any value of the error-format argument.

As a bonus, the compiletest crate has been updated to handle
the // html-output compiler directive. Adding this flag will invoke the
compiler with the -Z html-output flag and compare its output with a
corresponding .html file, similarly as .stderr files.
@scrabsha scrabsha force-pushed the scrabsha/html-errors branch from 47fbb79 to b33ccc3 Compare September 7, 2021 08:38
Ok(()) => {}

Err(e) if e.kind() == ErrorKind::WriteZero => return Ok(idx),
Err(e) => return Err(e),
Copy link

Choose a reason for hiding this comment

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

In practice I don't know if it actually matters (I am assuming that you've run tests and observed it work; I haven't tried to work on the compiler before and so haven't actually downloaded or run this myself), but I think this clause loses the current .next() segment if it is not able to write into self.inner, so a retry would skip it. If it works as-is, then I wouldn't worry about it.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Actually it is not a problem if we don't write the current .next(), as long as we exit early and return the correct amount of bytes we actually wrote.

But the good news is that you're highlighting the fact that we should not return an error if we wrote something to the sink. I do need to fix that.

@myrrlyn
Copy link

myrrlyn commented Sep 15, 2021

Okay so I've played with writing this as a standalone module and while I have some minor practical differences as a result of our prior conversation and seeing your solution first, ultimately I don't think I have anything worth bringing up as an actual change. The Peekable wrapper could be used instead of a local Option, or you could hold the original &str or &[u8] and pull out the SplitInclusive behavior we actually want (.position() and .filter().map()), but these don't affect the API.

I refuse to bikeshed this to a standstill before it even hits rustc. It's behavior I want the compiler to do and you made the compiler do it. Excellent. I think there could be some internal simplification (for instance, I got by without an EscapedHtml enum, and just used (src_bytes_consumed, segment): (usize, &[u8])) but, again, that's getting deep into the weeds when the important part is that it correctly emits text that is safe to place directly into an HTML template.

@scrabsha
Copy link
Owner Author

@myrrlyn

Thank you so much for taking time to review this piece of code. It's much appreciated.

I tried to remove the remove the trimmed_escaped field and make iter a Peekable<SplitInclusive<...>>, but failed. I think my level in Rust is not good enough to write it cleanly.

I'm wondering how you removed the EscapedHtml enum: how do you know if you must call write or write_all in the Write implementation? Could you post a playground link or something? I don't think I'll implement it though, as the goal is also to stay simple and easy to review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants