Commit Graph

83 Commits

Author SHA1 Message Date
Petr Hosek 23fdd5a37f [CMake] Unify scripts for generating VCS headers
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
2019-02-06 03:51:00 +00:00
Petr Hosek 12062e0667 Revert "[CMake] Unify scripts for generating VCS headers"
This reverts commits r352729 and r352731: this broke Sanitizer Windows bots

llvm-svn: 352733
2019-01-31 07:12:43 +00:00
Petr Hosek 0e712a766e [CMake] Unify scripts for generating VCS headers
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
2019-01-31 06:21:01 +00:00
Craig Topper 5589738979 [Nios2] Remove Nios2 backend
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
2019-01-15 19:58:36 +00:00
Richard Trieu 6368818fd5 Move CodeGenOptions from Frontend to Basic
Basic uses CodeGenOptions and should not depend on Frontend.

llvm-svn: 348827
2018-12-11 03:18:39 +00:00
Tatyana Krasnukha f8c264e02e [clang][ARC] Add ARCTargetInfo
Based-on-patch-by: Pete Couperus <petecoup@synopsys.com>

Differential Revision: https://reviews.llvm.org/D53100

llvm-svn: 347699
2018-11-27 19:52:10 +00:00
Jonas Devlieghere fc51490baf Lift VFS from clang to llvm (NFC)
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
2018-10-10 13:27:25 +00:00
Leonard Chan a677942d8a [Fixed Point Arithmetic] Fixed Point Constant
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
2018-08-06 16:42:37 +00:00
Pavel Labath d8c6290ba4 Move VersionTuple from clang/Basic to llvm/Support
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
2018-06-11 10:28:04 +00:00
Dean Michael Berris 488f7c2b67 [XRay][clang] Add flag to choose instrumentation bundles
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
2018-04-13 02:31:58 +00:00
Alex Bradbury 71f45455e1 [RISCV] Add the RISCV target and compiler driver
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
2018-01-11 13:36:56 +00:00
Vlad Tsyrklevich 2eccdab308 Allow specifying sanitizers in blacklists
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
2017-09-25 22:11:12 +00:00
MinSeong Kim 7c2556a895 [Basic] Update CMakeLists.txt to handle repo
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
2017-09-09 14:18:53 +00:00
Erich Keane ebba592682 Break up Targets.cpp into a header/impl pair per target type[NFCI]
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
2017-07-21 22:37:03 +00:00
Brian Gesiak 7873d822f7 [Basic] Detect Git submodule version in CMake
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
2017-07-17 19:22:57 +00:00
Dean Michael Berris 835832d37a [XRay] Add -fxray-{always,never}-instrument= flags to clang
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
2017-03-30 00:29:36 +00:00
Duncan P. N. Exon Smith 030d7d6daa Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"
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
2017-03-20 17:58:26 +00:00
Renato Golin f1966cf646 Revert "Modules: Cache PCMs in memory and avoid a use-after-free"
This reverts commit r298165, as it broke the ARM builds.

llvm-svn: 298185
2017-03-18 12:31:32 +00:00
Duncan P. N. Exon Smith 079c40e886 Modules: Cache PCMs in memory and avoid a use-after-free
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
2017-03-17 22:55:13 +00:00
Michal Gorny 0ed2f4e98b [cmake] Use LLVM_CMAKE_PATH for GetSVN script
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
2016-10-19 12:21:39 +00:00
Justin Lebar 629076178a [CUDA] Add utility functions for dealing with CUDA versions / architectures.
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
2016-07-06 21:21:39 +00:00
Chris Bieneman 38238a4f56 [CMake] Remove CLANG_APPEND_VC_REV option
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
2016-06-24 20:21:12 +00:00
Saleem Abdulrasool 10a4972a8d revert SVN r265702, r265640
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
2016-04-08 16:52:00 +00:00
Saleem Abdulrasool 94cfc603d1 Basic: move CodeGenOptions from Frontend
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
2016-04-07 17:49:44 +00:00
Eric Fiselier 098e6de9aa Add `-verify-ignore-unexpected` option to ignore unexpected diagnostics in 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
2015-06-13 07:11:40 +00:00
Paul Robinson af6b86ca98 Revert r223578, perf data collection depends on the old symbol name.
llvm-svn: 223987
2014-12-10 23:49:03 +00:00
Nico Weber d95699e9e7 cmake: Make SVNVersion.inc step depend on GetSVN.cmake.
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
2014-12-10 00:03:37 +00:00
Paul Robinson 01105887ab Rename a couple of preprocessor symbols to be more descriptive. NFC.
Review feedback from recent changes to GetSVN.cmake.

llvm-svn: 223578
2014-12-06 05:06:37 +00:00
Paul Robinson 91f0edc55f Specify the name of the generated header only once. NFC.
This will also simplify a private patch that we have.

llvm-svn: 223537
2014-12-05 22:32:49 +00:00
Jordan Rose 08b3638b84 [CMake] Use .svn/wc.db as our VC dependency if it's available.
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
2014-11-20 03:57:45 +00:00
Jordan Rose 85216ef0c3 [CMake] Always include the Clang repo version, just like the autoconf build.
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
2014-11-19 22:03:48 +00:00
Alexey Samsonov a041610f11 [Sanitizer] Refactor sanitizer options in LangOptions.
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
2014-11-11 01:26:14 +00:00
NAKAMURA Takumi 86204b21e9 [CMake] clangBasic: Add Core to LINK_COMPONENTS introduced by r219840.
llvm-svn: 219880
2014-10-16 00:12:02 +00:00
Alexey Samsonov 8d043e82ef Move SanitizerBlacklist to clangBasic. NFC.
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
2014-10-15 19:57:45 +00:00
Ben Langmuir b92de02f17 Reapply r207477 and r207479 without cyclic dependency
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
2014-04-29 16:25:26 +00:00
Aaron Ballman 2fbf99429a Reapplying r204952 a second time.
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
2014-03-31 13:14:44 +00:00
Aaron Ballman 0efd167f81 Reverting r204968 and r204969; while more build bots are happy with the results, some still have link errors.
llvm-svn: 204974
2014-03-27 22:37:56 +00:00
Aaron Ballman c9ad1ca715 Reapplying r204952 with fixes which should hopefully resolve linking issues with non-MSVC compilers.
llvm-svn: 204968
2014-03-27 22:12:09 +00:00
Aaron Ballman 0702d02b31 Reverting r204952, while I figure out what's going on with the makefile build.
llvm-svn: 204955
2014-03-27 20:36:32 +00:00
Aaron Ballman 9cac6f5f04 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: 204952
2014-03-27 20:19:24 +00:00
NAKAMURA Takumi 7da9487dd4 [CMake] Get rid of explicit dependencies to include/clang/*.inc and 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
2014-02-21 07:59:59 +00:00
Ben Langmuir c8130a74f4 Recommit virtual file system
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
2014-02-20 21:59:23 +00:00
Juergen Ributzka a32575e4f6 Reverting the virtual file system implementation, because it triggers an assertion
in our internal build bots.

This reverts commits 201618, 201635, 201636, 201639, 201685, 201691, and 201696.

llvm-svn: 201755
2014-02-20 05:24:58 +00:00
Ben Langmuir 090610d37a Initial implementation of virtual file system
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
2014-02-19 00:10:30 +00:00
Nico Weber 7c81c4a354 [cmake] Write Version.inc at cmake time, not at build time.
In SVN checkouts, clang_revision_tag is rerun on every build, even if nothing
else is dirty.  After this change, Version.inc is only written at cmake time,
so that empty builds run 0 build steps (like r191784 apparently did for git).

llvm-svn: 198704
2014-01-07 20:10:39 +00:00
NAKAMURA Takumi 65d42bcc2b [CMake] clang/lib: Satisfy dependencies to add *actually used* libraries on target_link_libraries() and LLVM_LINK_COMPONENTS.
I will prune redundant dependencies later.

llvm-svn: 196800
2013-12-09 19:04:43 +00:00
NAKAMURA Takumi 014529f595 Add newline at eof.
llvm-svn: 196346
2013-12-04 03:40:51 +00:00
Rafael Espindola fc74c81451 Revert commits r190613, r190560 and r190557.
The added a cmake invocation to null builds, making them a lot slower.

llvm-svn: 191784
2013-10-01 17:31:40 +00:00
Jordan Rose f31f5f8488 [CMake] Put controversial always-recheck-revision-number behind an option.
CMake does not have the ability to perform actions before calculating
dependencies, so it can't know whether it needs to rebuild clangBasic
to update for a new revision number. CLANG_ALWAYS_CHECK_VC_REV (off by
default) will cause clangBasic to always be dirty by deleting the
generated SVNVersion.inc after use; otherwise, SVNVersion.inc will
always be updated, but only included in the final binary when clangBasic
is rebuilt.

It'd be great to find a better way to do this, but hopefully this is
still an improvement over the complete lack of version information before.

llvm-svn: 190613
2013-09-12 16:17:41 +00:00
Jordan Rose e51d5f6706 [CMake] Fix repository version checking dependencies harder.
Just always regenerate SVNVersion.inc. Don't worry about it not changing.

llvm-svn: 190560
2013-09-11 23:12:55 +00:00