A few verification checks need to happen until all AST's have been
traversed, specifically for zippered framework checking. To keep source
location until that time valid, hold onto to references of
FrontendRecords + SourceManager.
* Capture reexported libraries, allowable clients, rpaths, shared cache
eligibility.
* Add support for select Xarch options.
* Add diagnostics related to capturing these options.
* Add support for verifying these attributes against what is encoded in
the dylib.
InstallAPI does not directly look at object files in the dylib for
verification. To help diagnose violations where a declaration is
undiscovered in headers, parse the dSYM and look up the source location
for symbols. Emitting out the source location with a diagnostic is
enough for some IDE's (e.g. Xcode) to have them map back to editable
source files.
Reported by Static Analyzer Tool:
In clang::installapi::InstallAPIVisitor::VisitFunctionDecl(clang::FunctionDecl
const *): Using the auto keyword without an & causes the copy of an
object of type DynTypedNode.
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.
* This completes support for verifying every declaration found in a
header is discovered in the dylib. Diagnostics are reported for each
class for differences that are representable in TBD files.
* This patch also now captures unavailable attributes that depend on
target triples. This is needed for proper tbd file generation.
This adds basic support for calling the verifier on global declarations
that are expected to represent symbol exports. The driver now
exclusively uses this for knowing what symbols make up a TBD file.
Future patches will check against the dylib's symbol table.
Before it gets too unwieldy, add a common header for all MachO types
that are used across InstallAPI. Also, break up the types in
`InstallAPI/Frontend`. This both avoids circular dependencies and is
logically easier to maintain as more functionality gets added.
This includes capturing symbols for global variables, functions,
classes, and templated defintions. As pre-determing what symbols are
generated from C++ declarations can be non-trivial, InstallAPI only
parses select declarations for symbol generation when parsing c++.
For example, installapi only looks at explicit template instantiations
or full template specializations, instead of general function or class
templates, for symbol emittion.
* Include whether functions are inlinable as they impact whether to add
them into the tbd file and for future verification.
* Fix how clang arguments got passed along, previously spacing was
passed along to CC1 causing search path inputs to look non-existent.
* This patch introduces a container class, for holding records and
attributes only collectible from the clang frontend, which is a subclass
of `llvm::MachO::RecordsSlice`
* This also prunes out collecting declarations from headers that aren't
considered input to installapi.
* Uses these constructs for collecting global objective-c interfaces.
This patch takes in json files as input to determine that header files
to process, and in which order, to pass along for CC1 invocations. This
patch also includes an ASTVisitor to collect simple global variables.
Installapi has important distinctions when compared to the clang driver,
so much that, it doesn't make much sense to try to integrate into it.
This patch partially reverts the CC1 action & driver support to replace
with its own driver as a clang tool.
For distribution, we could use `LLVM_TOOL_LLVM_DRIVER_BUILD` mechanism
for integrating the functionality into clang such that the toolchain
size is less impacted.
This patch adds support for expected InstallAPI inputs. InstallAPI
accepts a well defined filelist of headers and how those headers
represent a single library.
InstallAPI captures header files to determine linkable symbols to then
compare against what was compiled in a binary dylib and generate TBD
files.
This introduces a basic outline of installapi as a clang driver option.
It captures relevant information as cc1 args, which are common arguments
already passed to the linker to encode into TBD file outputs. This is
effectively an upstream for what already exists as `tapi installapi` in
Xcode toolchains, but directly in Clang. This patch does not handle any
AST traversing on input yet.
InstallAPI is broadly an operation that takes a series of header files
that represent a single dynamic library and generates a TBD file out of
it which represents all the linkable symbols and necessary attributes
for statically linking in clients. It is the linkable object in all
Apple SDKs and when building dylibs in Xcode. `clang -installapi` also
will support verification where it compares all the information recorded
for the TBD files against the already built binary, to catch possible
mismatches like when a declaration is missing a definition for an
exported symbol.
