-
Notifications
You must be signed in to change notification settings - Fork 695
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
3.0 Solver issue #6099
Comments
For the record, the only way I can manage to reproduce this (i.e. the We should encode some kind of version into the binary dist-newstyle/ cache data to detect and invalidate incompatible cache data generated by a different version of |
See also #6164 for a "point fix" in one place |
@DanielG so you're suggesting to start renaming the files on every schema change instead of including versioning inside the binary encoding? |
It's really just a stopgap measure which we can apply right now instead of waiting until we get around to versioning the cache. I'd also prefer to fix this properly but for now this works and doesn't really have any significant downsides. |
Fixed with #6255 |
I've observed a weird behavior that I haven't dug down into but follows the pattern below:
cabal new-configure
-> failure
cabal new-configure --allow-newer=base
-> success
cabal new-configure
-> success
cabal new-configure
-> failure
It seems that the 3rd new-configure is picking up settings and using them but also clearing them.
Since this is new-configure it seems it should clear them and not use them.
Additionally, there is an error "(conflict: requires NoStarIsType)", which comes from:
if impl(ghc >= 8.6) default-extensions: NoStarIsType
as that's an extension it doesn't seem it should cause a dependency resolution failure. In fact, it doesn't in 2.4 so it seems to be a regression.
The text was updated successfully, but these errors were encountered: