Control expensive assertion in Distribution.Solver.Modular.Linking with a build flag. #4346
Conversation
I added a function, 'debugAssert', that wraps 'assert' and only calls it when the build flag 'debug-assertions' is enabled. The flag defaults to false. I only replaced one call to 'assert' so far (in Distribution.Solver.Modular.Linking) in order to resolve haskell#4258.
cabal-install/cabal-install.cabal
Outdated
| @@ -189,6 +189,11 @@ Flag network-uri | |||
| description: Get Network.URI from the network-uri package | |||
| default: True | |||
|
|
|||
| Flag debug-assertions | |||
There was a problem hiding this comment.
Bikeshedding: what about introducing a flag assertions and call this one expensive-assertions to make it more clear what's going on? Then I guess debugAssert could be renamed to expensiveAssert. What do you think?
There was a problem hiding this comment.
Or, given that we already have debug-tracetree, we could also have debug-assertions for ghc-options: -fno-ignore-asserts and debug-expensive-assertions for expensive ones.
There was a problem hiding this comment.
I like the names debug-expensive-assertions and expensiveAssert. I think that it would be simpler to use ghc-options: -fno-ignore-asserts to enable the usual assertions in cabal.project, though, because we could set the same flag for all packages:
Line 11 in 9348682
|
Everything looks good to me, merging. |
|
Merged, thanks! |
|
Thanks! |
I added a function,
debugAssert, that wrapsassertand only calls it whenthe build flag
debug-assertionsis enabled. The flag defaults to false. Ionly replaced one call to
assertso far (in Distribution.Solver.Modular.Linking)in order to resolve #4258.
I enabled
debug-assertionsin a new GHC 8.0.1 build job, because I figured that it is important to continue testing with the default flag settings in all of the other matrix entries. I could set-fdebug-assertionsin one of the existing jobs instead, if it's not worth creating a separate job.I can also make a PR for the 2.0 branch.