Vladislav Zavialov

OK, I've reproduced this on another machine. Seems to be a non-deterministic failure, sensitive to build order. Could you try this sequence of commands? ``` $ cabal build happy-frontend $...

The `bootstrap` flag is turned on either way. You can also confirm this by specifying it manually ``` cabal build happy-frontend -f +bootstrap cabal build all -f +bootstrap ```

The failure seems to be caused by `cabal` extending the environment with `happy_backend_glr_datadir`, `happy_backend_lalr_datadir`, `happy_datadir`, and `happy_tabular_datadir`. I can reliably reproduce the failure as follows ``` happy_datadir="$(pwd)/./." cabal build happy-frontend...

Could it be a problem in cabal? Here's the version I have on the machine where the problem is reproducible ``` $ cabal --version cabal-install version 3.10.2.1 compiled using version...

> I can reliably reproduce the failure as follows No, I take that back. It does reproduce the problem on one machine but not on the other one. I'm lost...

> I then wonder what we need the "Oracle" parser for... The initial idea (in #170) was to avoid bootstrapping entirely, thus reducing the complexity of the build, and avoiding...

Here we go: https://github.com/haskell/happy/pull/277

> Error handling is not required to be fast Are you sure? GHC relies on the `error` token to implement the layout rule.

I have released `happy-2.0` as a set of package candidates. You can test them by adding the following lines to your `cabal.project`: ``` packages: https://hackage.haskell.org/package/happy-2.0/candidate/happy-2.0.tar.gz https://hackage.haskell.org/package/happy-grammar-2.0/candidate/happy-grammar-2.0.tar.gz https://hackage.haskell.org/package/happy-tabular-2.0/candidate/happy-tabular-2.0.tar.gz https://hackage.haskell.org/package/happy-codegen-common-2.0/candidate/happy-codegen-common-2.0.tar.gz https://hackage.haskell.org/package/happy-backend-glr-2.0/candidate/happy-backend-glr-2.0.tar.gz https://hackage.haskell.org/package/happy-backend-lalr-2.0/candidate/happy-backend-lalr-2.0.tar.gz...

Could we pick the entry size at code generation time? Use 8, 16, 32, or 64 bits depending on how many are needed.