For doing things like running the codegen process on in-editor yacc and lex files, It would be helpful
if we could run the codegen process passing it e.g. an input string, and perhaps a mutable output string to where codegen writes.
This could hopefully allow us someday to integrate into rust-analyzer and/or run rusts static analysis tools on the embedded actions within
.y files. Currently the codegen process assumes it can read the grammar from the filesystem, and then write the generated code to the filesystem. Requiring you to save the files before static analysis can occur.
Below are my ideas on this, it seems like it should be possible to do this without breaking CTParserBuilder, and CTLexerBuilder.
I'm open minded about other ideas, these are just the thoughts that occur to me.
- Add a module like
lrpar::codegen::CodeGenerator, and similar for lrlex
- Some of the ctbuilder options in both lrpar (serialisation_format) and lrlex (regex), both (mod_name) affect codegen.
- Some of the ctbuilder.rs in both affect parsing (yacckind, etc).
- Other options seem entirely builder specific like
grammar_path, and `output_path.
To handle 2. and 3. we need some way to pass settings from the Builders to the CodeGen.
The thought is we could stick these into a struct like CTBuilderSettings, or CodeGenSettings.
CTParserBuilder and CTLexerBuilder could own one of these, and passing a reference to the code generator.
Things that want to bypass CTParserBuilder and avoid filesystem interaction can construct these directly.
But mostly CTParserBuilder could become a wrapper around these two structures, plus it's own settings and cargo integration behaviors (printing to stderr, environment variables).
For doing things like running the codegen process on in-editor yacc and lex files, It would be helpful
if we could run the codegen process passing it e.g. an input string, and perhaps a mutable output string to where codegen writes.
This could hopefully allow us someday to integrate into rust-analyzer and/or run rusts static analysis tools on the embedded actions within
.yfiles. Currently the codegen process assumes it can read the grammar from the filesystem, and then write the generated code to the filesystem. Requiring you to save the files before static analysis can occur.Below are my ideas on this, it seems like it should be possible to do this without breaking
CTParserBuilder, andCTLexerBuilder.I'm open minded about other ideas, these are just the thoughts that occur to me.
lrpar::codegen::CodeGenerator, and similar forlrlexgrammar_path, and `output_path.To handle 2. and 3. we need some way to pass settings from the Builders to the
CodeGen.The thought is we could stick these into a struct like
CTBuilderSettings, orCodeGenSettings.CTParserBuilderandCTLexerBuildercould own one of these, and passing a reference to the code generator.Things that want to bypass CTParserBuilder and avoid filesystem interaction can construct these directly.
But mostly CTParserBuilder could become a wrapper around these two structures, plus it's own settings and cargo integration behaviors (printing to stderr, environment variables).