Closed hjorthjort closed 2 years ago
I managed to trace the problem to somewhere here https://github.com/kframework/k/blob/master/kernel/src/main/java/org/kframework/parser/inner/kernel/KSyntax2Bison.java#L190
for (Sort sort : iterable(module.allSorts())) -> 2152
for (Production prod : Optional.ofNullable(prods.get(sort)).orElse(java.util.Collections.emptyList())) -> subsets from over 70.000 productions
That's a lot. So I think it does finish but it's just going to take a long time.
The Bison parser is meant to be used to parse programs, but in the list of productions I see everything from domains.md included. I think that's the first thing that needs to be sorted.
Let me know if you need help with that.
Suggestions:
@dwightguth should have a chance at some point to profile this.
Another possibility: maybe we can disable the slow code when doing just LR parsing (and only enable it when doing GLR parsing).
This is probably fixed. If you're still having issues feel free to reopen though.
K Version
Description
Running
kompile
with--gen-[glr-]bison-parser
seems to never result in a bison file being generated, and the frontend doesn't terminate.Input Files
I haven't managed to get this in minimized form yet. But it is reproducible in https://github.com/kframework/wasm-semantics on the
hjorthjort
branch.Reproduction Steps
Clone the KWasm semantics, then:
Expected Behavior
It's possible (likely) that the KWasm semantics are not suited for Bison parsing as it stands currently, so we expect Bison failures. However, we expect there to be a Bison file produced in the temp directory (
.kompile-...
) which we can expect, or to Bison to report errors.Instead, it seems the call to generate the Bison file never terminates.
80955.jstack.txt