This unifies the unix and windows versions of FileManager::UniqueDirContainer
and FileManager::UniqueFileContainer by using UniqueID.
We cannot just replace "struct stat" with llvm::sys::fs::file_status, since we
want to be able to construct fake ones, and file_status has different members
on unix and windows.
What the patch does is:
* Record only the information that clang is actually using.
* Use llvm::sys::fs::status instead of stat and fstat.
* Use llvm::sys::fs::UniqueID
* Delete the old windows versions of UniqueDirContainer and
UniqueFileContainer since the "unix" one now works on windows too.
llvm-svn: 187619
When BUILD_CLANG_ONLY is set to YES, it is supposed to simply limit the tools
that get built. The change in r184794 broke this feature by moving libclang
and c-index-test into PARALLEL_DIRS. Those are both supposed to be in DIRS,
because c-index-test has a build dependency on libclang and cannot be
reliably built in parallel with it.
llvm-svn: 187246
Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)
I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.
llvm-svn: 187156
After the first operation, the buffer contents has changed and thus all
other operations would be invalid. Executing the operations in reversed
order should fix this.
llvm-svn: 186840
With this fix, only changed regions will be replaced in vim's buffer.
Thereby, marks should mostly be left intact. Furthermore, this is a
better fix for the performance problem in conjunction with
'foldmethod=syntax' (see r186660).
llvm-svn: 186789
The previous line-by-line replacement causes vim to take a long time if
the foldmethod is set to 'syntax'. This should significantly improve
performance in that case.
llvm-svn: 186660
and add a new option --driver-mode= to control it explicitly.
The CCCIsCXX and CCCIsCPP flags were non-overlapping, i.e. there
are currently really three modes that Clang can run in: gcc, g++
or cpp, so it makes sense to represent them as an enum.
Having a command line flag to control it helps testing.
llvm-svn: 186605
MSBuild writes response files as UTF-16 little endian with a byte order
mark. With this change, clang will be able to read them, although we
still can't parse any of their flags.
Adds a UTF-16-LE response file with a BOM for testing.
Differential Revision: http://llvm-reviews.chandlerc.com/D1137
llvm-svn: 186603
These flags control language options and user-visible macros, so it's
important to preserve them when analyzing. Rather than try to keep up
with all the -f flags, we'll pass them all through and then ban the ones
we don't want (like -fsyntax-only).
-Wwrite-strings is really an f-flag in disguise: it implies -fconst-strings.
Patch by Keaton Mowry, modified by me.
llvm-svn: 186138
-Wdocumentation won't seek -isystem. LIBXML2's headers in a certain distro might be incompatible to -Wdocumentation.
FIXME: Could autoconf detect clang or availability of -isystem?
llvm-svn: 185927
This is important for preprocessing steps, which may output to stdout.
Also, change ENV accesses using barewords to use string keys instead.
PR16414
llvm-svn: 185555
Previously, the CMake build still tried to link clang against the static
analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off.
Furthermore, clang-check depends on the analyzer, so it should be disabled
(in both CMake and configure builds).
In theory, clang-check could be made to conditionally include analyzer
support (like clang itself), but for now this at least gets a CMake ALL_BUILD
working.
Patch by Stephen Kelly, modified by me.
llvm-svn: 185548
Before, the computed byte range would include the trailing newline.
clang-format on the other hand counts whitespace as belonging to the
following token, so that git-clang-format inadvertendly reformats the
first unmodified line as well.
It is not entirely clear whether clang-format's behavior itself should
be modified, but for now this seems to be a safe change.
llvm-svn: 185423
The build system is currently miss-identifying GNU/kFreeBSD as FreeBSD.
This kind of simplification is sometimes useful, but in general it's not correct.
As GNU/kFreeBSD is an hybrid system, for kernel-related issues we want to match the
build definitions used for FreeBSD, whereas for userland-related issues we want to
match the definitions used for other systems with Glibc.
The current modification adjusts the build system so that they can be distinguished,
and explicitly adds GNU/kFreeBSD to the build checks in which it belongs.
Fixes bug #16445.
Patch by Robert Millan in the context of Debian.
llvm-svn: 185312
Summary:
Some valid pre-C++11 constructs change meaning when lexed in C++11
mode, e.g.
#define x(_a) printf("foo"_a);
(example from http://llvm.org/bugs/show_bug.cgi?id=16342). "foo"_a is treated as
a user-defined string literal when parsed in C++11 mode.
In order to deal with this correctly, we need to set lexing mode according to
which standard the code conforms to. We already have a configuration value for
this (FormatStyle.Standard), which seems to be appropriate to use in this case
as well.
Reviewers: klimek
CC: cfe-commits, gribozavr
Differential Revision: http://llvm-reviews.chandlerc.com/D1028
llvm-svn: 185149
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
llvm-svn: 184763
print-size-type.cpp was checking for specific record layout output for invalid
decls; I've removed the checks but left the records as tests for not crashing.
llvm-svn: 184751
Enea Zaffanella