[Tests] - FIX - several tests to run on linux target.

[JhonnyBillM]

This PR removes several target specific arguments and/or platform conditional checks in some SwiftDriverTests. We still need to determine what to do with tests that use specific macOS tooling such as dsymutil or libtool.

---

Questions:

1. Do we want to get completely rid of the /usr/bin/ hack or should we keep it to have some cleaner tests? ¹

2. We can remove the specific platform target in testMultiThreadedWholeModuleOptimizationCompiles and in testWholeModuleOptimizationOutputFileMap and they are going to work on both platforms. Can I remove the specific target or is it there for any other reason to have it there?

¹ Right now if we completely remove the hack, testLinking and testSanitizerArgs will fail because they require macOS specific tools such as dsymutil and libtool, we could probably update those tests similar to what we did in testDSYMGeneration, or just do a platform conditional check (but I understand that we are also trying to get rid of those platforms checks). So what I would like to know is the way we would like to proceed on those situations.

[DougGregor]

@swift-ci please test

[DougGregor]

This PR removes several target specific arguments and/or platform conditional checks in some SwiftDriverTests. We still need to determine what to do with tests that use specific macOS tooling such as dsymutil or libtool.

Questions:

1. Do we want to get completely rid of the /usr/bin/ hack or should we keep it to have some cleaner tests? ¹

I'd like a way to replace the /usr/bin hack with something that doesn't run outside of the specific unit tests that need it. Perhaps use an environment variable to pass through a flag that says it can fall back? That'll make the tests themselves cleaner.

2. We can remove the specific platform target in testMultiThreadedWholeModuleOptimizationCompiles and in testWholeModuleOptimizationOutputFileMap and they are going to work on both platforms. Can I remove the specific target or is it there for any other reason to have it there?

You can remove the specific target. Those tests don't need to be target-specific.

¹ Right now if we completely remove the hack, testLinking and testSanitizerArgs will fail because they require macOS specific tools such as dsymutil and libtool, we could probably update those tests similar to what we did in testDSYMGeneration, or just do a platform conditional check (but I understand that we are also trying to get rid of those platforms checks). So what I would like to know is the way we would like to proceed on those situations.

Hmm. testDSYMGeneration really does want to check for the dSYM generation command, so it probably makes sense to keep it target-specific. testLinking and testSanitizerArgs are cross-platform tests, though, so the test could expect dSYM generation when the selected toolchain is Darwin and not otherwise.

It's interesting, because we benefit both from the tests checking the driver on the host platform and for checking the cross-compile case. Maybe there's some future factoring where we can run the target-independent tests with a couple of different target triples that are independent from the host's triple, to make sure the driver behaves the same way when cross-compiling.

[DougGregor]

This is looking very good! Just the one dSYM bit I'd like to get cleaned up before we merge, thank you!

[DougGregor]

Here, I'd rather either keep the test target-specific (since we're testing a Darwin target feature) or use an isDarwin check on the selected toolchain to determine whether we should expect a .generateDSYM option. As this test is written, it will pass even if we made a mistake and stopped generating dSYMs on Darin

[DougGregor]

Looks great, thank you!

[DougGregor]

@swift-ci please test

[JhonnyBillM]

@DougGregor

1. I would like to know your opinion about the naming here.

2. Should we have all the environment variables listed in one place?
   I tried to look how other swift projects handles this but found nothing in particular. I think it would be nice to have a place where we define our environment variables, the naming convention and their purpose 🤔

[DougGregor]

I'm fine with the name as is; it clearly indicates that it's for testing purposes. It would certainly be good for us to document the environment variables we respond to... we don't really have user-level documentation yet, but we could create a docs/EnvironmentVariables.md for now and figure out how we want to evolve the docs over time.

[DougGregor]

@swift-ci please test