fix Issue 18729 - dmd -run executes in different environment

[marler8997]

TLDR: the following fails on windows

echo void main(){} > voidmain.d
dmd -run rdmd.d -m64 voidmain.d

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : OUT
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : LIBPATH
...

I ran into this problem when I was running a D program via dmd -run that itself invoked DMD. The resulting program was invoking the compiler with -m64, but the original dmd -run did not use -m64. This caused a problem because the first invocation of the compiler set the LINKCMD environment variable to the OPTLINK executable, which caused the second invocation to use the OPTLINK executable but it treated it like the MSVC linker because it was running in 64-bit mode.

The solution here is to maintain the original environment (the environment before it was changed by the compiler) when dmd -run executes the compiled program. This PR accomplishes this by saving the original values of environment variables when they are overwritten and then restoring these values before executing the compiled program.

[dlang-bot]

Thanks for your pull request and interest in making D better, @marler8997! 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

Auto-close	Bugzilla	Severity	Description
✓	18729	normal	dmd -run executes in different environment

Testing this PR locally

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

dub fetch digger
dub run digger -- build "master + dmd#8121"

[WalterBright]

There seems to be a lot of converting char* to [] and back again. Wouldn't it be simpler to just leave them as char*?

[marler8997]

There seems to be a lot of converting char* to [] and back again

Alot? This is the one and only place in this change that we're calling toCStringThen. And we're not converting name back to a DString, we're converting the return value of getenv to a DString.

We're using the char[] version of name for both the comparison and to pass to the LocalEnvVar allocation function. We only need the char* version to call getenv. I'm not sure what you'd like me to change here.

[marler8997]

@WalterBright I've integrated all your suggestions except the one about toCStringThen since I'm not sure what you want for that suggestion. Please let me know what you'd like me to do next here.

[WalterBright]

Thank you. In thinking about it some more, what's happening is simply storing name=value pairs, and avoiding making duplicate entries for name. This is exactly what D associative arrays do. You can dispense with the new structs, and just use:

__gshared string[string] envNameValues;

Use the in operator to test for membership, and foreach to iterate over envNameValues.

[marler8997]

Ok, I've changed the code per your suggestions.

[WalterBright]

Much better.

[marler8997]

Thanks alot for guiding this through to the finish line.