Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors during compilation of grammar.go are reported as grammar.go rather than grammar.peg #99

Open
kpixley opened this issue Jul 28, 2020 · 5 comments

Comments

@kpixley
Copy link

kpixley commented Jul 28, 2020

This is a nuisance when used, eg, with emacs compilation mode.

lex/yacc/byacc/bison/et all use line number preprocessor lines in the generated output to refer back to the original source file even when it's the C compiler that is reporting the error. I don't know how to do that in go but I presume that it must be possible. If not, it should be.

@breml
Copy link
Collaborator

breml commented Jul 31, 2020

This is by design. Pigeon does not care about the Go code in the PEG file but only about the PEG grammar. Go does not know anything about PEG and therefore can not report an other position for the error than in the generated grammar.go file.

If you have a lot of Go code used by the parser, it does make sense to move this code as functions into a separate .go file. Have a look at https://github.com/breml/logstash-config/tree/master for an example. There find logstash_config.peg with the grammar, logstash_config.go with the generated parser and logstash_config_helper.go with all the functions used by the generated parser. E.g. in https://github.com/breml/logstash-config/blob/master/logstash_config.peg#L30 the function config(...) is called, which is defined in https://github.com/breml/logstash-config/blob/master/logstash_config_helper.go#L21. In the generated parser you find the function call here: https://github.com/breml/logstash-config/blob/master/logstash_config.go#L7109

@breml
Copy link
Collaborator

breml commented Jul 31, 2020

That being said, Go does not have a preprocessor so there are no preporcessor lines that could point back to the original source file.

@kpixley
Copy link
Author

kpixley commented Jul 31, 2020

Not quite true.

https://golang.org/src/cmd/compile/doc.go#L153

@kpixley
Copy link
Author

kpixley commented Jul 31, 2020

I will likely take a crack at this at some point. I believe the task is relatively straightforward and superficial. But anyone else who is up for it is welcome to beat me to it.

@breml
Copy link
Collaborator

breml commented Aug 3, 2020

@kpixley Thanks for the hint on the //line compiler directive. I did not know about this. I started to look into adding this to pigeon. It is possible, but there are some challenges to solve, especially if there is some code (beside of the package directive) in the init section (like here). The problem is, that the correct position of the declarations after the imports do not match with the peg file, because the imports are added by pigeon automatically after the successful generation of the parser. But I am confident, that there is a solution for this as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants