Remove CPP driven error reporting in favor of HasCallStack

[lehins]

This PR does the world a favor by reducing CPP usage in vector. 😄

The idea behind this PR is that all Bounds checks get the HasCallStack constraint, so they can propagate to the user's callsite, while Internal and Unsafe do not, nevertheless the error message will still contain the module name and line number as before with CPP approach, because of the ghc's callstack innovation.

For ghc-7.10 it will fall back to call-stack package, which is a small price to pay for backwards compatibility with such and old ghc version.

Next step will be to adding HasCallStack to all other partial functions transitively, such PR in itself will supersede #184

[Shimuuar]

Excellent!

I added HasCallStack constraint to other check functions. Otherwise call stack is truncated early and there's no way to know which function failed:

*Data.Vector> generate 10 id ! 11
*** Exception: index out of bounds (11,10)
CallStack (from HasCallStack):
  error, called at src/Data/Vector/Internal/Check.hs:101:12 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  checkError, called at src/Data/Vector/Internal/Check.hs:107:17 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  check, called at src/Data/Vector/Internal/Check.hs:120:5 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check

Also monomophic functions lack HasCallStack constraint which again causes call stack to terminate early:

*Data.Vector> generate 10 id ! 11
*** Exception: index out of bounds (11,10)
CallStack (from HasCallStack):
  error, called at src/Data/Vector/Internal/Check.hs:101:12 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  checkError, called at src/Data/Vector/Internal/Check.hs:107:17 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  check, called at src/Data/Vector/Internal/Check.hs:120:5 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check

or if it's added:

*Data.Vector> generate 10 id ! 11
*** Exception: index out of bounds (11,10)
CallStack (from HasCallStack):
  error, called at src/Data/Vector/Internal/Check.hs:101:12 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  checkError, called at src/Data/Vector/Internal/Check.hs:107:17 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  check, called at src/Data/Vector/Internal/Check.hs:120:5 in vector-0.13.0.1-inplace:Data.Vector.Internal.Check
  checkIndex, called at src/Data/Vector/Generic.hs:238:11 in vector-0.13.0.1-inplace:Data.Vector.Generic
  !, called at src/Data/Vector.hs:505:7 in vector-0.13.0.1-inplace:Data.Vector
  !, called at <interactive>:47:1 in interactive:Ghci1

[lehins]

I added HasCallStack constraint to other check functions.

Yes, this is the next step. I wanted to keep this PR to a minimum.

[lehins]

check{Index,Slice,Length} require HasCallStack constraint too

Good catch!!

[lehins]

@Bodigrim Do you have input on this ticket? If not, then I'll merge it tomorrow.

[Bodigrim]

@lehins any chance to check performance impact? I guess all these functions are non-recursive and inline well, so there is no associated cost to HasCallStack, but it would be nice to check. Otherwise looks very good indeed.

[lehins]

I did compare benchmarks included in the repo and there was no difference in performance. As you mentioned all these functions inline well, so it is expected that there would be no regressions (also mentioned in this comment by Ben: #184 (comment))

As an extra confirmation I did a similar switch in massiv recently and there was no impact on performance either, so I am pretty confident in this approach.

[Bodigrim]

This is a breaking change, because downstream packages could have included vector.h, e. g., Bodigrim/bitvec@f6e96e3. Could someone add a changelog entry please?

[lehins]

@Bodigrim I beg to differ. There is not a single place in haddock where vector.h or the included CPP pragmas are advertised as public API.

However, I will add this ticket into changelog before making a release. I am sure there are other things that we have missed that didn't make it into the changelog, so I'll go through all of the PRs since version 0.12 and catalog them with PR numbers in the changelog. (I wish I didn't have to do that and all changelog entries were added together with the PR, but we are all human and it is easy to forget it.)