Improve build.sh error messages

[kenrussell]

Attempting to make a fairly small recent change, build.sh reports the following error:

$ ./build.sh
Checking if html-build is up to date...
Looking for the HTML source (set HTML_SOURCE to override)...
Found /home/kbr/src/kenrussell/whatwg/html (alongside html-build)...
Linting the source file...
Downloading caniuse data...
Downloading mdn-spec-links/html.json...
Pre-processing the source...
Started httpserver on port 8080

Local wattsi is not present; trying the build server...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9472k 100 152 100 9472k 72 4519k 0:00:02 0:00:02 --:--:-- 4521k
Parsing MDN data...
Parsing caniuse.com data...
Processing caniuse.com data...
Parsing...
Parse Error: (94117,77) parse error while closing p element

There were errors. Stopping.

Line number 94117 in "source" isn't anywhere near the changes I made. It seems clear the error's in a generated file but I can't figure out which one. Could the error messages from the build script please be improved? Diff is attached.

create-imagebitmap-options-diff.txt

[domenic]

Do you have any concrete ideas for improvement? In general, tracing what part of a HTML diff caused a parse error is a pretty hard problem.

[domenic]

It seems clear the error's in a generated file but I can't figure out which one.

Sorry, I missed that. No, that is not what happened. What happened is that there's an error in the source file, but it's possible it took until line 94117 for the parser to figure that out, because of the "pretty hard problem" I mentioned.

[kenrussell]

OK, it seemed that the parse error happened on a processed version of the file.

I found the error - a missing </dfn> - would that not be possible to catch earlier, perhaps with a preprocessor?

Also found that missing a:
data-x="dom-createImageBitmapOptions"
attribute in a code tag caused another hard to track down error:

Error: missing for topic "createimagebitmapoptions" explicitly from element containing "createImageBitmapOptions"; previous heading contents are "8.9 Images"
Error count: 1

Possible to generate a line number for this error?

[sideshowbarker]

I found the error - a missing </dfn> - would that not be possible to catch earlier, perhaps with a preprocessor?

It seems like if we implemented such a preprocessor, it would need to be an HTML parser — but the thing is, the error message in this case is actually coming from an HTML parser: specifically, the HTML parser that’s part of wattsi.

So what we’d actually want to do is to make the wattsi HTML parser report a specific message indicating that there’s an unclosed element (the dfn element) at line NNN.

The (Java-based) validator.nu HTML parser actually does that; it emits an error: Unclosed element “dfn” message. So it’s possible we could make the wattsi HTML parser do it too.

I’ve raised issue whatwg/wattsi#96 for that.

[sideshowbarker]

Line number 94117 in "source" isn't anywhere near the changes I made. It seems clear the error's in a generated file but I can't figure out which one.

What’s supposed to happen is that you get two error messages with two different line numbers.

The first error message is that one cited in the question, which has the line number of the generated file — and which as you noted isn’t a useful line number in helping you find the problem in the source.

But after that you should be seeing this message:

There were errors. Running again to show the original line numbers.

…followed by a second error message that identifies a line number in the actual source.

If you’re not seeing that error message, then it seems there’s been a regression in the build tooling, so we have a build bug we need to fix — specifically, in the part that gets the results back from the remote wattsi build server.

I’ll try to see if I can reproduce that problem.

[sideshowbarker]

OK yeah I was able to quickly reproduce the problem of that second error report not being emitted.

I’ve raised #190 for that and will try to help get it fixed asap.

In the meantime, note that you can get the expected error-reporting behavior by building and installing and running wattsi locally. See https://github.com/whatwg/wattsi#building-wattsi for the how-to

[domenic]

Thanks @sideshowbarker; my apologies @kenrussell for not being as dilligent in my investigation as I should have been. I'm glad we're on an optimistic path here.

[kenrussell]

No worries. Thanks @domenic and @sideshowbarker for looking into this.