WebIDL binding generator won't parse IDL grammar.
Closed this issue · 10 comments
At a directory that contains a .wasm file and a spasm/modules subdirectory:
webidl.lnk --bindgen
(webidl.lnk points to to webidl.exe but it's working directory is where the .wasm file is)
Output:
Reading definitions...
Failed to parse input. Are you sure it is valid WebIDL?
Failed to parse input. Are you sure it is valid WebIDL?
Failed to parse input. Are you sure it is valid WebIDL?
[...snip...]
Failed to parse input. Are you sure it is valid WebIDL?
Failed to parse input. Are you sure it is valid WebIDL?
Failed to parse input. Are you sure it is valid WebIDL?
Generating js bindings for dmodule.wasm
Writing bindings file
spasm/modules/bindings.js appears, but is empty. Not even the comments at the top.
I debugged a bit myself, and for me it seems that WebIDL grammar parser does not start working. I think so because rewriting the "Failed to parse input" line to writeln("Failed to parse input. Are you sure it is valid WebIDL? Details:\n", document.failMsg) yields failmsg lines like this:
Failed to parse input. Are you sure it is valid WebIDL? Details:
Failure at line 0, col 0, expected "end of input", but got "enum Audio"
Failed to parse input. Are you sure it is valid WebIDL? Details:
Failure at line 0, col 0, expected "end of input", but got "dictionary"
Failed to parse input. Are you sure it is valid WebIDL? Details:
Failure at line 0, col 0, expected "end of input", but got "typedef (I"
Are you running it on the original WebIDL definitions, or have you modified anything?
I run it with dub run spasm:webidl -- --bindgen, any particular reason you decided to make a .lnk? Not that it would matter much, because it seems it can find the definitions as well as your .wasm file.
The error messages from Pegged aren't the best. In fact, during development I got the Failure at line 0, col 0 error you are seeing a lot, even though often the error was in the middle of the file. (It could be that I have defined the grammar in a way that when the parser finds an error it backtraces completely until it is at the start of the file and concludes the whole thing is wrong. Still the messages haven't been much help to me.
Are you running it on the original WebIDL definitions, or have you modified anything?
I run it with
dub run spasm:webidl -- --bindgen, any particular reason you decided to make a.lnk? Not that it would matter much, because it seems it can find the definitions as well as your.wasmfile.
original (Fix exports for ldc 1.15 version) (except the debug msg), but downloaded by git, not dub (To allow pushing possible fixes made upstream). That's also the reason for the .lnk instead of dub run.
The error messages from Pegged aren't the best. In fact, during development I got the
Failure at line 0, col 0error you are seeing a lot, even though often the error was in the middle of the file. (It could be that I have defined the grammar in a way that when the parser finds an error it backtraces completely until it is at the start of the file and concludes the whole thing is wrong. Still the messages haven't been much help to me.
But does it also always claim that it's excepting "eof"?
It is probably because you are on windows, where git replaces line endings to match windows'. That might be something the grammar has trouble with.
You can try running dos2unix on the definition files, and see if that fixes it.
But does it also always claim that it's excepting "eof"?
That is a result of the error backtracing I talked about. The main rule in the grammar is defined as (Definition)* eoi (simplified). So, zero-or-more Definition's followed by end-of-input. Pegged can't parse the first definition so it backtraces, assumes there are zero, and tries to find end-of-input.
I have found the problem. It was indeed the parser not accepting windows newlines. I have pushed a fix, version 0.1.11. Please try.
Also, I have adjusted the WebIDL grammar to require at least one definition in the input. This will produce better error messages (but will fail parsing empty files).
Well, there is still the annoyance that you need to create the spasm/modules directory yourself, and some strange error messages:
Reading definitions...
Error: cannot find type DedicatedWorker to exposed constructor FileReaderSync on.
Error: cannot find type DedicatedWorker to exposed constructor ProgressEvent on.
Error: cannot find type DedicatedWorker to exposed constructor XMLHttpRequest on.
Generating js bindings for dmodule.wasm
Writing bindings file
However, the bindings file seems to contain definitions that match the ones I did by hand last time. The fact that I had already made the bindings by hand is the reason I was too lazy to test WebIDL further three weeks ago :D.
And +1 for change for better error messages.
Hmm, it should create that folder for you. See https://github.com/skoppe/spasm/blob/master/webidl/source/app.d#L80
If that hasn't been working I would like to understand how. It could be because of the way you have set it up.
The error messages you are seeing are meant for the D bindings. Indeed, it would be a good idea to hide them when generating js glue code.
Hmm, it should create that folder for you. See https://github.com/skoppe/spasm/blob/master/webidl/source/app.d#L80
If that hasn't been working I would like to understand how. It could be because of the way you have set it up.