Open eddyb opened 6 years ago
eddyb
commented
6 years ago One issue is figuring out how the terminals are actually encoded - if we do strings, who tokenizes/lowers the strings into something that can match the input? cc @centril
EDIT: resolved, for now, by hardcoding proc_macro tokens as an option, and using Pat: From<scannerless::Pat> for the tokenziation/lowering.
est31
commented
5 years ago sadly, that PR left columns disabled windows
FYI, it's because of Visual Studio expecting debug info to either only contain line number, or a full (start line, start column, end line, end column) span range, otherwise it's buggy: https://github.com/rust-lang/rust/issues/42921#issuecomment-330902694
This information is present in rustc already. However at least back when I made the PR, there was no LLVM support for range based spans.
At least it should be one of the provided options, alongside separate code generation.
A huge benefit is being able to use
Spans from the grammar syntax, inside the generated code.Given https://github.com/rust-lang/rust/pull/51980, breakpoints should be possible at a given line + column, assuming debuggers support them (sadly, that PR left columns disabled windows).
We could them be putting breakpoints and stepping through grammar rules, in whatever syntax variant they were specified by the user!
By strategically naming some variables to e.g.
input, we can also make debuggers able to show the currently remaining input to parse, potentially at zero cost to the implementation. (But showing "current input line/column", without on-demand computation, would incur a penalty).EDIT: @eternaleye points out that breadth-first is not ideal for debugging. We could have depth-first as part of a "debug mode", or just separately toggleable (even at runtime; not sure if "free" though).