If we are going to generate this file, I think the output is expected not to be placed in repository but loaded form CI cache.

I think it's fine to check it into the repo; while different cause it's a bootstrapping issue, lalrpop itself checks its generated parser into its repo, I feel like it's a decently common practice. While I do really like the idea of having everything necessary for the build be generated at build-time, that comes in conflict with the reality of longer build times. If it verifies that the generated file is up-to-date, I don't think I really see an issue with it.

I think that's not because of lalrpop convention but a typical compiler bootstrapping issue. If they don't bundle generated parser to their repository, people who don't have lalrpop yet will never can generate lalrpop parser by themselves.

I am not sure if I am little bit out of trends, but as I understand, traditional software communities only commit the original source to the repository but attaching the configuration result to their source code distribution. We usually now don't distribute source code anymore. So we'd better to invest more on easier build from source, but still we can avoid to bundle the generated output itself when possible.

practically, once after building the parser first, it will not take long time again because contributors and users never edit parsers. So this is concerning about CI, not the users or contributors, right?
then I think we can build this from CI and cache the result. There will be another dependency, but it will not be a big deal after first build because cache will be shared between the different CI runs.

Another advantage to including the parser in the repository is that we can see how much of it is covered by our test suite.

That point makes sense. We need rustfmt in that case.