Allow tests to link against executable targets

[abertelrud]

Experimental changes to allow test products to link against both Swift and Clang executable targets. This allows them to test everything except the main function in those targets without having to run the executable as a subprocess.

Motivation:

Many package authors don’t want to split their code into executable targets vs library targets, but still want to test data structures and algorithms in their executables.

Modifications:

This is experimental and not suitable for merging yet. It uses nmedit to elide the _main symbols from .o files from executables when a test product links them. This only works on Darwin; on Linux and Windows, the strip tool should usable but that hasn’t yet been tried.

There are several issues to address:

• this isn’t particularly portable, since different implementations are required on different platforms; currently only Darwin is supported
• it isn’t great from a performance perspective to have to create custom versions of the .o files from the executables
• there isn’t any way for a unit test that depends on an executable to indicate whether it just wants a build-time dependency on the product or whether it wants to link against it
• there’s something a bit conceptually shady about treating executables as libraries, so we will likely want to limit the types of targets that are allowed to link against executables to just unit tests
• whatever tool is invoked on a particular platform should be found using the toolchain using a proper accessor
• there are numerous FIXMEs in the code, especially related to the support for Clang executables
• the test fixture isn’t yet being used

In the long run it would be better to have Swift and Clang changes to conditionally emit any _main symbol to a separate .o file that could be either included or excluded from a particular link command.

Result:

Unit tests that declare dependencies on executable targets will link against that code as well. We will need to consider the compatibility impacts of this, and might need to tie it to a tools version.

rdar://58122395

[abertelrud]

@swift-ci please smoke test

[compnerd]

I think that we should possibly look at an older change of mine - marking main as hidden by default in the Swift compiler. In the case that the symbol is needed (because you are an executable) the C stub should cause it to be preserved via _start referencing main. That would obviate the need for the execution of nmedit and make this path identical across all the platforms.

BTW, strip is technically not available on Windows (although the current Swift toolchains being distributed do include it and thus would be there).

[abertelrud]

I think that we should possibly look at an older change of mine - marking main as hidden by default in the Swift compiler. In the case that the symbol is needed (because you are an executable) the C stub should cause it to be preserved via _start referencing main. That would obviate the need for the execution of nmedit and make this path identical across all the platforms.

Yes, doing this on the .o production side would definitely be better, though it wouldn't allow testing of Clang executables (not sure how important that is but it would be somewhat inconsistent). I'm not sure how feasible such a change would be, or how long that would take, but editing the symbol after-the-fact is definitely a stopgap.

BTW, strip is technically not available on Windows (although the current Swift toolchains being distributed do include it and thus would be there).

Right, that's what I actually meant to say (that it's currently available in the toolchain). I think on Linux as well, it comes from binutils which has to be installed via apt-get, etc.

[tomerd]

should not be required any longer?

[abertelrud]

Probably not. I’ll try without it.

[tomerd]

should not be required any longer?

[abertelrud]

@swift-ci please smoke test

[abertelrud]

@swift-ci please smoke test

[abertelrud]

Update: I will be reworking this to use the new Swift compiler flag in swiftlang/swift#35595.

[abertelrud]

This is superseded by #3316 so I'm withdrawing this PR.