This PR fixes two crashes in ExtractAPI that occur when decls are
requested via libclang:
- A null-dereference would sometimes happen in
`DeclarationFragmentsBuilder::getFragmentsForClassTemplateSpecialization`
when the template being processed was loaded indirectly via a typedef,
with parameters filled in. The first commit loads the template parameter
locations ahead of time to perform a null check before dereferencing.
- An assertion (or another null-dereference) was happening in
`CXXRecordDecl::bases` when processing a forward-declaration (i.e. a
record without a definition). The second commit guards the use of
`bases` in `ExtractAPIVisitorBase::getBases` by first checking that the
decl in question has a complete definition.
The added test `extract-api-cursor-cpp` adds tests for these two
scenarios to protect against the crash in the future.
Fixes rdar://140592475, fixes rdar://123430367
When an anonymous type has a typedef we normally use the typedef's name
in places where we expect a named identifier in the symbol graph. This
extends this logic to apply to subheadings.
rdar://136690614
As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
Extension SGFs require the module system to be enabled in order to discover which module defines the extended external type.
This patch ensures the following:
- Associate symbols with their top level module name, and that only top level modules are considered as modules for emitting extension SGFs.
- Ensure we don't drop macro definitions that came from a submodule. To this end look at all defined macros in `PPCalbacks::EndOfMainFile` instead of relying on `PPCallbacks::MacroDefined` being called to detect a macro definition.
This is an enabler for https://github.com/llvm/llvm-project/pull/92855
This allows an NTTP default argument to be set as an arbitrary
TemplateArgument, not just an expression.
This allows template parameter packs to have default arguments in the
AST, even though the language proper doesn't support the syntax for it.
This allows NTTP default arguments to be other kinds of arguments, like
packs, integral constants, and such.
This is an enabler for a future patch.
This allows an type-parameter default argument to be set as an arbitrary
TemplateArgument, not just a type.
This allows template parameter packs to have default arguments in the
AST, even though the language proper doesn't support the syntax for it.
This will be used in a later patch which synthesizes template parameter
lists with arbitrary default arguments taken from template
specializations.
There are a few places we used SubsType, because we only had a type, now
we use SubstTemplateArgument.
SubstTemplateArgument was missing arguments for setting Instantiation
location and entity names.
Adding those is needed so we don't regress in diagnostics.
Previously we only generated declaration fragments for template type
parameters/arguments, this adds supports for most other possible
template parameters/arguments.
rdar://127732598
This changes the handling of anonymous TagDecls to the following rules:
- If the TagDecl is embedded in the declaration for some VarDecl (this
is the only possibility for RecordDecls), then pretend the child decls
belong to the VarDecl
- If it's an EnumDecl proceed as we did previously, i.e., embed it in
the enclosing DeclContext.
Additionally this fixes a few issues with declaration fragments not
consistently including "{ ... }" for anonymous TagDecls. To make testing
these additions easier this patch fixes some text declaration fragments
merging issues and updates tests accordingly.
rdar://121436298
Reenables b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
Also adds a new warning for missing `--symbol-graph-dir` arg when
`--emit-extension-symbol-graphs` is provided. This also reverts the
commit that removed.
The names of template arguments in partial specializations or parameters
used as types might be mangled according to index and depth. Instead of
looping through parameter lists to find matches like we do now, they can
be deduced via their QualTypes or as written from the AST.
This extends ExtractAPI to take into account symbols defined in categories to types defined in an external module.
This introduces 2 new command line flags, `--symbol-graph-dir=DIR` and `--emit-extension-symbol-graphs`, when used together this generates additional symbol graph files at `DIR/ExtendedModule@ProductName.symbols.json` for each external module that is extended in this way.
Additionally this makes some cleanups to tests to make them more resilient and cleans up the `APISet` data structure.
When generating declaration fragments for types that use typedefs to
pointer types ensure that we keep the user-defined typedef form instead
of desugaring the typedef.
rdar://102137655
Ensure that block types get represented correctly in declaration
fragments, as block parameter names are important for documentation
clients we need a separate system from getFragmentsForType in order to
have access to full ParmVarDecls for the parameters.
rdar://118257401
This patch moves ElaboratedTypeKeyword before `Type` definition so that the enum is complete where bit-field for it is declared. It also converts it to scoped enum and removes `ETK_` prefix.
This patch moves `ArraySizeModifier` before `Type` declaration so that it's complete at `ArrayTypeBitfields` declaration. It's also converted to scoped enum along the way.
getFragmentsForType resulted in a bool typeIdentifier fragment to be spelled "_Bool".
This fixes the spelling to be "bool" and checks it in C and C++.
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D158474
Visit and serialize C++ fields by checking if a var template's context is a CXXRecordDecl in VisitVarTemplateDecl.
Depends on D158027
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D158029
Add records, serialization for global function templates and their specializations
Depends on D157350
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D157579
Serialize global C++ variable templates and specializations.
Depends on D157076
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D157350
Add has_template template, DeclarationFragmentBuilder functions, and tests for class templates, specializations/partial specs, and concepts.
Depends on D157007
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D157076
Reintroduce D153557 with fix for use-after-free from f4de606ef271 and minor changes.
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D157007
Use CRTP to enable creating statically dispatched subclasses of
ExtractAPIVisitor.
This enables adding extension points and customising the behavior more
easily.
This is used in CXExtractAPI.cpp to create a specialized visitor for
Libclang as well as streamlining the batch implementation in ExtractAPIConsumer.cpp
This is mainly adding an entry point to `SymbolGraphSerializer` at
`serializeSingleSymbolSGF` and exposing the necessary data to make this
possible. Additionaly there are some changes to how symbol kinds and
path components are serialized to make the usage more ergonomic in
`serializeSingleSymbolSGF`.
On the libclang side this introduces APIs to:
- create an APISet from a TU
- dispose of an APISet
- query an APISet for a single symbol SGF for a given USR.
- generate a single symbol SGF for a given CXCursor, this only traverses
the necessary AST nodes to construct the result as oppposed as going
through the entire AST.
Differential Revision: https://reviews.llvm.org/D139115
There is a bug in `DeclarationFragments::appendSpace` where the space
character is added to a local copy of the last fragment.
Differential Revision: https://reviews.llvm.org/D123259
Add (partial) support for Objective-C category records in ExtractAPI.
The current ExtractAPI collects everything for an Objective-C category,
but not fully serialized in the SymbolGraphSerializer. Categories
extending external interfaces are disgarded during serialization, and
categories extending known interfaces are merged (all members surfaced)
into the interfaces.
Differential Revision: https://reviews.llvm.org/D122774
