Eval plugin: support ghc 9.0.1

[berberman]

Tests are broken due to:

• the type of strings is displayed as String in GHC 9, rather than [Char]
• according to https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0179-printing-foralls.rst, inferred type variables are enclosed with braces in GHC 9

These are minor differences, but I'm not sure if it's a good idea to have separate golden test files for GHC 9...

[pepeiborra]

Awesome!

Re the test files, I think that we will need to update them for 9.0 and disable the eval plugin tests for 8.x to avoid maintaining two sets of golden tests files.

[jneira]

We are gonna support ghc 8 for a while, so I would wait to a stable and widely used ghc 9 to remove tests for older versions
The ghc golden tests file will not need maintenance effort, as they are not gonna change (probably) and we could only add new tests for 9.

[pepeiborra]

We are gonna support ghc 8 for a while, so I would wait to a stable and widely used ghc 9 to remove tests for older versions
The ghc golden tests file will not need maintenance effort, as they are not gonna change (probably) and we could only add new tests for 9.

Removing the tests for ghc 8.x does not mean that we don't support the plugin in that version, but simply that we only test it with ghc 9.

Either now or in the future we are going to need to migrate the test suite to ghc 9. My view is that it's better to do it now that it's cheap rather than wait until later when it's more expensive.

[jneira]

Removing the tests for ghc 8.x does not mean that we don't support the plugin in that version, but simply that we only test it with ghc 9.

Sure but new bugs could be introduced and in that case, depending on their severity, it will be worse than remove support for the plugin

Either now or in the future we are going to need to migrate the test suite to ghc 9. My view is that it's better to do it now that it's cheap rather than wait until later when it's more expensive.

Mmm we will have to

• copy golden tests and change them and
• add and cpp (or runtime) if for load files from one location or another

When we will drop support for ghc <= 8, we will have to remove old golden files and the if (like the rest of dozens of similar ifs everywhere).
The extra effort (create the if now and remove later) worths it imo.

[pepeiborra]

Removing the tests for ghc 8.x does not mean that we don't support the plugin in that version, but simply that we only test it with ghc 9.

Sure but new bugs could be introduced and in that case, depending on their severity, it will be worse than remove support for the plugin

That's true. As maintainers, we always have to balance the cost of duplication versus the perfect coverage. What I am saying is that, as a maintainer, I believe that it is not worth to duplicate these tests and that right now is the optimal moment to upgrade them. But I can also see your point: we don't want to accidentally break GHC 8.x support.

Either now or in the future we are going to need to migrate the test suite to ghc 9. My view is that it's better to do it now that it's cheap rather than wait until later when it's more expensive.

Mmm we will have to

• copy golden tests and change them and
• add and cpp (or runtime) if for load files from one location or another

When we will drop support for ghc <= 8, we will have to remove old golden files and the if (like the rest of dozens of similar ifs everywhere).
The extra effort (create the if now and remove later) worths it imo.

CPP in our test suites is not as pervasive as it is in our library code, and as far as I know we don't have duplicate golden tests anywhere else. But I'm not against adding them, if @berberman is willing to contribute them.

[berberman]

I'm fine with maintaining test cases for multi ghc versions, but having many duplicate golden tests files is a bit tedious, so I extracted tests pieces which need variation with ghc versions to the haskell source file for applying conditions.

[jneira]

lgtm, thanks for include the eval plugin for ghc-9