Closed michaelpj closed 2 years ago
There are two use cases for unsafeRunTcM
in the PyF codebase.
reportError
https://hackage.haskell.org/package/template-haskell-2.19.0.0/docs/Language-Haskell-TH.html#v:reportError function by just adding the precise localisation of the error. I have NO idea why this could generate any failure in a different context, because the unsafeRunTcM
here literally call the same code as reportError
, but replaces one argument (the localisation). Note also that this code path is only used when an error happen, so it may not be a problem if this fails in a cross compilation context.unsafeRunTcM
is more convoluted and may be the reason why it fails. I may revert this recent change and/or introduce a flag as you suggest. This codepath is used everywhere, so indeed it will be used during your cross compilation.@michaelpj I've tested the problem in your codebase based on what you describe in https://github.com/input-output-hk/plutus/pull/4862 and indeed, the use of unsafeRunTcM
was responsible for the problem.
I'm refactoring to remove the usage of unsafeRunTcM
in the "normal" path, leaving the only use case for the "error" path.
See #117
Wonderful, thank you! I think this should also work with cross-compilation since the error case won't be hit in the normal case, and if there's an error then users should be able to detect that in normal compilation :+1:
... or perhaps provide a flag to turn it off (at the cost of worse error reporting).
I don't have a smoking gun, but I suspect this is related to whatever was causing my issues in https://github.com/guibou/PyF/issues/111, and I have word from a GHC expert that this will definitely not work when cross-compiling/using the external interpreter, which is a thing that people want to do (and it'll be fairly obscure to discover the problem).