Lrlex codegen - #661
Conversation
| } | ||
| } | ||
|
|
||
| pub(crate) enum LexerBuildEnvError {} |
There was a problem hiding this comment.
I had forgotten to double check this, for some reason I thought a variant had been added to this,
but that was LexerCodegenError.
| ) | ||
| let code_gen = build_env | ||
| .code_generator(self.rule_ids_map, env!("VERGEN_BUILD_TIMESTAMP")) | ||
| .map_err(|e| match e {})?; |
There was a problem hiding this comment.
This wacky map_err/match was necessary at the time because ? couldn't convert the error.
I figured by the time I was done we'd have a variant added. Although I must admit I'm a bit uncertain what the type returned is, I assume it's inferring ! or some such.
There was a problem hiding this comment.
It's a new one on me! I imagine it's inferring the unit type ().
There was a problem hiding this comment.
I'd be surprised if () would convert into Box<dyn Error> via ? though, which is why I think it must be !
or Infallible.
There was a problem hiding this comment.
I see what you mean. I guess the ultimate point here is that the closure passed to map_err can't ever be called because e is of a type that cannot be constructed.
| f.write_str(&match self { | ||
| Self::InvalidRustIdentifierModName { mod_name, error } => { | ||
| format!( | ||
| "Invalid mod_name '{mod_name}' is not a valid rust identifier due to '{error}'" |
There was a problem hiding this comment.
I think I'd drop the "Invalid " prefix: the rest of the message makes clear it's an error.
There was a problem hiding this comment.
Done in 741cecf
I checked lrpar/codegen, and the latter didn't include "Invalid" already, so the two errors looked in sync.
| ) | ||
| let code_gen = build_env | ||
| .code_generator(self.rule_ids_map, env!("VERGEN_BUILD_TIMESTAMP")) | ||
| .map_err(|e| match e {})?; |
There was a problem hiding this comment.
It's a new one on me! I imagine it's inferring the unit type ().
2 participants
This is an attempt at lrlex codegen, in the style of the recently added lrpar codegen module.
One thing this doesn't do is change the
CTTokenMapBuilder.This tries to sequence the move over a couple of commits, with the first commit just generating module and ownership structure. With each subsequent commit moving one aspect of code generation, until it's all in the codegen module.
One slightly suprising thing was the placement of lexerdef within the
LexerBuildEnv, because we need it to generate therule_ids_map, with that we can wait to generate theLexerCodegenutil therule_ids_mapis built, and pass it in to thecode_generatorfunction, this is a slight departure from thelrparapi, which merely took atimestamp.Edit: One thing that the additional
rule_ids_mapparameter I immediately notice is that unlikeBuildEnvArgsand other builder patterns, it's hard for us to add add an additional parameter should we need one. I wonder if we should considerLexerCodegenArgs?