-
Notifications
You must be signed in to change notification settings - Fork 241
internal error: extractDecl when selectively reexporting data instance #979
Comments
This will make investigation of haskell#979 easier
This will make investigation of #979 easier
I'm having a tough time replicating this. What GHC commit were you using? |
@harpocrates I was able to repro this on a very recent commit ghc/ghc@548becd Here is a complete repro:
|
OK, I can replicate now. This looks like a GHC bug; check out the avails reported by
I'll see if I can diagnose the issue in GHC. If not, you're right we should at least patch Haddock (and leave this issue open as a reminder). |
I've opened https://ghc.haskell.org/trac/ghc/ticket/16077 regarding the Avail invariant being violated. |
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨ Hi! Getting a similar error over in esqueleto The problem is possibly the re-export of Update:
It looks like maybe Hope this helps! |
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨ So it seems like on ghc-8.2.2, the export list is kept at just the module
So it wasn't hitting the |
Haddock coverage: haddock: internal error: internal: extractDecl CallStack (from HasCallStack): error, called at utils/haddock/haddock-api/src/Haddock/Interface/Create.hs:1116:12 in main:Haddock.Interface.Create
Any news on this bug? Is there a way to work around it until it's fixed? |
This GHC patch should fix the issue: https://gitlab.haskell.org/ghc/ghc/merge_requests/276. At the very least, it fixes the test case from #979 (comment). No Haddock change will be required: this is just GHC not obeying one of its own invariants. In the meantime, it should be possible to work around this issue by replacing the problematic It would eventually be nice for Haddock to be more flexible around its error handling (for example: printing errors and exiting with an error code, but still producing a best effort at docs), but there are more pressing problems at the moment... |
The AvailTC was not be upheld for explicit export module export lists when the module contains associated data families. module A (module A) where class C a where { data T a } instance C () where { data T () = D } Used to (incorrectly) report avails as `[C{C, T;}, T{D;}]`. Note that although `T` is exported, the avail where it is the parent does _not_ list it as its first element. This avail is now correctly listed as `[C{C, T;}, T{T, D;}]`. This was induces a [crash in Haddock][0]. See #16077. [0]: haskell/haddock#979
The AvailTC was not be upheld for explicit export module export lists when the module contains associated data families. module A (module A) where class C a where { data T a } instance C () where { data T () = D } Used to (incorrectly) report avails as `[C{C, T;}, T{D;}]`. Note that although `T` is exported, the avail where it is the parent does _not_ list it as its first element. This avail is now correctly listed as `[C{C, T;}, T{T, D;}]`. This was induces a [crash in Haddock][0]. See #16077. [0]: haskell/haddock#979
The AvailTC was not be upheld for explicit export module export lists when the module contains associated data families. module A (module A) where class C a where { data T a } instance C () where { data T () = D } Used to (incorrectly) report avails as `[C{C, T;}, T{D;}]`. Note that although `T` is exported, the avail where it is the parent does _not_ list it as its first element. This avail is now correctly listed as `[C{C, T;}, T{T, D;}]`. This was induces a [crash in Haddock][0]. See #16077. [0]: haskell/haddock#979 (cherry picked from commit a0cd486)
The GHC patch has been merged and cherry-picked to the 8.6 and 8.8 branches. This should mean that this will be fixed in |
Are other people no longer seeing this when compiling with GHC 8.6.4? I'm still getting the error for e.g. classy-prelude-yesod-1.5.0, and that package is marked as broken because of this bug on the Nix 19.03 release for this bug. https://github.com/NixOS/nixpkgs-channels/blob/3a4ffdd38b56801ce616aa08791121d36769e884/pkgs/development/haskell-modules/configuration-hackage2nix.yaml#L3482 |
Updated to LTS 13.15 for GHC 8.6.4 but still get this error: $ stack hoogle
No Hoogle database yet. Automatically building haddocks and hoogle database (use --no-setup to disable) ...
Yapper-0.0.0: unregistering
classy-prelude-yesod-1.5.0: configure
classy-prelude-yesod-1.5.0: build
classy-prelude-yesod-1.5.0: haddock
Progress 1/2
-- While building package classy-prelude-yesod-1.5.0 using:
/Users/nrm/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.4 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 haddock --html --hoogle --html-location=../$pkg-$version/ --haddock-option=--hyperlinked-source --haddock-option=--quickjump
Process exited with code: ExitFailure 1
Logs have been written to: /Users/nrm/Sources/mdpm/projects/Yapper/.stack-work/logs/classy-prelude-yesod-1.5.0.log
Configuring classy-prelude-yesod-1.5.0...
Preprocessing library for classy-prelude-yesod-1.5.0..
Building library for classy-prelude-yesod-1.5.0..
[1 of 2] Compiling ClassyPrelude.Yesod ( src/ClassyPrelude/Yesod.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/ClassyPrelude/Yesod.o )
[2 of 2] Compiling Paths_classy_prelude_yesod ( .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/Paths_classy_prelude_yesod.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Paths_classy_prelude_yesod.o )
Preprocessing library for classy-prelude-yesod-1.5.0..
Running Haddock on library for classy-prelude-yesod-1.5.0..
Haddock coverage:
haddock: internal error: internal: extractDecl
CallStack (from HasCallStack):
error, called at utils/haddock/haddock-api/src/Haddock/Interface/Create.hs:1116:12 in main:Haddock.Interface.Create |
I am still seeing this error with LTS 13.15 as well. |
The reason for haddock's error is a bug in GHC which was fixed (https://gitlab.haskell.org/ghc/ghc/merge_requests/276/commits) but not merged into the 8.6 branch. So it seems like you need to wait for GHC 8.8 ... or you could checkout GHC's 8.6 branch cherry-pick 2a431640d1 and then compile your fixed GHC ... but that will take a lot of time ... |
This will make investigation of #979 easier
Causes something very much like this bug: haskell/haddock#979
This will make investigation of haskell/haddock#979 easier
Env
Repro
Here is the minimal repro I constructed, with two packages where pkg2 depends on pkg1:
Issue
I looked into this a little bit and this is what the callstack looks like:
availExportsDecl
depends on the invariants stated inAvail
that if the type or class is itself to be in scope, it must be first in this list. But this invariant doesn't quite hold for data instance above?Not sure what's the best way to fix this, we can at least suppress this error by intentionally ignoring this case.
The text was updated successfully, but these errors were encountered: