-
Notifications
You must be signed in to change notification settings - Fork 476
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
Make it build with ghc-9.6 #5286
Conversation
39846a1
to
5c2dab1
Compare
@@ -70,7 +70,7 @@ executable doc-doctests | |||
, base >=4.9 && <5 | |||
, bytestring | |||
, containers | |||
, flat <0.5 | |||
, flat ^>=0.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be careful with this, we have to check carefully that upstream hasn't broken anything. Is this change necessary for 9.6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old version does not compile with 9.6
(probably due to nope, much worse than that).base
bounds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can get away with allow-newer
ing the base bounds then I think I'd mildly prefer this, since this is a sensitive dependency and this will change the bound for all GHC versions atm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it not make sense to do one or both of the following?
- Write tests for
flat
and submit them upstream. - Write tests for
flat
and keep them in the Plutus repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried removing the version bump for flat
and added allow-newer: flat:*
. The result was:
src/Flat/Decoder/Strict.hs:240:19: error: [GHC-31891]
• Illegal term-level use of the type constructor or class ‘TA.Array’
• imported qualified from ‘Data.Text.Array’ at src/Flat/Decoder/Strict.hs:45:1-53
• Perhaps use variable ‘array’ (line 239)
• In the first argument of ‘T.Text’, namely ‘(TA.Array array)’
In the first argument of ‘return’, namely
‘(T.Text (TA.Array array) 0 (lengthInBytes `div` 2))’
In a stmt of a 'do' block:
return (T.Text (TA.Array array) 0 (lengthInBytes `div` 2))
|
240 | return (T.Text (TA.Array array) 0 (lengthInBytes `div` 2))
| ^^^^^^^^
and
src/Flat/Encoder/Prim.hs:243:25: error: [GHC-76037]
Not in scope: data constructor ‘TA.Array’
NB: the module ‘Data.Text.Array’ does not export ‘Array’.
|
243 | eUTF16F_ !(TI.Text (TA.Array array) w16Off w16Len) s =
| ^^^^^^^^
It supposedly is possible to constrain text < 2.0
but that may cause issues further up the stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have tests. Nonetheless I'm cautious :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bezirg could you look into upgrading to flat >= 0.6
on master and check that the script dump test continues to pass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I am on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test infrastructure this needs got broken a while ago so it might be a little while until we can test this. I am tentatively in favour of merging since I think it's very likely not broken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests are finished locally.
Both plutus-master and plutus-master+flat0.6.patch pass the current mainnet script tests
c40ea93
to
7c27753
Compare
Now it appears to fail to build with 8.10 and fail to even plan with 9.2 |
@michaelpj I rebased this against I think the failure to create a build plan was due to the line:
I have been adjusting those bounds for each compiler. Would be happy to hear any solutions to that issue. |
I think we discussed this a bit on Slack, but:
|
Ah, this is what I need: diff --git a/plutus-tx-plugin/plutus-tx-plugin.cabal b/plutus-tx-plugin/plutus-tx-plugin.cabal
index a40d9ccde..6635d44b6 100644
--- a/plutus-tx-plugin/plutus-tx-plugin.cabal
+++ b/plutus-tx-plugin/plutus-tx-plugin.cabal
@@ -49,7 +49,7 @@ flag use-ghc-stub
library
import: lang
- if impl(ghc <9.0)
+ if impl(ghc < 9.2) || impl(ghc >= 9.3)
buildable: False and in a number of other places. |
plutus-core/index-envs/src/Data/RandomAccessList/SkewBinarySlab.hs
Outdated
Show resolved
Hide resolved
b30089f
to
fd2e4e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty much there. We need to update the GHC versions section of CONTRIBUTING, but I can do that when I add 9.6 CI.
cabal.project
Outdated
, th-compat:* | ||
|
||
constraints: | ||
, microlens >= 0.2.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment explaining these (I would expect us cabal to pick the compatible versions of these libraries automatically) and when we can remove them.
cabal.project
Outdated
, dependent-map:* | ||
, hedgehog:* | ||
, protolude:* | ||
, th-compat:* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming we have upstream issues for everything that's jailbroken by this?
@@ -70,7 +70,7 @@ executable doc-doctests | |||
, base >=4.9 && <5 | |||
, bytestring | |||
, containers | |||
, flat <0.5 | |||
, flat ^>=0.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test infrastructure this needs got broken a while ago so it might be a little while until we can test this. I am tentatively in favour of merging since I think it's very likely not broken.
deriving anyclass (NFData) | ||
deriving stock (Functor, Generic) | ||
|
||
deriving stock instance (Show tyname, Show name, GShow uni, Everywhere uni Show, Show fun, Show ann, Closed uni) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it really sucks. But perhaps we could introduce some aliases in order not to write this whole thing our every time. Maybe some generic one that works for every constraint (we'll only need to special-case things like GShow
). Not sure if it's worth it, though.
I pushed a commit attempting to make the 9.6 CI work, and also merged master to get a haskell.nix update. |
Okay, it seems to find a build plan now, let's see how far it gets. |
maybe well-typed/cborg#311 ? Looks like we need to poke our WT colleagues or something. |
Non-darwin fails because of
|
I still seem to be getting some warnings locally, I'll fix those next, and then I think this might be ready. |
An actual test failure! And an interesting one. |
deriving anyclass (NFData, NoThunks) | ||
deriving anyclass (NFData) | ||
|
||
-- For some reason the generic instance gives incorrect nothunk errors, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI @effectfully
force-pushed to re-excite ci. |
a7bcba9
to
d3d6088
Compare
Co-Authored-By: effectfully <effectfully@gmail.com>
Co-Authored-By: effectfully <effectfully@gmail.com>
I think all that is missing is #5309 |
No description provided.