Every time DarwinSDKInfo reads a new key out of SDKSettings, a boatload
of test SDKSettings files need to be updated across several repositories
and forks and branches. It’s tedious to be careful to update those with
real values so that the tests are properly regression testing older
SDKs. It’s important to be careful so that the tests are accurate, e.g.
to prevent the scenario where DarwinSDKInfo starts reading a new key out
of SDKSettings and assumes that it’s always available everywhere, when
in reality it was only added a few releases ago and will break with
older SDKs. If the test SDKSettings files continue to be updated ad hoc,
it’s going to be really easy to copy/paste a default value everywhere,
and then clients will see incorrect behaviors with the real SDKs, or
even compiler crashes if the key is unconditionally read. Preemptively
add all of the maybe-possibly-compiler relevant keys to the test
SDKSettings files from the real SDKs so that the test files are an
accurate representation and shouldn't need to be touched in the future.
Where the test SDKSettings have intentionally doctored data, add a
Comments key explaining what is changed from the real SDK, and alter the
SDK name with a tag indicating the change.
The search path prefix is really a property of the SDK, and not the
target triple. The target is just being used as a proxy for the SDK.
That's problematic when the SDK being used doesn't match the target
assumption, and the prefix should be taken from the SDK rather than hard
coded.
Parse the SupportedTargets, which is what holds the platform prefix, in
DarwinSDKInfo. SupportedTargets contains an entry for the SDK's
canonical name, and that entry holds a valid OS value so use that
instead of the hard coded map. Include the environment which is also
relevant in some situations, and the vendor and object format in case
they're useful later. Skip architectures because they typically aren't
used for doing platform matching.
Whether the SDK supports builtin modules is a property of the SDK
itself, and really has nothing to do with the target. This was already
worked around for Mac Catalyst, but there are some other more esoteric
non-obvious target-to-sdk mappings that aren't handled. Have the SDK
parse its OS out of CanonicalName and use that instead of the target to
determine if builtin modules are supported.
Projects like libc use mutually exclusive macros to compile files
multiple times and then merge the result into the final library. For
installapi to accept these, we'd need to parse the same declarations in
different ways. This patch adds the basic pipelining for installapi to
create the correct TBD file.
* -Xproject allows: -fmodules, -fobjc-arc, fvisibility=hidden, prefix
headers
* -Xlabel allows: -D and -U settings
* Error on 'private' and 'public' labels -X<label>
* Xplatform allows: -iframework <path> This is to support the case where
zippered frameworks want to pass in iOSSupport search path.
A zippered framework is a single framework that can be loaded in both
macOS and macatalyst processes. Broadly to InstallAPI, it means the same
interface can represent two separate platforms.
A dylib's symbol table does not distinguish between macOS/macCatalyst.
`InstallAPI` provides the ability for the tbd file to distinct
symbols between them.
The verifier handles this special logic by tracking all unavailable and
obsoleted APIs in this context and checking against those when
determining dylib symbols with no matching declaration.
* If there exists an available decl for either platform, do not warn.
* If there is no available decl, emit a diagnostic and print the source
location for both decls.
Umbrella headers are a concept for Darwin-based libraries. They allow
framework authors to control the order in which their headers should be
parsed and allow clients to access available headers by including a
single header.
InstallAPI will attempt to find the umbrella based on the name of the
framework. Users can also specify this explicitly by using command line
options specifying the umbrella header by file path. There can be an
umbrella header per access level.
This reverts commit b7d8c6188986f62573b9516fe27fdd0c7df1aaf9. And
This reverts commit 2d40f179124f874aca4cf1145fdbc42fb8fb17f3.
It caused a build failure i'll need to reproduce.
` error: could not convert ‘Rule’ from ‘llvm::Regex’ to ‘llvm::Expected<llvm::Regex>’`
InstallAPI takes a json list of headers that is typically generated from
a build system like Xcode based on a project's attributes. Sometimes,
maintainers may want to alter this for tapi input. Using e.g.
`--extra-public-headers`, users can manipulate what headers will be used
for TBD file generation.
