Warning: "debug build with assertions" interferes with --numeric-version

[andreasabel]

The warning printed by the cabal development version interferes with collecting output, e.g.

CABAL_VERSION=$(cabal --numeric-version)

will usually set CABAL_VERSION to something like 3.8.1.0, but for the development version it is the warning-string followed by the version:

$ echo $CABAL_VERSION
Warning: this is a debug build of cabal-install with assertions enabled. 3.9

The problem is that this warning is printed to stdout with normal verbosity:

cabal/cabal-install/main/Main.hs

Lines 192 to 198 in 399cf64

	warnIfAssertionsAreEnabled :: IO ()
	warnIfAssertionsAreEnabled =
	assert False (return ()) `catch`
	(\(_e :: AssertionFailed) -> warn normal assertionsEnabledMsg)
	where
	assertionsEnabledMsg =
	"this is a debug build of cabal-install with assertions enabled."

I think this warning should only be printed with increased verbosity, e.g. -v2.

What confuses me is that -v0 does not seem to have any effect:

$ cabal -v0 --numeric-version
Warning: this is a debug build of cabal-install with assertions enabled.
3.9

I still see this well-meant but silly warning.

[Mikolaj]

I suppose normal verbosity is needed to help people avoid surprises. However, -v0 should work, so it's worth investigating. Also, I think there is a ticket about printing warnings (and errors?) to stderr.

[andreasabel]

Also, I think there is a ticket about printing warnings (and errors?) to stderr.

We have:

• cabal run should send info logging to stderr not stdout #7790
• Use stderr for Cabal's diagnostic messages instead of stdout #4789
• Write debug output to stderr #7838
• ...

This topic has a history...

I suppose normal verbosity is needed to help people avoid surprises.

Why do we need this warning preemptively at all? Couldn't we just add it as explanation if an actual assertion is thrown? In >99% of my invocations of cabal, this message is just spamming me.

I'd think the best path of action here (if we want to avoid the thickets of stdout vs stderr) is to remove the warning and only utter it when an assertion failed.

[Mikolaj]

Some history:

• Print a warning when assertions are enabled #8240
• Updated warning message to output on stderr #8396

[andreasabel]

Ok, to not start a revolution, I submitted a modest PR that shifts the warning to stderr and restricts it to normal operation of cabal, i.e. not in special commands such as help and version:

• Fix #8645: no assertion warning on special modes (help, version, etc.) #8647

[ulysses4ever]

I like the idea of printing it only when an assertion actually fails.

[grayjay]

I like the idea of printing it only when an assertion actually fails.

I think that the main purpose of the warning is to warn about decreased performance.

[andreasabel]

@grayjay wrote:

I think that the main purpose of the warning is to warn about decreased performance.

Digging the history I saw that once this warning had some text about decreased performance. Do you know why this part was dropped?

[gbaz]

Just as a historical note, there was certainly a case I found at some point where we were shipping binaries that accidentally had assertions on, leading to vastly decreased solver performance. I think having some warning in at least some cases is a good guard against this.

[grayjay]

Digging the history I saw that once this warning had some text about decreased performance. Do you know why this part was dropped?

Which warning mentioned decreased performance? Are you referring to the expensive assertions mentioned in #8240? They were only enabled with a custom build flag, so they were not easy to enable unintentionally.

[andreasabel]

@grayjay: Ah, it was in a PR that didn't get merged as such:

• Print a warning when assertions are enabled. #4552