when updating hspec to 2.9.0, must change configFastFail to configFailFast

[GoldThruster]

My test wasn't compiling (which has not be modified at all, fresh from download), and cabal reported this error:

test\Tests.hs:9:27: error:
    Module `Test.Hspec.Runner' does not export `configFastFail'
9 | import Test.Hspec.Runner (configFastFail, defaultConfig, hspecWith)
  |                           ^^^^^^^^^^^^^^

Searching online I found the hspec changelog (the latest version).
It reports that in version "2.9.0":

Changes in 2.9.0
- Add ASCII fallbacks to "checks" formatter (fixes #512)
- Use checks formatter by default (to restore the old behavior use --format specdoc)
- Allow to extend the list of available formatters for --format (configAvailableFormatters)
- Add getExpectedTotalCount to Test.Hspec.Core.Formatters.V2
- Rename formatConfigItemCount to formatConfigExpectedTotalCount
- Rename configFastFail to configFailFast      <--!!!!

The important line: "Rename configFastFail to configFailFast"
By updating the import, everything compiled just fine.

I'm not making a pr because, no one else seems to have reported it, so I'm not sure I've messed up something or is a real "bug".
If I haven't messed up, then the only corrections to be applied are:

• import Test.Hspec.Runner (configFailFast, defaultConfig, hspecWith) on line 9
• main = hspecWith defaultConfig {configFailFast = True} specs on line 14

[moniquelive]

If you like oneliners like me, change to the exercise path and:

❯ sed -i 's/configFastFail/configFailFast/g' test/Tests.hs

Thanks for pointing that out!

[asarkar]

Hard coding configuration options in tests can be avoided by putting a .hspec file in the exercise directory.

In fact, the main function can be completely eliminated as specified in ticket #1075

[denismaier]

What's the status of this? I just ran into the same issue with the pangram exercise. (I'm doing the exercises in the online editor, so I think I cannot adjust the test files manually.)

Edit: I've realized there's a PR for this. I've restated my question there.

[avysk]

Can you point me to the PR, please? I've just hit the same error (and this bug is over one month old).

[MatthijsBlom]

The problem is that #1158 isn't merged yet; working on it as we speak.

[avysk]

So PR was merged, and my error changed to

[blah]
[2 of 2] Compiling Paths_space_age
Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.6.3.0/build/test/test ...
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
[blah]

So it looks like the infrastructure is still broken, and CI allowed to merge a broken PR. Am I wrong?

[avysk]

...and now I cannot build locally anymore with clock > error: gcc: error: unrecognized command-line option '--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd'. Isn't the space missing before --lflag?

[MatthijsBlom]

Please open a forum thread and post your system information and taken actions there.

[avysk]

How my system information relates to ld failure at Exercism site (see above)? The fact that local build started to fail is just an additional information and can be ignored.

[MatthijsBlom]

Silliness on my part aside, I do not suggest you post on the forum without reason.

Discussions on the forum suggest the problems related to the GHC 9.0.2 -> 9.2.7 upgrade have been fixed. If you are still having trouble, probably something else is going on and please take it to the forum.

[denismaier]

I've been just able to successfully run a test in the online editor.

[avysk]

Yes, it looks like linker error on exercism site was fixed. My tests passed.

[avysk]

and just FYI: I have fixed the local build by switching ghc from the usage of gcc to the usage of clang. Quite possible that gcc in FreeBSD is broken somehow, and clang is a part of the base system.