Do not depend on clock

[sol]

This is trading correctness for fewer dependencies. One immediate benefit of this change is that we will get GHC 9.2.1 support right now.

The new code uses getCurrentTime, which is not monotonic. As a consequence the new behavior is less accurate when:

• A test run spans a leap second
• The system clock is adjusted during a test run

Both of these events are reasonably rare, so I hope this is the right thing to do.

[soenkehahn]

Both of these events are reasonably rare, so I hope this is the right thing to do.

Is getMonotonicTime only used to measure the speed of tests and display times to the user? If yes, this change doesn't seem bad or dangerous to me.

I'm struggling a bit to understand why this is necessary to support ghc-9.2 however. Locally I tried to run the hspec-core test-suite both from current branch main and branch ghc-9.2.1, both with ghc-9.2.1 as the compiler. And both times it builds fine, but the test-suite fails. Here's is the failure message:

  test/Test/Hspec/Core/Example/LocationSpec.hs:42:29:
  1) Test.Hspec.Core.Example.Location.extractLocation, with pattern match failure in do expression, in IO, extracts Location
       expected: Just (Location {locationFile = "test/Test/Hspec/Core/Example/LocationSpec.hs", locationLine = 40, locationColumn = 13})
        but got: Nothing

Did you run the tests from branch ghc-9.2.1 with compiler ghc-9.2.1 successfully? Any idea why it doesn't work on my machine? And why does clock need to be replaced?

[sol]

This is the error I'm getting with GHC 9.2.1:

linking dist/build/System/Clock_hsc_make.o failed (exit code 1)
rsp file was: "dist/build/System/hsc2hscall441822-2.rsp"
command was: /usr/bin/gcc dist/build/System/Clock_hsc_make.o dist/build/System/Clock_hsc_utils.o -o dist/build/System/Clock_hsc_make -fuse-ld=gold -fuse-ld=gold -L/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/base-4.16.0.0 -Wl,-R,/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/base-4.16.0.0 -L/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/ghc-bignum-1.2 -Wl,-R,/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/ghc-bignum-1.2 -lgmp -L/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/ghc-prim-0.8.0 -Wl,-R,/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/ghc-prim-0.8.0 -lc -lm -L/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/rts -Wl,-R,/home/sol/.install/haskell/ghc-9.2.1/lib/ghc-9.2.1/rts -lm -lrt -ldl -lnuma -lpthread
error: /usr/bin/ld.gold: error: cannot find -lnuma

I guess this is not clock specific, but will probably happen with any package that contains C sources?

Installing libnuma-dev resolves the issue.

Not entirely sure if this is a bug? Should e.g. ./configure fail when installing https://downloads.haskell.org/~ghc/9.2.1/ghc-9.2.1-x86_64-deb10-linux.tar.xz?

Also: https://gitlab.haskell.org/ghc/ghc/-/issues/15444#note_388256

[sol]

Both of these events are reasonably rare, so I hope this is the right thing to do.

Is getMonotonicTime only used to measure the speed of tests and display times to the user? If yes, this change doesn't seem bad or dangerous to me.

Yes, exactly.

Did you run the tests from branch ghc-9.2.1 with compiler ghc-9.2.1 successfully? Any idea why it doesn't work on my machine? And why does clock need to be replaced?

https://github.com/hspec/hspec/pull/549 addresses the failing test.

[sol]

It turns out that we can use GHC.Clock.getMonotonicTime with recent versions of GHC.