Darwin: Implement sysroot flag

[etcwilde]

The sysroot flag is designed to control where the compiler looks for the C runtimes and headers that one would normally find in an SDK for a system. Apple SDKs contain both the Swift runtimes and the other platform libraries, so under normal circumstances, this flag isn't needed.

It is useful, however, for consistency and testing purposes. As we're bringing up the split runtime/compiler build on the main repository, having the ability to tell the compiler under test to use the just-built Swift runtimes, but also where to find the existing system libraries (libsystem.tbd, e.g.) is incredibly useful.

If the sysroot flag is set, it take precedence for the clang importer and clang-linker.
If the sysroot flag is left unset but an sdk flag is set, the compiler should implicitly fall back on the sdk flag, which is the current behavior.
Finally, if neither are set, it falls back on whatever default the frontend uses, and no special flags are forwarded.

[etcwilde]

@swift-ci please test

[compnerd]

This might be better expressed as:

if let sysroot = parsedOptions.getLastArgument(.sysroot)?.asSingle ?? targetInfo.sdkPath?.path {
  commandLine.appendFlag("--sysroot")
  try commandLine.appendPath(VirtualPath(path: sysroot))
}

[etcwilde]

the sdkPath is a VirtualPath.Handle, not a string. I don't think we can merge these like this.

[etcwilde]

It might make sense to refactor constructing the virtual path for the sysroot though?

[etcwilde]

For the next PR, refactors this to store both as TextualVirtualPath objects in the driver so that we can merge these clauses: etcwilde@fe2bd92

[compnerd]

I tend to prefer test.swift or something other than "foo" given its unfortunate history.

[etcwilde]

I feel like I missed something while I was out. When was foo disallowed, and why?

[etcwilde]

The test failure is:

<big wall of text> does not contain [SwiftDriver.Job.ArgTemplate.flag("-fmodule-file=SAL=C:\\Users\\ContainerAdministrator\\AppData\\Local\\clang\\ModuleCache\\SAL-C0NRIAP58RED50SQXNKMXXKN.pcm")]

in one of the explicit module build tests. I don't believe that this change is related to that failure, but it looks like things haven't been testing or merging cleanly for a while here so I can't really make out what I should expect.

[cachemeifyoucan]

You need to run swift-ci test and that is the only blocking PR testing.

That failure is fixed in #2074 and I just merged. There might still be other issue.

[compnerd]

@swift-ci please test

[etcwilde]

@swift-ci please test Windows

[etcwilde]

@swift-ci please test

[etcwilde]

@swift-ci please test Windows

[finagolfin]

Apple SDKs contain both the Swift runtimes and the other platform libraries, so under normal circumstances, this flag isn't needed.

It is useful, however, for consistency and testing purposes.

Not just for that, I took a look at the macOS CI after we discussed this new flag on the Build and Packaging workgroup call a couple weeks ago and I see that the -sdk and -resource-dir flags are used extensively there to bring up the Swift stdlib on macOS, just like it would be for iOS and so on. That doesn't even include all the compiler validation suite tests that use the -sdk flag to find the same Darwin C/C++ headers and libraries that you would like to use this new -sysroot flag for instead.

If the plan is to move that Darwin build to this -sysroot flag and a -sdk flag with changed behavior, you really should run this pull through a stdlib build and the compiler validation suite using this new -sysroot flag instead. Otherwise, you won't even know of holes that remain in this -sdk/-sysroot implementation until way down the line, similar to the holes I have listed for non-Darwin platforms in swiftlang/swift#79657.