Use -XNoStrictData in generated parser (#273) #289
Conversation
| @@ -4,6 +4,9 @@ | |||
|
|
|||
| The main focus of this release was modularizing Happy. | |||
|
|
|||
| * Generated parsers now activate the language extension `-XNoStrictData` without | |||
There was a problem hiding this comment.
-X(No)StrictData is available since GHC-8.0, so this change means that happy won't anymore generate code which works with older GHCs.
As far as I'm concerned, that is fine, but it's probably a good idea to tell explicitly in the changelog.
There was a problem hiding this comment.
... you don't test master with older than GHC-8.0, though it might be still buildable with older GHCs? If it weren't, then using new happy with old GHCs will become very unlikely.
There was a problem hiding this comment.
The trouble is that it has become quite hard to test 7.10 and below in CI. ghcup doesn't provide it and I'm not a huge fan of manually setting it up. Besides it is not unlikely that it won't work due to some glibc incompatibility.
Besides, GHC 8.0 is quite ancient at this point and I would be happy to drop support for 7.10 and below. The cabal file says as much already, but perhaps we should announce it in the release notes as well.
There was a problem hiding this comment.
The cabal file says as much already,
It doesn't
It only says that you test with GHC-8.0 and up, not that you don't support oldere GHCs. E.g. you have
build-depends: base < 5,
array,
...
so technically cabal would try compile even with GHC-7.0 etc.
And it actually fails, if you test it:
Building library for happy-backend-glr-2.0..
ghc: unrecognised flag: -Wincomplete-uni-patterns
There was a problem hiding this comment.
Anyone stuck on GHC < 8.0 is probably also fine with happy < 2.0. Let's not waste time on legacy compiler versions.
There was a problem hiding this comment.
@int-index Correct the metadata. Write lower-bounds. base >=4.9. Not a hard thing to do. It's not a waste of time.
There was a problem hiding this comment.
Dependency bounds for the generator itself and dependency bounds for the generated code aren't the same thing. base >=4.9 is correct as long as happy itself builds with base >=4.9.
I agree that we should bump this bound because, as you point out, happy-backend-glr doesn't build with older GHCs. However it's a separate problem unrelated to this PR.
There was a problem hiding this comment.
As I said, if happy itself is not buildable with older GHCs then it's make sense it isn't able to generate code for older GHCs.
It could be so that happy is buildable only with newer GHCs (say even GHC-9+ only) but supports code generation for older GHCs. (It would be trickier to test but not impossible. E.g. cabal is buildable with only newer GHCs, but can work with older than that).
It would be somewhat confusing if happy would be buildable with old GHCs, but not be able to generate code for those old GHCs. Given that cabal-install builds happy itself (doesn't reuse some global installation), those users would find themselves if complicated situations.
So, IMHO, it makes everything somewhat simpler if happy itself and generated code has the same support GHC windows. "If you can build a happy version with GHC-x.y, that happy will generate code which GHC-x.y will handle".
In particular, if/when GHC introduces a change, such that happy itself is still buildable, but code is not, I'd argue that happy shouldn't be buildable.
There is no way to declare in happy.cabal dependency metadata for the generated code, so at large it's simpler if happy's own build metadata is (re)used also as the generated code dependency metadata. (Similarly as we are currently imprecise in multi-staged or cross-compilation scenarios, using the same bounds for all stages and host&target).
|
Alright, I added another commit setting a lower bound on |
Fixes #273. CC @andreasabel