-
Notifications
You must be signed in to change notification settings - Fork 710
Copy .hie
test fails with ghc-9.8.1
#9725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I have |
The failing test was added in #9019. |
It seems to pass on 9.6.2 and 9.8.1 for me locally. |
More carefully this time, first with
Then again with
|
The test is looking in the wrong place; - setup.dist/usr/lib/x86_64-linux-ghc-9.8.1/hie-local-0.1.0.0/extra-compilation-artifacts/hie/HieLocal.hie
+ setup.dist/usr/lib/x86_64-linux-ghc-9.8.1-eb95/hie-local-0.1.0.0/extra-compilation-artifacts/hie/HieLocal.hie |
@alt-romes could this be from the change in #9618 to use |
lbiCompiler :: Compiler
lbiCompiler = Compiler {compilerId = CompilerId GHC (mkVersion [9,8,1]), compilerAbiTag = NoAbiTag, ... Same
Footnotes
|
In the testsuite we generate a module `ScriptEnv0.hs` which records information about the compiler used to build the testsuite, the packages etc so that the test runner can then use this information to However, this is very fragile because * `ScriptEnv0.hs` is generated by a module compiled against `Cabal-3.10` * The file is compiled against `Cabal-3.11` So if any definition changes between 3.10 and 3.11 then the new version will fail to read the generated file. Really we should record the information which needs to be persisted in a more generic way (ie only depending on `base`) so that you can be sure the serialisation/deserialisation will work. This seems to have worked for a while because these data types never change.. but now `compilerAbiTag` is populated by `3.11` but not by `3.10`, which leads to bugs like haskell#9725 See haskell#9730
A patch which fixes this immediate issue: https://github.com/mpickering/cabal/tree/wip/test-compiler-fix I am still not happy with the overall approach (see #9730) so I will leave it here for when progress is forced on this issue. |
Uh oh!
There was an error while loading. Please reload this page.
While testing #9717, I found a test that fails locally with
ghc-9.8.1
but passes withghc-9.4.8
. Here's the failure;Originally posted by @philderbeast in #9717 (comment)
The text was updated successfully, but these errors were encountered: