aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-07-19[ifs] Prepare llvm-ifs for elfabi/ifs merging.Haowei Wu1-8/+4
This diff changes llvm-ifs to use unified IFS file format and perform other renaming changes in preparation for the merging between elfabi/ifs. Differential Revision: https://reviews.llvm.org/D99810
2021-01-04Revert "[NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped ↵Thorsten Schütt1-3/+3
enum (II)" This reverts commit efc82c4ad2bcb256a4f4c20238d08cd3afba4d2d.
2021-01-04[NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped enum (II)Thorsten Schütt1-3/+3
Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93765
2020-04-01[llvm][clang][IFS] Enhancing the llvm-ifs yaml format for symbol lists.Puyan Lotfi1-7/+7
Prior to this change the clang interface stubs format resembled something ending with a symbol list like this: Symbols: a: { Type: Func } This was problematic because we didn't actually want a map format and also because we didn't like that an empty symbol list required "Symbols: {}". That is to say without the empty {} llvm-ifs would crash on an empty list. With this new format it is much more clear which field is the symbol name, and instead the [] that is used to express an empty symbol vector is optional, ie: Symbols: - { Name: a, Type: Func } or Symbols: [] or Symbols: This further diverges the format from existing llvm-elftapi. This is a good thing because although the format originally came from the same place, they are not the same in any way. Differential Revision: https://reviews.llvm.org/D76979
2020-03-11Prune TargetInfo.h include from ParsedAttr.h, NFCReid Kleckner1-0/+1
Saves ~400 includes of related headers: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 468 - llvm-project/clang/include/clang/Basic/TargetInfo.h 468 - llvm-project/clang/include/clang/Basic/TargetCXXABI.h 368 - llvm-project/llvm/include/llvm/Support/CodeGen.h 368 - llvm-project/clang/include/clang/Basic/XRayInstr.h 368 - llvm-project/clang/include/clang/Basic/CodeGenOptions.h 368 - llvm-project/clang/include/clang/Basic/CodeGenOptions.def 367 - llvm-project/llvm/include/llvm/ADT/FloatingPointMode.h 367 - llvm-project/clang/include/clang/Basic/DebugInfoOptions.h
2020-01-13[clang][IFS] Prevent Clang-IFS from Leaking symbols from inside a block.Puyan Lotfi1-0/+4
Built libdispatch with clang interface stubs. Ran into some block related issues. Basically VarDecl symbols can leak out because I wasn't checking the case where a VarDecl is contained inside a BlockDecl (versus a method or function). This patch checks that a VarDecl is not a child decl of a BlockDecl. This patch also does something very similar for c++ lambdas as well. Differential Revision: https://reviews.llvm.org/D71301
2020-01-13[NFC][clang][IFS] Adding braces to if-statement as prep for D71301.Puyan Lotfi1-1/+2
Just trying to make https://reviews.llvm.org/D71301 look cleaner.
2019-12-04[clang][IFS] Adding support for new clang interface stubs decl types.Puyan Lotfi1-0/+4
NamespaceAliasDecl UnresolvedUsingTypenameDecl CXXDeductionGuideDecl ConstructorUsingShadowDecl Differential Revision: https://reviews.llvm.org/D70728
2019-11-08[clang][IFS] Adds support for more decl types in clang interface stubs.Puyan Lotfi1-6/+32
Adding support for processing the following Decls: NonTypeTemplateParmDecl, CXXConversionDecl, UnresolvedUsingValueDecl, UsingDecl, UsingShadowDecl, TypeAliasTemplateDecl, TypeAliasDecl, VarTemplateDecl, VarTemplateSpecializationDecl, UsingDirectiveDecl, TemplateTemplateParmDecl, ClassTemplatePartialSpecializationDecl, IndirectFieldDecl. Also, this allows for processing NamedDecls that don't have an identifier and skips over VarDecls that are dependent on template types. Differential Revision: https://reviews.llvm.org/D69995
2019-10-14[clang][IFS] Escape mangled names so MS ABI doesn't break YAML parsing.Puyan Lotfi1-2/+2
Microsoft's ABI mangles names differently than Itanium and this breaks the LLVM yaml parser unless the name is escaped in quotes. Quotes are being added to the mangled names of the IFS file generation so that llvm-ifs doesn't break when Windows triples are passed to the driver. Differential Revision: https://reviews.llvm.org/D68915 llvm-svn: 374798
2019-10-12[clang][IFS] Fixing spelling errors in interface-stubs OPT flag (NFC).Puyan Lotfi1-1/+1
This is just a long standing spelling error that was found recently. llvm-svn: 374638
2019-10-11[clang][IFS] Fixing assert in clang interface stubs for enums, records, typedefsPuyan Lotfi1-0/+4
The clang IFS ASTConsumer was asserting on enums, records (struct definitions in C), and typedefs. All it needs to do is skip them because the stub just needs to expose global object instances and functions. Differential Revision: https://reviews.llvm.org/D68859 llvm-svn: 374573
2019-08-23Do a sweep of symbol internalization. NFC.Benjamin Kramer1-0/+2
llvm-svn: 369803
2019-08-22[clang][ifs] Dropping older experimental interface stub formats.Puyan Lotfi1-131/+2
I've been working on a new tool, llvm-ifs, for merging interface stub files generated by clang and I've iterated on my derivative format of TBE to a newer format. llvm-ifs will only support the new format, so I am going to drop the older experimental interface stubs formats in this commit to make things simpler. Differential Revision: https://reviews.llvm.org/D66573 llvm-svn: 369719
2019-08-22[clang][ifs] New interface stubs format (llvm triple based).Puyan Lotfi1-0/+53
After posting llvm-ifs on phabricator, I made some progress in hardening up how I think the format for Interface Stubs should look. There are a number of things I think the TBE format was missing (no endianness, no info about the Object Format because it assumes ELF), so I have added those and broken off from being as similar to the TBE schema. In a subsequent commit I can drop the other formats. An example of how The format will look is as follows: --- !experimental-ifs-v1 IfsVersion: 1.0 Triple: x86_64-unknown-linux-gnu ObjectFileFormat: ELF Symbols: _Z9nothiddenv: { Type: Func } _Z10cmdVisiblev: { Type: Func } ... The format is still marked experimental. Differential Revision: https://reviews.llvm.org/D66446 llvm-svn: 369715
2019-08-14[Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-2/+2
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
2019-06-20[clang-ifs] Clang Interface Stubs, first version (second landing attempt).Puyan Lotfi1-0/+378
This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-18Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."Fangrui Song1-379/+0
This reverts commit rC363626. clangIndex depends on clangFrontend. r363626 adds a dependency from clangFrontend to clangIndex, which creates a circular dependency. This is disallowed by -DBUILD_SHARED_LIBS=on builds: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "clangFrontend" of type SHARED_LIBRARY depends on "clangIndex" (weak) "clangIndex" of type SHARED_LIBRARY depends on "clangFrontend" (weak) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. Note, the dependency on clangIndex cannot be removed because libclangFrontend.so is linked with -Wl,-z,defs: a shared object must have its full direct dependencies specified on the linker command line. In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking `bin/clang-9`. However, it can cause trouble to downstream clang library users. The llvm build system links libraries this way: clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe libclangIndex.a etc are not wrapped in --start-group. If the downstream application depends on libclangFrontend.a but not any other clang libraries that depend on libclangIndex.a, this can cause undefined reference errors when the linker is ld.bfd or gold. The proper fix is to not include clangIndex files in clangFrontend. llvm-svn: 363649
2019-06-17[clang-ifs] Clang Interface Stubs, first version.Puyan Lotfi1-0/+379
Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363626
generated by cgit v1.1 at 2025-10-04 16:54:36 +0000