rdmd.d: Capture stderr when calculating dependencies

[the-horo]

When invoking the compiler to calculate dependencies capture both stdout and stderr since gdc's verbose output goes to stderr.

[dlang-bot]

Thanks for your pull request and interest in making D better, @the-horo! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + tools#469"

[thewilsonator]

auto process = spawnProcess(args, stdin, outputFile,  captureStderr ? outputFile : stderr);

[the-horo]

It seems that having both stdout and stderr be the same file breaks something, see the ubuntu-latest test failure.

As for my tests, when they fail, because they only sometimes fail, they always fail at

tools/rdmd_test.d

Lines 205 to 207 in 1a8c1a9

	res = execute(rdmdArgs ~ ["--force", forceSrc]);
	enforce(res.status == 0, res.output);
	enforce(res.output.canFind("compile_force_src")); // force will re-compile

The output has, so far, been "". One more reason to postpone this PR.

[CyberShadow]

1. rdmd and GDC are both very old, why is this change needed now? Has it never worked with GDC?

2. Wouldn't this also swallow error messages from the compiler that the user should be able to see?

3. Would it not be better to make the change in GDC (or at least its gdmd wrapper), so that it conforms to the same behavior as the other compilers?

[CyberShadow]

CC @ibuclaw

[the-horo]

1. rdmd and GDC are both very old, why is this change needed now? Has it never worked with GDC?

The tests fail with gdc so I guess not.

2. Wouldn't this also swallow error messages from the compiler that the user should be able to see?

Yes, they do, that's too bad a consequence to allow as is. Is it enough if we displayed the collected stderr? I can think of either this or rerunning the failed command without changing how gdc or gdmd work.

3. Would it not be better to make the change in GDC (or at least its `gdmd` wrapper), so that it conforms to the same behavior as the other compilers?

Since gdmd is just a wrapper, I don't know how it would be able to split the -v output into legitimate output tied to stdout and error messages displayed on stderr.

[CyberShadow]

Since gdmd is just a wrapper, I don't know how it would be able to split the -v output into legitimate output tied to stdout and error messages displayed on stderr.

It could pass an internal switch to the command it's wrapping, which redirects these messages to standard output. I think that's what the ldmd command does for LDC, though there, it's not a wrapper but a driver (so it talks to the compiler implementation via function calls instead of subprocesses).

[CyberShadow]

Yes, they do, that's too bad a consequence to allow as is. Is it enough if we displayed the collected stderr? I can think of either this or rerunning the failed command without changing how gdc or gdmd work.

I think we should try to pursue the third option first. If that doesn't work, then I think that would be OK provided that we only do this redirection for GDC. Since we're already parsing the output, we could also re-print all lines that we couldn't parse (and are therefore likely messages intended for the user).