Closed liluyue closed 6 months ago
The most user friendly errors that we currently have can be seen by running the nimbleparse
tool (unless using a hand-written lexer)... But it has been a bit difficult trying to find the right abstraction boundary to be able to leverage this from within the CTParserBuilder
used by cargo. However that still doesn't have a counterexample generator, but should at least show a bit more info about source locations of the conflicts.
I doubt the reliability of the nimbleparse. I use test the nimbleparse by calc exmaple :
markdown_parser git:(master) ✗ nimbleparse src/calc.l src/calc.y a.txt
src/calc.y: [Error] Missing ':' at line 3 column 6
but calc actually is not bad:
%start Expr
%%
Expr -> Result<u64, ()>:
Expr '+' Term { Ok($1? + $3?) }
| Expr '-' Term { Ok($1? - $3?) }
| Term { $1 }
;
so,I hope can find the state table for analysis the problem
It looks like you need to pass the -y grmtools
flag to nimbleparse, in this case to set the yacc format.
Because the original format isn't expecting the type -> Result<u64, ()>
that is valid.Thanks!
I also notice that the output of nimbleparse in the above error that you quoted doesn't include inline source code. This was added in https://github.com/softdevteam/grmtools/pull/439 and contains some more information about conflicts. It seems like that hasn't made it into a release. So perhaps it would be good to try grmtools git (I'm assuming you are currently running a crates.io version). Also interested in feedback on the errors that produces.
Understood, thank you for the reminder
There's now a new release of grmtools out with this functionality in. Thanks @ratmice!
I execute "cargo run",get info :
It is too vague,I wish can get below info for I fix the issue: