| Age | Commit message (Collapse) | Author |
|---|
|
Fixes #106355
|
|
Add back missing includes and revert revert "[clang][ExtractAPI] Stop
dropping fields of nested anonymous record types when they aren't
attached to variable declaration (#104600)"
|
|
types when they aren't attached to variable declaration (#104600)"
This reverts commit c60da1a271a6bb271e7703b2f7c71fbece67ab78.
|
|
when they aren't attached to variable declaration (#104600)
- Introduce primitives for removing records from `APISet` and managing
the record chain of `RecordContext`
- Detect nested anonymous record types and remove them from the `APISet`
after they have been fully traversed and transfer ownership of child
records to the parent context (if any)
|
|
|
|
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.
|
|
(#86676)"
This failed the test suite due to missing DiagGroup for a new warning.
This reverts commit b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
|
|
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.
|
|
Ensure that we generate correct symbol kinds and declaration fragments
for unions in C and Objective-C parsing modes.
rdar://120544091
|
|
platform (#76823)
Currently, ExtractAPI provides availability information for all
platforms within a given domain. With this change, we narrow down the
output to include availability details only for the specified target
platform, so users can generate the symbol graph with only the
availability information they need, omitting information of the other
platforms.
This change reverts the functionality introduced in
[`57c9780`](https://github.com/llvm/llvm-project/commit/57c9780).
rdar://120419037
|
|
These source files do not use function_ref.
|
|
Serialize namespaces, nested namespaces, and class relationships inside them.
Depends on D157076
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D158239
|
|
Refactor visitation for C++ record children by following the Visitor's CRTP.
Expand VisitCXXField, VisitCXXMethod for non-templates and introduce VisitCXXConstructor, VisitCXXDestructor.
Handle relationships by finding the parent's Record via USR from DeclContext.
Depends on D158029
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D158031
|
|
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
|
|
Visit and serialize method templates and template specializations. Introduces a new scheme of visiting child Decls via VisitCXXMethodDecl which will be followed in future patches for Fields and non-template methods.
Depends on D157579
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D158027
|
|
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
|
|
Differential Revision: https://reviews.llvm.org/D152770
|
|
Reintroduce D153557 with fix for use-after-free from f4de606ef271 and minor changes.
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D157007
|
|
This reverts commit 8b76b44e46ac5b4efbf8cb3702f09d353af2a112.
|
|
Add ExtractAPI support C++ classes, fields, methods, and various qualifiers and specifiers
Differential Revision: https://reviews.llvm.org/D153557
|
|
|
|
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
|
|
This was an accidental addition of a non-reviewed change.
This reverts commit f63db9159bbbb0db98e13cb4440fdaa5c40e219b.
|
|
|
|
Currently ExtractAPI only emits availability information for the
current platform. This makes it easy for clients to get all availability
information for a given symbol in one invocation as opposed to having to invoke
clang once per-platform and then merge the symbol-graphs.
Differential Revision: https://reviews.llvm.org/D130918
|
|
Anonymous enums without a typedef should have a "(anonymous)" identifier.
Differential Revision: https://reviews.llvm.org/D123533
|
|
- Split GlobalRecord into two distinct types to be able to introduce
has_function_signature type trait.
- Add has_function_signature type trait.
- Serialize function signatures as part of serializeAPIRecord for
records that are known to have a function signature.
Differential Revision: https://reviews.llvm.org/D123304
|
|
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
|
|
Typedef records consist of the symbol associated with the underlying
TypedefDecl and a SymbolReference to the underlying type. Additionally
typedefs for anonymous TagTypes use the typedef'd name as the symbol
name in their respective records and USRs. As a result the declaration
fragments for the anonymous TagType are those for the associated
typedef. This means that when the user is defining a typedef to a
typedef to a anonymous type, we use a reference the anonymous TagType
itself and do not emit the typedef to the anonymous type in the
generated symbol graph, including in the type destination of further
typedef symbol records.
Differential Revision: https://reviews.llvm.org/D123019
|
|
To achieve this we hook into the preprocessor during the
ExtractAPIAction and record definitions for macros that don't get
undefined during preprocessing.
|
|
Add support for Objective-C protocol declarations in ExtractAPI.
Depends on D122446
Differential Revision: https://reviews.llvm.org/D122511
|
|
Add support for Objective-C interface declarations in ExtractAPI.
Depends on D122495
Differential Revision: https://reviews.llvm.org/D122446
|
|
Add missing virtual method anchors for structs in ExtractAPI/API.h
|
|
Using a BumpPtrAllocator introduced memory leaks for APIRecords as they
contain a std::vector. This meant that we needed to always keep a
reference to the records in APISet and arrange for their destructor to
get called appropriately. This was further complicated by the need for
records to own sub-records as these subrecords would still need to be
allocated via the BumpPtrAllocator and the owning record would now need
to arrange for the destructor of its subrecords to be called
appropriately.
Since APIRecords contain a std::vector so whenever elements get added to
that there is an associated heap allocation regardless. Since
performance isn't currently our main priority it makes sense to use
regular unique_ptr to keep track of APIRecords, this way we don't need
to arrange for destructors to get called.
The BumpPtrAllocator is still used for strings such as USRs so that we
can easily de-duplicate them as necessary.
Differential Revision: https://reviews.llvm.org/D122331
|
|
- Add `StructFieldRecord` and `StructRecord` to store API information
for structs
- Implement `VisitRecordDecl` in `ExtractAPIVisitor`
- Implement Symbol Graph serialization for struct records.
- Add test case for struct records.
Depends on D121873
Differential Revision: https://reviews.llvm.org/D122202
|
|
Add support for enum records
- Add `EnumConstantRecord` and `EnumRecord` to store API information for
enums
- Implement `VisitEnumDecl` in `ExtractAPIVisitor`
- Implement serializatin for enum records and `MemberOf` relationship
- Add test case for enum records
- Few other improvements
Depends on D122160
Differential Revision: https://reviews.llvm.org/D121873
|
|
- The name SymbolGraph is inappropriate and confusing for the new library
for clang-extract-api. Refactor and rename things to make it clear that
ExtractAPI is the core functionality and SymbolGraph is one serializer
for the API information.
- Add documentation comments to ExtractAPI classes and methods to improve
readability and clearness of the ExtractAPI work.
Differential Revision: https://reviews.llvm.org/D122160
|
