GHC panic with deferred custom type errors
I'm working on a music composition library that enforces composition rules at the type level. It makes heavy use of TypeInType and custom compiler errors. For example, it disallows dissonant major seventh intervals (e.g., a C and a B) in harmonic composition. While testing the library, I encountered a GHC panic which I haven't seen anywhere – unfortunately I don't know enough about GHC to understand what is causing the panic and couldn't reproduce it in simpler examples. I was hoping that you could point me in the right direction so that I can find a smaller program that reproduces the error.
In GHCi, with the -fdefer-type-errors flag set, the following code (which should throw a custom type error as it describes composing a B quarter note with a C quarter note) produces a panic:
λ: let t = c qn :-: b qn <interactive>:21:9: warning: [-Wdeferred-type-errors] • Can't have major sevenths in chords: C and B • In the expression: c qn :-: b qn In an equation for ‘t’: t = c qn :-: b qn ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): nameModule system irred_aCeG Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This does not appear when loading a source file, or when -fdefer-type-errors is disabled, and only happens when the expression is assigned to a new value. A lot of the literals in the library are generated by TemplateHaskell, but the error happens without them as well:
λ: let s = Note (Root :: Root (PitchRoot (Pitch B Natural Oct4))) (Dur :: Dur Quarter ) λ: let t = Note (Root :: Root (PitchRoot (Pitch C Natural Oct4))) (Dur :: Dur Quarter ) λ: let v = s :-: t <interactive>:27:9: warning: [-Wdeferred-type-errors] • Can't have major sevenths in chords: B and C • In the expression: s :-: t In an equation for ‘v’: v = s :-: t ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): nameModule system irred_aCnF Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
The library is available on Hackage (https://hackage.haskell.org/package/mezzo) and the error is reproducible as soon as the main module is loaded.
I'd happily try to find a smaller example which gives the same error, so I was hoping that you might have some ideas about what could be going wrong.
|Operating system||MacOS X|