summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [clang][IFS] Prevent Clang-IFS from Leaking symbols from inside a block.Puyan Lotfi2020-01-131-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
* [NFC][clang][IFS] Adding braces to if-statement as prep for D71301.Puyan Lotfi2020-01-131-1/+2
| | | | Just trying to make https://reviews.llvm.org/D71301 look cleaner.
* [clang][IFS] Adding support for new clang interface stubs decl types.Puyan Lotfi2019-12-041-0/+4
| | | | | | | NamespaceAliasDecl UnresolvedUsingTypenameDecl CXXDeductionGuideDecl ConstructorUsingShadowDecl Differential Revision: https://reviews.llvm.org/D70728
* [clang][IFS] Adds support for more decl types in clang interface stubs.Puyan Lotfi2019-11-081-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
* [clang][IFS] Escape mangled names so MS ABI doesn't break YAML parsing.Puyan Lotfi2019-10-141-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
* [clang][IFS] Fixing spelling errors in interface-stubs OPT flag (NFC).Puyan Lotfi2019-10-121-1/+1
| | | | | | This is just a long standing spelling error that was found recently. llvm-svn: 374638
* [clang][IFS] Fixing assert in clang interface stubs for enums, records, typedefsPuyan Lotfi2019-10-111-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
* Do a sweep of symbol internalization. NFC.Benjamin Kramer2019-08-231-0/+2
| | | | llvm-svn: 369803
* [clang][ifs] Dropping older experimental interface stub formats.Puyan Lotfi2019-08-221-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
* [clang][ifs] New interface stubs format (llvm triple based).Puyan Lotfi2019-08-221-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
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-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
* [clang-ifs] Clang Interface Stubs, first version (second landing attempt).Puyan Lotfi2019-06-201-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
* Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."Fangrui Song2019-06-181-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
* [clang-ifs] Clang Interface Stubs, first version.Puyan Lotfi2019-06-171-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
OpenPOWER on IntegriCloud