Support for ghc-9

[junjihashimoto]

We can test this pr with ghc-9, but it breaks backwards compatibility, so I will add ifdef of CPP-extenstion.

[gelisam]

Thanks! It"s pretty difficult to maintain backwards compatibility in a ghc plugin because the code is so tightly coupled to ghc's api, which can change a lot between versions. I was planning to only support one ghc version until I get enough users that the extra effort starts to seem worthwhile. But if you're willing to do the work to support more than one version, be my guest!

In any case, before I can merge this PR, CI must be updated so it tests with ghc-9; and if you want to do the work to support more than one ghc version, then CI should be updated to test both versions.

The CI configuration is in https://github.com/gelisam/typelevel-rewrite-rules/blob/main/.github/workflows/ci.yml, and as you can see, it is testing twice using stack and once using cabal. I do that for all my projects; the idea is to use stack.yaml for the recommended stackage lts version, oldest-supported-lts.yaml for the oldest supported stackage lts, and to use cabal to test that the upper bounds aren't too loose. I unfortunately don't have a good way to test the lower bounds, so I always set them to the oldest-supported-lts.yaml versions.

If we start using #ifdefs, then it's important for CI to test both of its branches. This could be accomplished with the above setup by choosing an oldest-supported-lts.yaml version which exercises one branch, and a stack.yaml which exercises the other. If more than two versions of ghc is supported, then we need to add more .yaml files, probably named stack-<ghc-version>.yaml.

[junjihashimoto]

Thx!

[gelisam]

I'm trying to figure out why GitHub isn't automatically running CI on this branch. I remember that GitHub is not running actions automatically on all PRs in order to avoid attacks in which a contributor opens a PR which modifies the .github file to make it mine some bitcoins it something. But how do I tell GitHub that this PR is legitimate?

[gelisam]

I don't see the dialog mentioned in GitHub's announcement of the cryptomining protection measures, so that's not the problem.

My next hypothesis is that maybe all the github actions are disabled on this repo? On July 1st I received an email telling me that the "CI" GitHub action had been disabled due to inactivity. I assumed this referred to the cron job which I run every month (I specifically run it every month rather than every day so that GitHub doesn't feel pressured to shut it down, but oh well), that PRs would be unaffected, and that the monthly runs would be reactivated next time I merge something in main. but maybe I assumed wrong!

[gelisam]

As I suspected, Only scheduled workflows are automatically disabled, so that's not it either. I'm running out of ideas...

[junjihashimoto]

For now, ci runs on pr's repo.
'Error messages' matrix fails.
https://github.com/hasktorch/typelevel-rewrite-rules/actions/runs/1057107862

[gelisam]

Thanks for finding the CI run. It makes a lot of sense that the error-messages test would fail when switching to a new version of ghc. Those tests are intended to detect regressions in the quality of the error messages, but it's hard to write a predicate which quantifies quality, so in practice I just use a golden file to detect when the error message changes, to make a human read the new error message and confirm that it's as clear as the old error message. In this case, ghc is now splitting the old couldn't match type A with B into two lines,

couldn't match: A
with: B

Which is obviously fine.

To make the test pass, we should thus change the expected file to match the new error message. Even though I support some glob patterns in the syntax for those files, it's going to be pretty difficult to make a single expected file which matches the output of both versions of the compiler, so I suggest only running the error-messages suite with one version of ghc.

[junjihashimoto]

@gelisam
Thank you for explaining about the failure of the error-message.
I've updated the message of error-message. The test runs only on ghc-9.
I think the result of CI is okay.
https://github.com/hasktorch/typelevel-rewrite-rules/actions/runs/1104728930

[gelisam]

@tscholak do you have time to look at and possibly merge this PR? As you know, I'm quite busy these days :)

[amigalemming]

What about ghc-tcplugins-extra? Would it help to write plugins that fit multiple GHC versions?

[Bodigrim]

@gelisam @tscholak any chance to merge this and make a release please?

[junjihashimoto]

This PR should be updated for ghc-9.2.
https://github.com/hasktorch/typelevel-rewrite-rules/tree/feature/ghc-9.2

[gelisam]

any chance to merge this and make a release please?

Thanks for reminding me about this! I'll take a look now.

[gelisam]

What about ghc-tcplugins-extra? Would it help to write plugins that fit multiple GHC versions?

It would help, but it only covers a tiny fraction of the GHC API, so it would not eliminate the issue. Looking at the CPP macros in the PR, I don't think it would have helped all that much.

The GHC team has already promised to keep the plugins portion of the GHC API more stable than the rest, but since plugins do a wide variety of things, it is common for plugins to reach outside of that stable API. As a result, it is not a surprise that plugins need more work between GHC versions than most libraries. For this reason, I am especially grateful to @junjihashimoto for this PR!

[gelisam]

@gelisam @tscholak any chance to merge this and make a release please?

Unfortunately, there is a regression: https://github.com/gelisam/typelevel-rewrite-rules/pull/35/files#r1136519429

[gelisam]

Oh wait, the regression only affects ghc-9.2, so I should be able to make a release which supports ghc-9.0!

[gelisam]

Merged as part of #37, and #35 is still open in order to track the ghc-9.2 work.

Next, releasing a new version!

[gelisam]

Released as typelevel-rewrite-rules-1.0.0.1!

[Bodigrim]

Thanks!