summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well.Nico Weber2020-06-231-2/+2
| | | | | | | | | | | | | | | | | | When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no longer embedded into binaries (mostly for --version output). Without it, most binaries need to relink after every single commit, even if they didn't change otherwise (due to, say, a documentation-only commit). LLVM_APPEND_VC_REV is ON by default, so this doesn't change the default behavior of anything. With this, all clients of GenerateVersionFromVCS.cmake honor LLVM_APPEND_VC_REV. Differential Revision: https://reviews.llvm.org/D72855 (cherry picked from commit fb5fafb23cc2d8613f8be2487afe94d8594a88ce)
* [NFC] Move OptionUtils from Basic to DriverYaxun (Sam) Liu2019-12-231-2/+0
| | | | Differential Revision: https://reviews.llvm.org/D71802
* [NFC] Separate getLastArgIntValue to BasicYaxun (Sam) Liu2019-12-211-0/+2
| | | | | | | | getLastArgIntValue is a useful utility function to get command line argument as an integer. Currently it is in Frontend so that it can only be used by clang -cc1. Move it to basic so that it can also be used by clang driver. Differential Revision: https://reviews.llvm.org/D71080
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
* Move LangStandard*, InputKind::Language to BasicRainer Orth2019-08-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is a prerequisite for using LangStandard from Driver in https://reviews.llvm.org/D64793. It moves LangStandard* and InputKind::Language to Basic. It is mostly mechanical, with only a few changes of note: - enum Language has been changed into enum class Language : uint8_t to avoid a clash between OpenCL in enum Language and OpenCL in enum LangFeatures and not to increase the size of class InputKind. - Now that getLangStandardForName, which is currently unused, also checks both canonical and alias names, I've introduced a helper getLangKind which factors out a code pattern already used 3 times. The patch has been tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. There's a companion patch for lldb which uses LangStandard.h (https://reviews.llvm.org/D65717). While polly includes isl which in turn uses InputKind::C, that part of the code isn't even built inside the llvm tree. I've posted a patch to allow for both InputKind::C and Language::C upstream (https://groups.google.com/forum/#!topic/isl-development/6oEvNWOSQFE). Differential Revision: https://reviews.llvm.org/D65562 llvm-svn: 367864
* Modules: Rename MemoryBufferCache to InMemoryModuleCacheDuncan P. N. Exon Smith2019-03-091-1/+0
| | | | | | | | | | | | | Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-02-061-32/+24
| | | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang and lldb. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM, Clang and lldb, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 353268
* Revert "[CMake] Unify scripts for generating VCS headers"Petr Hosek2019-01-311-22/+33
| | | | | | This reverts commits r352729 and r352731: this broke Sanitizer Windows bots llvm-svn: 352733
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-01-311-33/+22
| | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM and Clang, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 352729
* [Nios2] Remove Nios2 backendCraig Topper2019-01-151-1/+0
| | | | | | | | As mentioned here http://lists.llvm.org/pipermail/llvm-dev/2019-January/129121.html This backend is incomplete and has not been maintained in several months. Differential Revision: https://reviews.llvm.org/D56690 llvm-svn: 351230
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-0/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* [clang][ARC] Add ARCTargetInfoTatyana Krasnukha2018-11-271-0/+1
| | | | | | | | Based-on-patch-by: Pete Couperus <petecoup@synopsys.com> Differential Revision: https://reviews.llvm.org/D53100 llvm-svn: 347699
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-1/+0
| | | | | | | | | | | | | | | | | | | This patch moves the virtual file system form clang to llvm so it can be used by more projects. Concretely the patch: - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support. - Moves the corresponding unit test from clang to llvm. - Moves the vfs namespace from clang::vfs to llvm::vfs. - Formats the lines affected by this change, mostly this is the result of the added llvm namespace. RFC on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html Differential revision: https://reviews.llvm.org/D52783 llvm-svn: 344140
* [Fixed Point Arithmetic] Fixed Point ConstantLeonard Chan2018-08-061-0/+1
| | | | | | | | | | This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values. Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum. Differential Revision: https://reviews.llvm.org/D48661 llvm-svn: 339028
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* [XRay][clang] Add flag to choose instrumentation bundlesDean Michael Berris2018-04-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change addresses http://llvm.org/PR36926 by allowing users to pick which instrumentation bundles to use, when instrumenting with XRay. In particular, the flag `-fxray-instrumentation-bundle=` has four valid values: - `all`: the default, emits all instrumentation kinds - `none`: equivalent to -fnoxray-instrument - `function`: emits the entry/exit instrumentation - `custom`: emits the custom event instrumentation These can be combined either as comma-separated values, or as repeated flag values. Reviewers: echristo, kpw, eizan, pelikan Reviewed By: pelikan Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D44970 llvm-svn: 329985
* [RISCV] Add the RISCV target and compiler driverAlex Bradbury2018-01-111-0/+1
| | | | | | | | | As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* [Basic] Update CMakeLists.txt to handle repoMinSeong Kim2017-09-091-33/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: The find_first_existing_file and find_first_existing_vc_file macros in lib/Basic/CMakeLists.txt are removed. The macros are also defined in {LLVM}/cmake/modules/AddLLVM.cmake for the same purpose. This change serves the following 2 objectives: 1. To remove the redundant code in clang to use the same macros in llvm, 2. The macros in AddLLVM.cmake can also handle repo for displaying correct version information. Reviewers: jordan_rose, cfe-commits, modocache, hintonda Reviewed By: hintonda Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D35533 llvm-svn: 312865
* Break up Targets.cpp into a header/impl pair per target type[NFCI]Erich Keane2017-07-211-0/+22
| | | | | | | | | | | | | | | | Targets.cpp is getting unwieldy, and even minor changes cause the entire thing to cause recompilation for everyone. This patch bites the bullet and breaks it up into a number of files. I tended to keep function definitions in the class declaration unless it caused additional includes to be necessary. In those cases, I pulled it over into the .cpp file. Content is copy/paste for the most part, besides includes/format/etc. Differential Revision: https://reviews.llvm.org/D35701 llvm-svn: 308791
* [Basic] Detect Git submodule version in CMakeBrian Gesiak2017-07-171-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When searching for Git version control information, libBasic's CMake checks for the path '.git/logs/HEAD'. However, when LLVM is included as a Git submodule, this path does not exist. Instead, it contains a '.git' file with the following: ``` gitdir: ../../.git/modules/external/llvm ``` Where '../..' is the relative path to the root repository that contains the LLVM Git submodule. Because of this discrepancy, `clang --version` does not output source control information if built from a Git submodule. To fix, check whether '.git' is a directory or a file. If it's a directory, simply use the '.git/logs/HEAD' path. If it's a file, read it and check for the tell-tale sign of a Git submodule: the text "gitdir:". If it exists, follow that path and use the 'logs/HEAD' at that location instead. This allows not only the correct revision information to be retrieved, but also uses a file that will change with each source control revision. Test Plan: 1. Before applying this change, build Clang as a Git submodule in a repository that places it in external/clang, and confirm no revision information is output when `clang --version` is invoked (just "clang 5.0.0" is output, no Git hashes). 2. Apply these changes and build Clang as a Git repository nested under llvm/tools/clang, and confirm that `clang --version` displays correct version information. 3. Apply these changes and build Clang as a Git submodule using the structure described in (1), and confirm version control information is output as in (2). Reviewers: jordan_rose, beanz, probinson Reviewed By: jordan_rose Subscribers: chapuni, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D34955 llvm-svn: 308205
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
* Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"Duncan P. N. Exon Smith2017-03-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r298185, effectively reapplying r298165, after fixing the new unit tests (PR32338). The memory buffer generator doesn't null-terminate the MemoryBuffer it creates; this version of the commit informs getMemBuffer about that to avoid the assert. Original commit message follows: ---- Clang's internal build system for implicit modules uses lock files to ensure that after a process writes a PCM it will read the same one back in (without contention from other -cc1 commands). Since PCMs are read from disk repeatedly while invalidating, building, and importing, the lock is not released quickly. Furthermore, the LockFileManager is not robust in every environment. Other -cc1 commands can stall until timeout (after about eight minutes). This commit changes the lock file from being necessary for correctness to a (possibly dubious) performance hack. The remaining benefit is to reduce duplicate work in competing -cc1 commands which depend on the same module. Follow-up commits will change the internal build system to continue after a timeout, and reduce the timeout. Perhaps we should reconsider blocking at all. This also fixes a use-after-free, when one part of a compilation validates a PCM and starts using it, and another tries to swap out the PCM for something new. The PCMCache is a new type called MemoryBufferCache, which saves memory buffers based on their filename. Its ownership is shared by the CompilerInstance and ModuleManager. - The ModuleManager stores PCMs there that it loads from disk, never touching the disk if the cache is hot. - When modules fail to validate, they're removed from the cache. - When a CompilerInstance is spawned to build a new module, each already-loaded PCM is assumed to be valid, and is frozen to avoid the use-after-free. - Any newly-built module is written directly to the cache to avoid the round-trip to the filesystem, making lock files unnecessary for correctness. Original patch by Manman Ren; most testcases by Adrian Prantl! llvm-svn: 298278
* Revert "Modules: Cache PCMs in memory and avoid a use-after-free"Renato Golin2017-03-181-1/+0
| | | | | | This reverts commit r298165, as it broke the ARM builds. llvm-svn: 298185
* Modules: Cache PCMs in memory and avoid a use-after-freeDuncan P. N. Exon Smith2017-03-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang's internal build system for implicit modules uses lock files to ensure that after a process writes a PCM it will read the same one back in (without contention from other -cc1 commands). Since PCMs are read from disk repeatedly while invalidating, building, and importing, the lock is not released quickly. Furthermore, the LockFileManager is not robust in every environment. Other -cc1 commands can stall until timeout (after about eight minutes). This commit changes the lock file from being necessary for correctness to a (possibly dubious) performance hack. The remaining benefit is to reduce duplicate work in competing -cc1 commands which depend on the same module. Follow-up commits will change the internal build system to continue after a timeout, and reduce the timeout. Perhaps we should reconsider blocking at all. This also fixes a use-after-free, when one part of a compilation validates a PCM and starts using it, and another tries to swap out the PCM for something new. The PCMCache is a new type called MemoryBufferCache, which saves memory buffers based on their filename. Its ownership is shared by the CompilerInstance and ModuleManager. - The ModuleManager stores PCMs there that it loads from disk, never touching the disk if the cache is hot. - When modules fail to validate, they're removed from the cache. - When a CompilerInstance is spawned to build a new module, each already-loaded PCM is assumed to be valid, and is frozen to avoid the use-after-free. - Any newly-built module is written directly to the cache to avoid the round-trip to the filesystem, making lock files unnecessary for correctness. Original patch by Manman Ren; most testcases by Adrian Prantl! llvm-svn: 298165
* [cmake] Use LLVM_CMAKE_PATH for GetSVN scriptMichal Gorny2016-10-191-1/+1
| | | | | | | | Use the LLVM_CMAKE_PATH variable to locate the GetSVN.cmake script. The variable was already available in stand-alone builds, and is also set by LLVM since r284581. llvm-svn: 284582
* [CUDA] Add utility functions for dealing with CUDA versions / architectures.Justin Lebar2016-07-061-0/+1
| | | | | | | | | | | | | | | | | | Summary: Currently our handling of CUDA architectures is scattered all around clang. This patch centralizes it. A key advantage of this centralization is that you can now write a C++ switch on e.g. CudaArch and get a compile error if you don't handle one of the enum values. Reviewers: tra Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D21867 llvm-svn: 274681
* [CMake] Remove CLANG_APPEND_VC_REV optionChris Bieneman2016-06-241-0/+7
| | | | | | | | | | | | I added this option in r257827 to try and add compatibility with autoconf. At the time I misunderstood the problem. Our CMake automatically generates the SVN revision information and generates a build action to update it so builds don't need to be re-configured on SCM update (which is a better solution than we had in autoconf). The problem I was actually seeing was isolated cases where SVN revision information isn't available because the repository structures have been removed. This happens in some automated testing systems. This patch allows SVN_REVISION to be overridden if the build configuration could not find the SCM repository structures, and removes the code from my original patch because it is unnecessary. llvm-svn: 273714
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-1/+0
| | | | | | | | | | | 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-0/+1
| | | | | | | | 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
* Add `-verify-ignore-unexpected` option to ignore unexpected diagnostics in ↵Eric Fiselier2015-06-131-0/+1
| | | | | | | | | | | | | | | | | | | | | VerifyDiagnosticsConsumer Summary: The goal of this patch is to make `-verify` easier to use when testing libc++. The `notes` attached to compile error diagnostics are numerous and relatively unstable when they reference libc++ header internals. This patch allows libc++ to write stable compilation failure tests by allowing unexpected diagnostic messages to be ignored where they are not relevant. This patch adds a new CC1 flag called `-verify-ignore-unexpected`. `-verify-ignore-unexpected` tells `VerifyDiagnosticsConsumer` to ignore *all* unexpected diagnostic messages. `-verify-ignore-unexpected=<LevelList>` can be used to only ignore certain diagnostic levels. `<LevelList>` is a comma separated list of diagnostic levels to ignore. The supported levels are `note`, `remark`, `warning` and `error`. Reviewers: bogner, grosser, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10138 llvm-svn: 239665
* Revert r223578, perf data collection depends on the old symbol name.Paul Robinson2014-12-101-1/+1
| | | | llvm-svn: 223987
* cmake: Make SVNVersion.inc step depend on GetSVN.cmake.Nico Weber2014-12-101-2/+4
| | | | | | | | This way, the step generating SVNVersion.inc gets rerun every time someone changes GetSVN.cmake (which is the file that decides how the contents of SVNVersion.inc look). This makes hacking on GetSVN.cmake a bit easier. llvm-svn: 223861
* Rename a couple of preprocessor symbols to be more descriptive. NFC.Paul Robinson2014-12-061-1/+1
| | | | | | Review feedback from recent changes to GetSVN.cmake. llvm-svn: 223578
* Specify the name of the generated header only once. NFC.Paul Robinson2014-12-051-4/+7
| | | | | | This will also simplify a private patch that we have. llvm-svn: 223537
* [CMake] Use .svn/wc.db as our VC dependency if it's available.Jordan Rose2014-11-201-6/+10
| | | | | | | | | | | In order to keep SVNVersion.inc from being regenerated on every build, we need to specify as a dependency a file that only changes when the VC state updates. I previously just had .svn/entries, but that's only used by Subversion 1.6. 1.7 uses .svn/wc.db instead; prefer that if it's present. (Thanks, Nico!) llvm-svn: 222407
* [CMake] Always include the Clang repo version, just like the autoconf build.Jordan Rose2014-11-191-25/+43
| | | | | | | | | | | | | | Now that LLVM's helper script GetSVN.cmake actually works consistently, there's no reason not to use it. We avoid having to regenerate SVNVersion.inc every time by marking it as dependent on Git's reflog or SVN's entries file. This should end most of the issues of the AST format changing and breaking old module files: CMake-Clang should now detect that the version changed just like Autoconf-Clang has. Based on r190557. Depends on LLVM r222391. llvm-svn: 222393
* [Sanitizer] Refactor sanitizer options in LangOptions.Alexey Samsonov2014-11-111-0/+1
| | | | | | | | | | | | | | | | | | Get rid of ugly SanitizerOptions class thrust into LangOptions: * Make SanitizeAddressFieldPadding a regular language option, and rely on default behavior to initialize/reset it. * Make SanitizerBlacklistFile a regular member LangOptions. * Introduce the helper class "SanitizerSet" to represent the set of enabled sanitizers and make it a member of LangOptions. It is exactly the entity we want to cache and modify in CodeGenFunction, for instance. We'd also be able to reuse SanitizerSet in CodeGenOptions for storing the set of recoverable sanitizers, and in the Driver to represent the set of sanitizers turned on/off by the commandline flags. No functionality change. llvm-svn: 221653
* [CMake] clangBasic: Add Core to LINK_COMPONENTS introduced by r219840.NAKAMURA Takumi2014-10-161-0/+1
| | | | llvm-svn: 219880
* Move SanitizerBlacklist to clangBasic. NFC.Alexey Samsonov2014-10-151-0/+1
| | | | | | | | | | | | This change moves SanitizerBlacklist.h from lib/CodeGen to public Clang headers in include/clang/Basic. SanitizerBlacklist is currently only used in CodeGen to decide which functions/modules should be instrumented, but this will soon change as ASan will optionally modify class layouts during AST construction (http://reviews.llvm.org/D5687). We need blacklist machinery to be available at this point. llvm-svn: 219840
* Reapply r207477 and r207479 without cyclic dependencyBen Langmuir2014-04-291-0/+1
| | | | | | | | 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
* Reapplying r204952 a second time.Aaron Ballman2014-03-311-0/+1
| | | | | | | | | | Clean up the __has_attribute implementation without modifying its behavior. Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes). Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options. llvm-svn: 205181
* Reverting r204968 and r204969; while more build bots are happy with the ↵Aaron Ballman2014-03-271-1/+0
| | | | | | results, some still have link errors. llvm-svn: 204974
* Reapplying r204952 with fixes which should hopefully resolve linking issues ↵Aaron Ballman2014-03-271-0/+1
| | | | | | with non-MSVC compilers. llvm-svn: 204968
* Reverting r204952, while I figure out what's going on with the makefile build.Aaron Ballman2014-03-271-1/+0
| | | | llvm-svn: 204955
* Clean up the __has_attribute implementation without modifying its behavior. Aaron Ballman2014-03-271-0/+1
| | | | | | | | Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes). Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options. llvm-svn: 204952
* [CMake] Get rid of explicit dependencies to include/clang/*.inc and ↵NAKAMURA Takumi2014-02-211-17/+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
* Recommit virtual file systemBen Langmuir2014-02-201-0/+1
| | | | | | | | | | | Previously reverted in r201755 due to causing an assertion failure. I've removed the offending assertion, and taught the CompilerInstance to create a default virtual file system inside createFileManager. In the future, we should be able to reach into the CompilerInvocation to customize this behaviour without breaking clients that don't care. llvm-svn: 201818
* Reverting the virtual file system implementation, because it triggers an ↵Juergen Ributzka2014-02-201-1/+0
| | | | | | | | | | assertion in our internal build bots. This reverts commits 201618, 201635, 201636, 201639, 201685, 201691, and 201696. llvm-svn: 201755
* Initial implementation of virtual file systemBen Langmuir2014-02-191-0/+1
| | | | | | | | | | | | This adds the minimum virtual file system support to start migrating FileManager onto the VFS. Originally discussed here: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035188.html Differential Revision: http://llvm-reviews.chandlerc.com/D2745 llvm-svn: 201618
OpenPOWER on IntegriCloud