Open RyanGlScott opened 7 years ago
This is my doing; will look into it soon!
In the meantime One workaround is to rename ISO's record name if possible?
This is my doing; will look into it soon!
In the meantime One workaround is to rename ISO's record name if possible?
Renaming the records does seem to work around the issue, yes.
By the way, the names are unqualified now so this should work even without renaming the fields. Can you try that?
I made this comment since I encountered this very issue (on the latest LH commit, 68370a4c5ae9c0dc2fa70e9373dd7da7d4a3a793) elsewhere. But I can try this minimized example again too.
I'm afraid that I experience the same error on 68370a4c5ae9c0dc2fa70e9373dd7da7d4a3a793 (after removing the --totality
flag from Iso
and Bug
, of course).
Ok, so another work around is to make the imports qualified, i.e.
import qualified Iso
import qualified Generic
but really, we ought to just save the "qualified"-DataCtor (see qualifyDataCtor
) in the lifted spec.
Unfortunately, the qualifying happens long after the lifting, so this is quite a difficult piece of surgery :(
This is a regression that seems to have arisen somewhere between 27bc088c4f8b29fd9866e5589233e97e22e314c4 (where this bug does not occur) and 259ebc254472918e6275c44099c56d7ff019ea9f (where it does). First, consider these two files:
If you try to check them with LH with either commit (I'll use the later one, 259ebc254472918e6275c44099c56d7ff019ea9f, as an example):
Then they're safe, as expected (although the percentage is quite off, for some reason...)
However, if you combine these files:
Then with commit 27bc088c4f8b29fd9866e5589233e97e22e314c4, it's safe. But with commit 259ebc254472918e6275c44099c56d7ff019ea9f, it's unsafe:
This error is confusing for a number of reasons, since:
Iso.hs
, but that can't be the case, as checkingIso
worked!to
whose definition was reflected was that ofIso
.