It looks like commit 46580d43fc70d migrated the flags from llvm::cl to
OptTable. As a result, the flag behaviour changed. Commit
e29e30b1397f3e50f3487491f8a77ae08e4e3471 from 2019 went through and
changed the llvm tests to consistently use the double-dash for long
options so it was undetected.
With this info, I'm just going to go ahead and fix these tests cases to
get them going again.
PE/COFF does not include a symbol table in the generated executable
binary. Instead, use `public` to expose the getter, and then use
`-coff-exports` from `llvm-readobj` to get the symbols that are
exported. Fortunately, the same tool can be used to list the symbol
table contents for ELF and MachO binary. This allows us to share the
test across all the targets.
We cannot link against the DSO (dll) on Windows and instead link against
the import library. Let the driver understand this and use the standard
linking technique. Adjust the name of the emitted files accordingly and
use the `%target-library-name` macro more freely.
Two tests remain:
- multifile.protocol-conformance-member
The getter is synthesized by not exported so `llvm-nm` is unable to
see it
- multifile.nested_types
Windows uses the singleton strategy, so the emitted full type
metadata does not have the reference to the value witness table for
Void
Rather than relying on the system to provide ar and nm, use the LLVM equivalent
tools instead. Since the build is already dependent on llvm and its tools, this
just ensures that the full set is self-contained. NFC.
