-
Notifications
You must be signed in to change notification settings - Fork 62
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
Output parse errors for the Rust part of the build step #291
Conversation
Not... really, it seems. https://chat.openai.com/share/fa746c1a-403f-4611-bce7-7277e21114d8 |
An alternative hacky option we could always have is to treat validation as a "lint" step as part of the GitHub actions, as opposed to a feature of the core build process itself. Then we don't need the core build's parser to track errors in detail. Obviously it's less elegant, but potentially an option. Or in between -- the core build simply tracks whether there were errors, and then we do a separate lint/diagnostic pass to describe the errors given there were some. Either of these might be preferable to fully forking markup5ever_rcdom. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wrapped everything, and it seems to mostly work... not pretty, but it seems like the way to do things in Rust.
// Expose out the document and errors from the inner RcDom | ||
pub fn document(&self) -> &Handle { | ||
&self.dom.document | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like how this makes RcDomWithLineNumbers
have a different public API than RcDom
. Also sometimes I need to call clone()
on the result of this, and sometimes not. Probably there is something better I could do here.
But since it's a macro, `cargo fmt` can't get inside of it?
@jeremyroman @domfarolino for review if you all have time. |
This fixes #290, by outputting the parse errors encountered by the Rust build step's parser. Previously they were being stored in the
RcDom
instance'serrors
vector, and ignored. Now they are threaded through to the finalio::Result
, and then output bymain()
.The hardest part of this was adding line numbers to the errors. Doing this necessitated creating a wrapper for
RcDom
, which I inventively calledRcDomWithLineNumbers
, which implementsTreeSink
with two methodsparse_error
andset_current_line
given custom behavior, while the other many methods just delegate toRcDom
's implementation.(There doesn't appear to be any better way to do this in Rust, currently. If you search for "rust delegation" you'll find lots of discussion of the problem, and various solutions which work if you can modify the delegated-to class, i.e.
RcDom
in our case. But nothing seems to work if the delegated-to class is in third-party code.)Additionally, this enables
exact_errors
as a parser option, which provides slightly more information in a couple of cases related to character references.Original PR description
I spent some time trying to address #290
This sort of works. (Although the code needs a lot of cleanup; probably we want to bubble the errors to the top level instead of printing them immediately.)
However, the biggest problem is that there is no line number information. So the output is terrible:
The upstream issue is servo/html5ever#48 .
I think this is possible to fix if we do something where we override the
RcDom
sink so that instead of doing nothing whenset_current_line
is called, it stores that information somewhere. And then I guess we'd override theparse_error
implementation to use that stored information.Figuring out how to create some version of
RcDom
with these overrides seems likely to be something Rust supports, but I'm running out time for playing with Rust today. If anyone else wants to pitch in, patches are appreciated./cc @noamr @jeremyroman