summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [clang-ifs] Clang Interface Stubs, first version (second landing attempt).Puyan Lotfi2019-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+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
* [NFC] Undoing r363646 to fix bots.Puyan Lotfi2019-06-181-0/+1
| | | | | | | | -DBUILD_SHARED_LIBS=ON is still having problem caused by layering issues with D60974. Locally there weren't problems building with shared libs on or off but the bots appear to be acting up. llvm-svn: 363648
* [NFC] Fixing -DBUILD_SHARED_LIBS=ON problem caused by layering issue in D60974Puyan Lotfi2019-06-181-1/+0
| | | | llvm-svn: 363646
* [clang-ifs] Clang Interface Stubs, first version.Puyan Lotfi2019-06-171-0/+2
| | | | | | | | | | | | | | | | | | | 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
* Move PCHContainerOperations from Frontend to SerializationRichard Trieu2018-12-121-1/+0
| | | | | | | Fix a layering violation. Frontend depends on Serialization, so anything used by both should be in Serialization. llvm-svn: 348907
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+0
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* PTH-- Remove feature entirely-Erich Keane2018-12-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging a boost build with a modified version of Clang, I discovered that the PTH implementation stores TokenKind in 8 bits. However, we currently have 368 TokenKinds. The result is that the value gets truncated and the wrong token gets picked up when including PTH files. It seems that this will go wrong every time someone uses a token that uses the 9th bit. Upon asking on IRC, it was brought up that this was a highly experimental features that was considered a failure. I discovered via googling that BoostBuild (mostly Boost.Math) is the only user of this feature, using the CC1 flag directly. I believe that this can be transferred over to normal PCH with minimal effort: https://github.com/boostorg/build/issues/367 Based on advice on IRC and research showing that this is a nearly completely unused feature, this patch removes it entirely. Note: I considered leaving the build-flags in place and making them emit an error/warning, however since I've basically identified and warned the only user, it seemed better to just remove them. Differential Revision: https://reviews.llvm.org/D54547 Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9 llvm-svn: 348266
* Use special new Clang flag 'FrontendTimesIsEnabled' instead of ↵Andrew V. Tischenko2018-04-231-0/+1
| | | | | | | | 'llvm::TimePassesIsEnabled' inside -ftime-report feature. Differential Revision: https://reviews.llvm.org/D45619 llvm-svn: 330571
* Moved code hanlding precompiled preamble out of the ASTUnit.Ilya Biryukov2017-06-211-0/+1
| | | | | | | | | | | | Reviewers: bkramer, krasimir, arphaman, akyrtzi, klimek Reviewed By: klimek Subscribers: mgorny, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D34287 llvm-svn: 305890
* clangFrontend: Make intrinsics_gen optional for standalone build.NAKAMURA Takumi2016-06-021-1/+6
| | | | | FIXME: intrinsics_gen may be exported from llvm. llvm-svn: 271579
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-0/+1
| | | | | | | | | | | Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
* Basic: move CodeGenOptions from FrontendSaleem Abdulrasool2016-04-071-1/+0
| | | | | | | | This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. llvm-svn: 265702
* [PGO] Change profile use cc1 option to handle IR level profilesRong Xu2016-03-021-0/+1
| | | | | | | | | | | | | | | | | | This patch changes cc1 option for PGO profile use from -fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>. -fprofile-instr-use=<path> is now a driver only option. In addition to decouple the cc1 option from the driver level option, this patch also enables IR level profile use. cc1 option handling now reads the profile header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM} -- this is a common enum for -fprofile-instrument={}, for the profile instrumentation), and invoke the pipeline to enable the respective PGO use pass. Reviewers: silvas, davidxl Differential Revision: http://reviews.llvm.org/D17737 llvm-svn: 262515
* clangFrontend: [PR25565] Quick fix for dependencies on Attributes.inc.NAKAMURA Takumi2015-11-191-0/+1
| | | | | | | | FIXME: Attributes.inc may be an independent target. Differential Revision: http://reviews.llvm.org/D14760 llvm-svn: 253554
* Introduce module file extensions to piggy-back data onto module files.Douglas Gregor2015-11-031-0/+1
| | | | | | | | | | | | | | | | | | | | | Introduce the notion of a module file extension, which introduces additional information into a module file at the time it is built that can then be queried when the module file is read. Module file extensions are identified by a block name (which must be unique to the extension) and can write any bitstream records into their own extension block within the module file. When a module file is loaded, any extension blocks are matched up with module file extension readers, that are per-module-file and are given access to the input bitstream. Note that module file extensions can only be introduced by programmatic clients that have access to the CompilerInvocation. There is only one such extension at the moment, which is used for testing the module file extension harness. As a future direction, one could imagine allowing the plugin mechanism to introduce new module file extensions. llvm-svn: 251955
* Introduce a PCHContainerOperations interface (NFC).Adrian Prantl2015-06-201-0/+1
| | | | | | | | | | | | | | | | A PCHContainerOperations abstract interface provides operations for creating and unwrapping containers for serialized ASTs (precompiled headers and clang modules). The default implementation is RawPCHContainerOperations, which uses a flat file for the output. The main application for this interface will be an ObjectFilePCHContainerOperations implementation that uses LLVM to wrap the module in an ELF/Mach-O/COFF container to store debug info alongside the AST. rdar://problem/20091852 llvm-svn: 240225
* Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."Adrian Prantl2015-02-251-1/+0
| | | | llvm-svn: 230454
* Wrap clang module files in a Mach-O, ELF, or COFF container.Adrian Prantl2015-02-251-0/+1
| | | | | | | | | | | | | | | | | This is a necessary prerequisite for debugging with modules. The .pcm files become containers that hold the serialized AST which allows us to store debug information in the module file that can be shared by all object files that were built importing the module. This reapplies r230044 with a fixed configure+make build and updated dependencies and testcase requirements. Over the last iteration this version adds - missing target requirements for testcases that specify an x86 triple, - a missing clangCodeGen.a dependency to libClang.a in the make build. rdar://problem/19104245 llvm-svn: 230423
* Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."Adrian Prantl2015-02-241-1/+0
| | | | | | | This reverts commit r230305. Off to fix another round of missing dependencies on various platforms. llvm-svn: 230309
* Wrap clang module files in a Mach-O, ELF, or COFF container.Adrian Prantl2015-02-241-0/+1
| | | | | | | | | | | | | | This is a necessary prerequisite for debugging with modules. The .pcm files become containers that hold the serialized AST which allows us to store debug information in the module file that can be shared by all object files that were built importing the module. rdar://problem/19104245 This reapplies r230044 with a fixed configure+make build and updated dependencies. Take 3. llvm-svn: 230305
* Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."Adrian Prantl2015-02-211-1/+0
| | | | | | | | This reverts commit 230099. The Linux configure+make build variant still needs some work. llvm-svn: 230103
* Wrap clang module files in a Mach-O, ELF, or COFF container.Adrian Prantl2015-02-201-0/+1
| | | | | | | | | | | | | | This is a necessary prerequisite for debugging with modules. The .pcm files become containers that hold the serialized AST which allows us to store debug information in the module file that can be shared by all object files that were built importing the module. rdar://problem/19104245 This reapplies r230044 with a fixed configure+make build and updated dependencies. Take 2. llvm-svn: 230089
* Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."Adrian Prantl2015-02-201-1/+0
| | | | | | | | This reverts commit r230067. Investigating another batch of problems found by the bots. llvm-svn: 230073
* Wrap clang module files in a Mach-O, ELF, or COFF container.Adrian Prantl2015-02-201-0/+1
| | | | | | | | | | | | | | This is a necessary prerequisite for debugging with modules. The .pcm files become containers that hold the serialized AST which allows us to store debug information in the module file that can be shared by all object files that were built importing the module. rdar://problem/19104245 This reapplies r230044 with a fixed configure+make build and updated dependencies. llvm-svn: 230067
* Revert "Wrap clang module files in a Mach-O, ELF, or COFF container."Adrian Prantl2015-02-201-1/+0
| | | | | | | | | This reverts commit r230044 while dealing with buildbot breakage. Conflicts: test/Modules/module_container.m llvm-svn: 230052
* Wrap clang module files in a Mach-O, ELF, or COFF container.Adrian Prantl2015-02-201-0/+1
| | | | | | | | | | | This is a necessary prerequisite for debugging with modules. The .pcm files become containers that hold the serialized AST which allows us to store debug information in the module file that can be shared by all object files that were built importing the module. rdar://problem/19104245 llvm-svn: 230044
* Move CodeGenOptions constructor out-of-line and add missing headers. NFC.Alexey Samsonov2014-11-111-0/+1
| | | | llvm-svn: 221646
* Re-apply "Frontend: Extract SerializedDiagnosticReader out of ↵Justin Bogner2014-10-141-0/+2
| | | | | | | | | | | | CXLoadedDiagnostic (NFC)" I'd mispelled "Bitcode/BitCodes.h" before, and tested on a case insensitive filesystem. This reverts commit r219649, effectively re-applying r219647 and r219648. llvm-svn: 219664
* Revert "Frontend: Extract SerializedDiagnosticReader out of ↵Justin Bogner2014-10-141-2/+0
| | | | | | | | | | | CXLoadedDiagnostic (NFC)" The bots can't seem to find an include file. Reverting for now and I'll look into it in a bit. This reverts commits r219647 and r219648. llvm-svn: 219649
* Frontend: Try to fix cmake builders after r219647Justin Bogner2014-10-141-0/+1
| | | | | | Looks like I missed a dependency here. llvm-svn: 219648
* Frontend: Extract SerializedDiagnosticReader out of CXLoadedDiagnostic (NFC)Justin Bogner2014-10-141-0/+1
| | | | | | | | | We currently read serialized diagnostics directly in the C API, which makes it difficult to reuse this logic elsewhere. This extracts the core of the serialized diagnostic parsing logic into a base class that can be subclassed using a visitor pattern. llvm-svn: 219647
* Make clang's rewrite engine a core featureAlp Toker2014-07-161-0/+2
| | | | | | | | | | | | | | | The rewrite facility's footprint is small so it's not worth going to these lengths to support disabling at configure time, particularly since key compiler features now depend on it. Meanwhile the Objective-C rewriters have been moved under the ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still potentially worth excluding from lightweight builds. Tests are now passing with any combination of feature flags. The flags historically haven't been tested by LLVM's build servers so caveat emptor. llvm-svn: 213171
* Frontend: Add a CC1 flag to dump module dependencies to a directoryJustin Bogner2014-06-191-0/+1
| | | | | | | | | | | | | | | | | | This adds the -module-dependency-dir to clang -cc1, which specifies a directory to copy all of a module's dependencies into in a form suitable to be used as a VFS using -ivfsoverlay with the generated vfs.yaml. This is useful for crashdumps that involve modules, so that the module dependencies will be intact when a crash report script is used to reproduce a problem on another machine. We currently encode the absolute path to the dump directory, due to limitations in the VFS system. Until we can handle relative paths in the VFS, users of the VFS map may need to run a simple search and replace in the file. llvm-svn: 211303
* Reapply r207477 and r207479 without cyclic dependencyBen Langmuir2014-04-291-1/+0
| | | | | | | | Fixed by moving ProcessWarningOptions from Frontend into Basic. All of the dependencies for ProcessWarningOptions were already in Basic, so this was a small change. llvm-svn: 207549
* [CMake] Use LINK_LIBS instead of target_link_libraries().NAKAMURA Takumi2014-02-261-2/+1
| | | | llvm-svn: 202238
* [CMake] Resurrect mis-dropped dependency to ClangDriverOptions since r201842.NAKAMURA Takumi2014-02-231-0/+3
| | | | llvm-svn: 201978
* [CMake] Get rid of explicit dependencies to include/clang/*.inc and ↵NAKAMURA Takumi2014-02-211-16/+0
| | | | | | | | | | | | | | | | | | | introduce CLANG_TABLEGEN_TARGETS. This does; - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list. - List of targets is added to LLVM_COMMON_DEPENDS. - all clang libraries and targets depend on generated headers. You might wonder this would be regression, but in fact, this is little loss. - Almost all of clang libraries depend on tblgen'd files and clang-tblgen. - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild. - Each library's dependencies to tblgen'd files might vary along headers' structure. It made hard to track and update *really optimal* dependencies. Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS. llvm-svn: 201842
* [CMake] clang/lib: Satisfy dependencies to add *actually used* libraries on ↵NAKAMURA Takumi2013-12-091-0/+5
| | | | | | | | target_link_libraries() and LLVM_LINK_COMPONENTS. I will prune redundant dependencies later. llvm-svn: 196800
* clang/lib: [CMake] Update tblgen'd dependencies.NAKAMURA Takumi2012-07-271-0/+4
| | | | llvm-svn: 160851
* clang/lib: [CMake] Reformat, alphabetize lists.NAKAMURA Takumi2012-07-271-2/+2
| | | | llvm-svn: 160850
* Implement AST classes for comments, a real parser for Doxygen comments and aDmitri Gribenko2012-07-061-0/+1
| | | | | | | | | | | | | | very simple semantic analysis that just builds the AST; minor changes for lexer to pick up source locations I didn't think about before. Comments AST is modelled along the ideas of HTML AST: block and inline content. * Block content is a paragraph or a command that has a paragraph as an argument or verbatim command. * Inline content is placed within some block. Inline content includes plain text, inline commands and HTML as tag soup. llvm-svn: 159790
* Remove a goofy CMake hack and use the standard CMake facilities toChandler Carruth2012-06-211-13/+13
| | | | | | | | | express library-level dependencies within Clang. This is no more verbose really, and plays nicer with the rest of the CMake facilities. It should also have no change in functionality. llvm-svn: 158888
* Zap the /Za compiler switch from MSVC projects, the option is considered ↵Francois Pichet2012-06-061-7/+0
| | | | | | | | harmful even by Microsoft people and clang won't build using the MSVC 2012 RC if not removed. Only 1 minor code change was necessary: can't use cdecl as variable name anymore. llvm-svn: 158063
* Fix cmake. Remaining two ClangCC1Options deps.Andrew Trick2012-05-021-3/+2
| | | | llvm-svn: 155977
* CMake: Fix build to add clangEdit to USED_LIBS.NAKAMURA Takumi2012-03-061-0/+1
| | | | llvm-svn: 152154
* Introduce a -cc1 option "-dependency-graphviz" that determines headerDouglas Gregor2012-02-021-0/+1
| | | | | | dependencies and outputs them in GraphViz format. llvm-svn: 149575
* Extend the ExternalASTSource interface to allow the AST source toDouglas Gregor2012-01-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | provide the layout of records, rather than letting Clang compute the layout itself. LLDB provides the motivation for this feature: because various layout-altering attributes (packed, aligned, etc.) don't get reliably get placed into DWARF, the record layouts computed by LLDB from the reconstructed records differ from the actual layouts, and badness occurs. This interface lets the DWARF data drive layout, so we don't need the attributes preserved to get the answer write. The testing methodology for this change is fun. I've introduced a variant of -fdump-record-layouts called -fdump-record-layouts-simple that always has the simple C format and provides size/alignment/field offsets. There is also a -cc1 option -foverride-record-layout=<file> to take the output of -fdump-record-layouts-simple and parse it to produce a set of overridden layouts, which is introduced into the AST via a testing-only ExternalASTSource (called LayoutOverrideSource). Each test contains a number of records to lay out, which use various layout-changing attributes, and then dumps the layouts. We then run the test again, using the preprocessor to eliminate the layout-changing attributes entirely (which would give us different layouts for the records), but supplying the previously-computed record layouts. Finally, we diff the layouts produced from the two runs to be sure that they are identical. Note that this code makes the assumption that we don't *have* to provide the offsets of bases or virtual bases to get the layout right, because the alignment attributes don't affect it. I believe this assumption holds, but if it does not, we can extend LayoutOverrideSource to also provide base offset information. Fixes the Clang side of <rdar://problem/10169539>. llvm-svn: 149055
* Update the CMake build for r146959's new files.Chandler Carruth2011-12-201-0/+1
| | | | llvm-svn: 146967
* Refactor 'TextDiagnostic' to have a parent class 'DiagnosticRenderer' which ↵Ted Kremenek2011-12-171-0/+1
| | | | | | | | | | | | handles the policy of how diagnostics are lowered/rendered, while TextDiagnostic handles the actual pretty-printing. This is a first part of reworking SerializedDiagnosticPrinter to use the same inclusion-stack/macro-expansion logic as TextDiagnostic. llvm-svn: 146819
OpenPOWER on IntegriCloud