Skip to content

Disable problematic tests with -boundschecks #407

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

kenranunderscore
Copy link
Contributor

@kenranunderscore kenranunderscore commented Aug 18, 2021

Some negative tests (namely, the testsSliceOutOfBounds ones in the test group slice out of bounds #257) crash the test suites vector-tests-O0 and vector-tests-O2 when running it without bounds checks. I used cabal test -f -boundschecks from inside the vector directory, but encountered this problem in a nix-build of our project first where I disabled said flag for version 0.12.3.0 of the library.

It feels like they should not be run at all without those checks.

If there is a better/alternative way to tackle and fix this problem, please let me know and I'll try to update this PR with it :)

Some negative tests (namely, the `testsSliceOutOfBounds` ones) crash
the test suite when running it without bounds checks.  It feels like
they should not be run at all without those checks.
@lehins
Copy link
Contributor

lehins commented Aug 18, 2021

I have two questions:

  • Why would you ever try to disable boundschecks? I personally think that flag should be removed from vector because it is way too dangerous
  • Why would even want to run or expect tests to pass with boundschecks flag disabled?

I am not in favor of this PR or supporting that flag period. I'd rather users explicitly use unsafe* functions instead of letting partial functions become unsafe with a flip of a switch. @Shimuuar and @Bodigrim what are your thought on the boundschecks flag?

@Bodigrim
Copy link
Contributor

I have a use case for boundschecks flag: temporarily disabling it provides a convenient way to estimate how much performance can be gained by switching to unsafe functions. On the other hand, running tests with boundschecks disabled seems a bit pointless to me.

@Shimuuar
Copy link
Contributor

I agree it's very questionable flag. It changes semantics of library in a very dangerous way.

On other hand if we keep boundscheck flag it makes sense to disable segfaulting tests when bounds checking is off. It allows one to test that disable bounds checks doesn't break anything

@kenranunderscore
Copy link
Contributor Author

  • Bodigrim's use case was pretty much the one where I encountered the issue: we were trying to see if performance could be gained some way or other.
  • The default for the Haskell packages in nixpkgs is that the test suites are all run as part of the nix-build. After disabling the flag that's basically just what happened and where I encountered the crash. I agree though that I probably wouldn't even have tried running the tests if I had used a local copy of vector to experiment with. Nevertheless a crash is somewhat unexpected as compared to failing tests without the flag.

@mikesperber
Copy link

* Why would even want to run or expect tests to pass with `boundschecks` flag disabled?

We're using it exclusively through vector-sized, which provides proofs that the bounds are respected. Presumably, leaving out the dynamic bounds checks could then be elided.

@lehins
Copy link
Contributor

lehins commented Aug 19, 2021

We're using it exclusively through vector-sized, which provides proofs that the bounds are respected

Even in that case I'd recommend using unsafe* functions for the sake of a person who is reading the code. That is a global flag, which must be explicitly turned off at compile time, which means it carries invalid information to the reader of the code.

Looks like we have a tie among maintainers about the boundschecks flag and its support in the test suite. However, it seems that people use it for odd reasons here and there, so merging. @kenranunderscore thank you for submitting this PR

@lehins lehins merged commit f2339ea into haskell:master Aug 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants