Updated warning message to output on stderr

[SaadAhmedGit]

This Fixes #8393
The message warning about assertions being enabled was previously being output to the stdout stream rather than stderr.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[andreasabel]

Thanks for the PR!

If I infer the intentions of previous cabal developers correctly, there shouldn't be any naked putStr calls ever, but output should be channeled through one of the service functions given here:

cabal/Cabal/src/Distribution/Simple/Utils.hs

Lines 34 to 37 in a97e1f1

	warn,
	notice, noticeNoWrap, noticeDoc,
	setupMessage,
	info, infoNoWrap,

I suppose warn would be what we want here, and warnIfAssertionsAreEnabled then needs a Verbosity argument.

[ulysses4ever]

There's a similar PR right next door: #7838. Maybe you want to pick it up?

[ulysses4ever]

LGTM, thanks! The big stderr switch will have to wait for another day, I guess…

[Mikolaj]

@mergify refresh

[mergify]

refresh

✅ Pull request refreshed

[Mikolaj]

@mergify refresh

[mergify]

refresh

✅ Pull request refreshed

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[andreasabel]

Weird, I commanded "squash + merge me" 4 days ago, but it still isn't merged. I thought the waiting period was 2 days. Is the Mergify way of merging brittle? Should we go back to hit the button manually?

[Mikolaj]

The waiting period probably resets sometimes. I hope not at every manual rebase, but it's possible. As you can see I struggled with broken CI, fixed it, the merge queue was still blocked, so I rebased manually a few times, etc. Last time 2 days ago.

Merging delay is brittle whenever CI is broken.

[ulysses4ever]

Last events I see (before your comments today):

jneira force-pushed the patch-1 branch from 5f395e6 to 0a01a22 2 days ago
Mikolaj added the squash+merge me label 2 days ago

When pointing "2 days ago" with the mouse, I see the exact time and it's less than 48 hours, so I don't see a problem.

I was thinking about this whole system, and I think what makes it take longer are concurrent merges during the 48 hours windows. Because Mergify has to rebase in that case, and that probably qualifies for a timer reset. Also, manual merges probably makes the queue of "law-abiding" (2-day rule preserving) merges to starve (also because of rebase).

It'd be nice to say: merge 2 days after last "significant" event, rather than any event, but that doesn't seem to be possible.

[andreasabel]

It'd be nice to say: merge 2 days after last "significant" event, rather than any event, but that doesn't seem to be possible.

Yes, I think the clock should start ticking once the yellow "merge me" label is set. If one wants to halt the merge process, one would remove that label again.
I suppose the API may not support this; I wonder if/hpw one could report this upstream to Mergify...

Q: Is me commenting here also delaying the merge?

[ulysses4ever]

@andreasabel

Q: Is me commenting here also delaying the merge?

Correct.

[ulysses4ever]

I submitted an issue against Mergify tracker about the spurious delays: Mergifyio/mergify#5036 Feel free to pitch in.

[athas]

Based on my understanding of the code base, this is correct.

[SaadAhmedGit]

Looks like mergify has cancelled putting this PR on squash+merge queue

[ulysses4ever]

It looks fine to me so far. The 2-day timer was reset by the last rebase 9 hours ago (and our comments after that), so we'll have to wait. Unless someone wants to take a liberty and merge it manually.

[andreasabel]

Unless someone wants to take a liberty and merge it manually.

Yes, me.
I am loosing patience with the Mergify procrastinator.

[andreasabel]

Having been hit by

• cabal gen-bounds: Consume (multiple) build plans? #8654

I regret that I requested changes to @SaadAhmedGit 's original fix. The problem is that the warn machinery does not work at this point where command line options are not passed, so it cannot be silenced with -v0. So vanilla printing to stderr would have been better. I'll open a new PR.