Ghc 9.2.5 #1869
Ghc 9.2.5 #1869
Conversation
ylecornec
force-pushed
the
ghc-9.2.5
branch
4 times, most recently
from
d4918bf to
bda3e5f
Compare
| @@ -132,6 +203,15 @@ stack_snapshot( | |||
| "hspec", | |||
| "package1", | |||
| ], | |||
| setup_deps = { | |||
| "HUnit": ["@Cabal//:Cabal"], | |||
There was a problem hiding this comment.
Maybe add a comment like the one above here, too, so that it's not forgotten when we can update to the new Cabal version. (Best also open a GH issue on rules_haskell to track it.)
vendor/bazel_json/lib/BUILD
Outdated
| @@ -1,4 +1,5 @@ | |||
| package(default_visibility = ["//:__pkg__"]) | |||
|
|
|||
There was a problem hiding this comment.
Not opposed to including this here, but, out of curiosity, how is bazel_json connected to the GHC update?
Also, for a separate PR, but, could we get rid of this and replace it by the builtin Bazel JSON module?
There was a problem hiding this comment.
After double-checking, the modifications to bazel_json were not due to an update but to buildifier. And they seem unnecessary since CI still passes after removing this commit (so I am merging without them).
About replacing bazel_json with bazel json module. Looking at the documentation of https://bazel.build/rules/lib/json, I do not see a way to test if a json string is valid before trying to parse it, in order to customize the error message. And we use the fail_on_invalid = False functionnality of bazel_json for this once (here).
There was a problem hiding this comment.
Thanks for looking into this! Makes sense!
I do not see a way to test if a json string is valid before trying to parse it, in order to customize the error message. And we use the
fail_on_invalid = Falsefunctionnality ofbazel_jsonfor this once (here).
I see. Well, given that that code fails immediately itself after observing an error, it doesn't look like a big loss. So, I think we could still remove bazel_json and replace it with the builtin JSON parser.
|
🎉 All dependencies have been resolved ! |
Co-Authored-By: GuillaumeGen <[email protected]>
Co-Authored-By: GuillaumeGen <[email protected]>
Co-Authored-By: GuillaumeGen <[email protected]>
Co-Authored-By: GuillaumeGen <[email protected]>
Co-Authored-By: GuillaumeGen <[email protected]>
Paths_ modules generated by Cabal 3.6.3.0 contain paths with some duplicated backslashes (but they are still valid). This update tests to be more permissive when comparing them to the paths we generate.
haskell_libraries without versions used as dependencies of haskell_cabal_{library/binary} rules are not found anymore when using ghc 9.2.5
Co-Authored-By: GuillaumeGen <[email protected]>
Co-Authored-By: GuillaumeGen <[email protected]>
|
Commit 3b2c2e4 makes use of the This way, paths are consistent with the ones used for the |
Depends on #1868
This PR updates the version of GHC used for tests to
9.2.5.The tests rely on tweag's fork of cabal, which adds the fix to issue splitFileName and minusFileName Variable not in scope causes builds to fail #1832 to Cabal 3.6.3.0 (the version corresponding to ghc
9.2.5).The arm example is not updated yet because it relies on haskell.nix which does not support
9.2.5(see here). Doing so thus results in recompilation of ghc.