Mark output in LogProgress#11753
Conversation
1af3dfb to
d54a5eb
Compare
|
CI is passing, just a spurious network blip in one of the jobs. |
|
Anyone else willing to review? Very straightforward change. It's mainly motivated by #11703 because, in that patch, we more often go via the |
Cabal's Distribution.Utils.LogProgress module failed to take into
account whether we are marking output or not, and simply never included
output markers.
We also make sure that warnings go to stderr not stdout, to be
consistent with `Distribution.Simple.Utils.warnMessage`.
In summary, the impact is that:
- warning messages now consistently go to stderr
- when running the testsuite, we are more consistent in tagging
messages emitted by Cabal, with the 'BEGIN CABAL OUTPUT'/'END CABAL OUTPUT'
markers.
I see no changes in testsuite outputs. Is that expected? |
Yes, it turned out there weren't any tests that needed updating as none of the test that use marked output were going via the LogProgress codepath. That was not the case for the "info messages" (mostly Backpack debugging messages), which is why I kept them non-marked (otherwise a huge amount of tests needed to adapt to new output because of gobs of Backpack noisy output). |
Merge Queue Status
This pull request spent 10 minutes 8 seconds in the queue, including 2 seconds running CI. Required conditions to merge
|
Cabal's
Distribution.Utils.LogProgressmodule failed to take into account whether we were marking output or not, and simply never included output markers. This PR rectifies that.We also make sure that warnings go to stderr not stdout, to be consistent with
Distribution.Simple.Utils.warnMessage.In summary, the impact is that:
BEGIN CABAL OUTPUT/END CABAL OUTPUTmarkers.TODO:
Template B: This PR does not modify behaviour or interface. It only modifies output marking, which is an internal mechanism for the testsuite.