Pass a wrapped VFS down into `clang::createInvocationFromCommandLine` so
that the working directory is set and then used in the underlying Clang
`CompilerInstance`.
Fixes the possibility of differing modules hashes when the same
arguments are used in Clang directly vs from the importer.
Resolves rdar://79376364
This enables additional tests for the ClangImporter. This found a
missing piece in the `-enable-objc-interop` work that was done
previously. Address that and enable the tests. There are now the
following failing tests on Linux:
* sdk - depends on Foundation (not hermetic, see SR-7572)
* mixed-nsuinteger - depends on Foundation (not hermetic, see SR-7572)
* import-mixed-with-header-twice - requires apple/swift PR#16022
* can_import_objc_idempotent - requires apple/swift PR#16022
* objc_protocol_renaming - requires apple/swift PR#16022
This works a around search path problems caused by a module existing
in both the build/install directory and the source directory.
<rdar://problem/35714074>
When swift-ci ran the tests, it looks like `%target-os` was "linux-gnu”, which wasn’t listed in the Testing Swift document (ony listing `macosx`, `darwin`, `linux`, `freebsd`, `windows-cygnus`, and `windows-gnu`)
Since I can’t (at least don’t know how to) run the linux tests myself, I’ll try and update the check-prefix to see if that passes.
When Objective-C interop is enabled, modules will continue to be referred to as “Objective-C modules”. But when interop is disabled, they will be referred to as “C modules”.
Updated the existing test for the current behavior that doesn’t expect to fail on linux and doesn’t require objc_interop, so that it checks to different diagnostics on the two systems.
