Expose tests and benchmarks as public sublibrary

[Shimuuar]

This was discussed in #426 and #459 as a way for other packages to access tests and benchmarks from vector. I tested that it's possible to build PAPI-based benchmarks as separate package, but this change is big enough that it deserves its own PR

There're two tests sublibraries: one built with with -O2 (vector:tests-O2) and another with -O0 (vector:tests-O0). In the same way benchmarks library is called vector:benchmarks-O2. I want to leave name for benchmarks built with -O1 since testing both -O1 and -O2 could be quite valuable.

Most notable change: building vector requires cabal 3.0 since it's earliest version supporting public sublibraries.

There's also question of naming of modules in both sublibraries. I left them as they were but it was assumed that they are not available outside of test-suite/benchmarks which is not the case anymore.

[Shimuuar]

There's also problem with cabal check. It complains:

Warning: These warnings may cause trouble when distributing the package:
Warning: 'ghc-options: -O0' is not needed. Use the --disable-optimization
configure flag.
Warning: 'ghc-options: -O0' is not needed. Use the --disable-optimization
configure flag.

and fails CI. It seems there's no good way around this. We do need to build tests with different optimization levels

[lehins]

It also complains about bounds:

Warning: These packages miss upper bounds:
- base-orphans
- random
- tasty
- tasty-hunit
- tasty-quickcheck
- template-haskell
- transformers

I think we can just disable cabal check, since those warnings are useless.

[Shimuuar]

Cabal check has warnings and warning-but-actually-errors. Former are printed but cabal check returns 0, latter causes non-zero exit code. AFIAR hackage runs cabal check on upload and will reject packages failing it, warnings are accepted.

Maybe there's way around this by structuring tests different;y. But I think it would be better to keep tests private in this PR

[lehins]

Maybe cabal check is right? Is it actually necessary to specify optimization flag for libraries?
I thought it is up the end executable to control that. If this is true, then all we need is two sublibraries that would specify all of the reusable functionality:

• testlib
• and benchlib

and then me can have the separate test suites and bemchmarks with varying optimization levels.

I also agree that module names should be improved before we actually make a release.

My suggestion would be adding these prefixes:

• for test library Test.Vector...
• for benchmarks Bench.Vector...

[lehins]

I think it would be better to not expose all of the functionality from a sub-library.

The idea behind the library is that downstream users would be able to use it somehow. For example Arbitrary instances are quite useful. Potentially some properties implemented in terms of generic vector, in case someone wants to test their custom instances of vector, like instance of Unboxed vector.

That being said, we can make these improvements later, so it doesn't have to be done in this PR

[Shimuuar]

Yes I think sublibrary for tests turned out to be trickier than I thought. It would be better to keep tests as they are. And extract common functionality piece by piece later.

With benchmarks situation with optimization flags is more tricky. They export monomorphic function and optimization level is decided when function is built. Application cannot change it.

[Shimuuar]

So I left tests mostly alone and only factored shared parts into common stanza. Also:

• Dropped HUnit dependency

For benchmarks sublibrary I moved all modules into Bench.Vector hierarcy and moved RandomSeed & VectorSize options to library as well. They will be used by PAPI benchmark as well

[lehins]

This looks great!