Vedant Kumar [Mon, 19 Nov 2018 20:10:21 +0000 (20:10 +0000)]
[Sema] Fix PR38987: keep end location of a direct initializer list
If PerformConstructorInitialization of a direct initializer list constructor is
called while instantiating a template, it has brace locations in its BraceLoc
arguments but not in the Kind argument.
This reverts the hunk https://reviews.llvm.org/D41921#inline-468844.
Roman Lebedev [Mon, 19 Nov 2018 19:56:43 +0000 (19:56 +0000)]
[clang][CodeGen] Implicit Conversion Sanitizer: discover the world of CompoundAssign operators
Summary:
As reported by @regehr (thanks!) on twitter (https://twitter.com/johnregehr/status/1057681496255815686),
we (me) has completely forgot about the binary assignment operator.
In AST, it isn't represented as separate `ImplicitCastExpr`'s,
but as a single `CompoundAssignOperator`, that does all the casts internally.
Which means, out of these two, only the first one is diagnosed:
```
auto foo() {
unsigned char c = 255;
c = c + 1;
return c;
}
auto bar() {
unsigned char c = 255;
c += 1;
return c;
}
```
https://godbolt.org/z/JNyVc4
This patch does handle the `CompoundAssignOperator`:
```
int main() {
unsigned char c = 255;
c += 1;
return c;
}
```
```
$ ./bin/clang -g -fsanitize=integer /tmp/test.c && ./a.out
/tmp/test.c:3:5: runtime error: implicit conversion from type 'int' of value 256 (32-bit, signed) to type 'unsigned char' changed the value to 0 (8-bit, unsigned)
#0 0x2392b8 in main /tmp/test.c:3:5
#1 0x7fec4a612b16 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x22b16)
#2 0x214029 in _start (/build/llvm-build-GCC-release/a.out+0x214029)
```
However, the pre/post increment/decrement is still not handled.
Paul Robinson [Mon, 19 Nov 2018 18:29:28 +0000 (18:29 +0000)]
[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-specific flags from there to the new flags word.
This patch does not change IR/bitcode formats, that will be
done in a follow-up.
Zachary Turner [Mon, 19 Nov 2018 15:12:34 +0000 (15:12 +0000)]
Fix some issues with LLDB's lit configuration files.
Recently I tried to port LLDB's lit configuration files over to use a
on the surface, but broke some cases that weren't broken before and also
exposed some additional problems with the old approach that we were just
getting lucky with.
When we set up a lit environment, the goal is to make it as hermetic as
possible. We should not be relying on PATH and enabling the use of
arbitrary shell commands. Instead, only whitelisted commands should be
allowed. These are, generally speaking, the lit builtins such as echo,
cd, etc, as well as anything for which substitutions have been
explicitly set up for. These substitutions should map to the build
output directory, but in some cases it's useful to be able to override
this (for example to point to an installed tools directory).
This is, of course, how it's supposed to work. What was actually
happening is that we were bringing in PATH and LD_LIBRARY_PATH and then
just running the given run line as a shell command. This led to problems
such as finding the wrong version of clang-cl on PATH since it wasn't
even a substitution, and flakiness / non-determinism since the
environment the tests were running in would change per-machine. On the
other hand, it also made other things possible. For example, we had some
tests that were explicitly running cl.exe and link.exe instead of
clang-cl and lld-link and the only reason it worked at all is because it
was finding them on PATH. Unfortunately we can't entirely get rid of
these tests, because they support a few things in debug info that
clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record
which makes some of the tests fail.
The high level changes introduced in this patch are:
1. Removal of functionality - The lit test suite no longer respects
LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
more support for gcc, but nobody was using this anyway (note: The
functionality is still there for the dotest suite, just not the lit test
suite). There is no longer a single substitution %cxx and %cc which maps
to <arbitrary-compiler>, you now explicitly specify the compiler with a
substitution like %clang or %clangxx or %clang_cl. We can revisit this
in the future when someone needs gcc.
2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit
what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now
more friendly. If this is not specified, all tools are expected to be
the just-built tools. If it is specified, the tools which are not
themselves being tested but are being used to construct and run checks
(e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this
directory first, then the build output directory.
3. Changes to core llvm lit files. The use_lld() and use_clang()
functions were introduced long ago in anticipation of using them in
lldb, but since they were never actually used anywhere but their
respective problems, there were some issues to be resolved regarding
generality and ability to use them outside their project.
4. Changes to .test files - These are all just replacing things like
clang-cl with %clang_cl and %cxx with %clangxx, etc.
5. Changes to lit.cfg.py - Previously we would load up some system
environment variables and then add some new things to them. Then do a
bunch of work building out our own substitutions. First, we delete the
system environment variable code, making the environment hermetic. Then,
we refactor the substitution logic into two separate helper functions,
one which sets up substitutions for the tools we want to test (which
must come from the build output directory), and another which sets up
substitutions for support tools (like compilers, etc).
6. New substitutions for MSVC -- Previously we relied on location of
MSVC by bringing in the entire parent's PATH and letting
subprocess.Popen just run the command line. Now we set up real
substitutions that should have the same effect. We use PATH to find
them, and then look for INCLUDE and LIB to construct a substitution
command line with appropriate /I and /LIBPATH: arguments. The nice thing
about this is that it opens the door to having separate %msvc-cl32 and
%msvc-cl64 substitutions, rather than only requiring the user to run
vcvars first. Because we can deduce the path to 32-bit libraries from
64-bit library directories, and vice versa. Without these substitutions
this would have been impossible.
Sam McCall [Mon, 19 Nov 2018 13:37:46 +0000 (13:37 +0000)]
[FileManager] getFile(open=true) after getFile(open=false) should open the file.
Summary:
Old behavior is to just return the cached entry regardless of opened-ness.
That feels buggy (though I guess nobody ever actually needed this).
This came up in the context of clangd+clang-tidy integration: we're
going to getFile(open=false) to replay preprocessor actions obscured by
the preamble, but the compilation may subsequently getFile(open=true)
for non-preamble includes.
Kristof Umann [Sun, 18 Nov 2018 11:34:10 +0000 (11:34 +0000)]
[analyzer][UninitializedObjectChecker] Uninit regions are only reported once
Especially with pointees, a lot of meaningless reports came from uninitialized
regions that were already reported. This is fixed by storing all reported fields
to the GDM.
Jan Kratochvil [Sun, 18 Nov 2018 09:36:36 +0000 (09:36 +0000)]
cmake: z3: Remove EXACT from 4.7.1 after being compatible with 4.8.1
After check-in of D54391 a comment there by @mikhail.ramalho says:
Since we're supporting version 4.8.1 now, the cmake file should be changed to
"minimum" instead of "exact".
Calixte Denizet [Sat, 17 Nov 2018 19:41:39 +0000 (19:41 +0000)]
[Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659)
Summary:
the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows.
So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c.
Petr Hosek [Fri, 16 Nov 2018 23:07:03 +0000 (23:07 +0000)]
[CMake] Use lld and llvm-objcopy for first stage compiler in Fuchsia
When cross-compiling the second stage to a different target, we need to
make sure that the first-stage compiler can produce binaries for that
target. Using lld and llvm-objcopy as the default linker and objcopy
tool eliminates some of the dependencies on the host toolchain.
Alexey Bataev [Fri, 16 Nov 2018 21:13:33 +0000 (21:13 +0000)]
[OPENMP]Fix PR39694: do not capture `this` in non-`this` region.
If lambda is used inside of the OpenMP region and captures `this`, we
should recapture it in the OpenMP region also. But we should do this
only if the OpenMP region is used in the context of the same class, just
like the lambda.
Alexey Bataev [Fri, 16 Nov 2018 19:38:21 +0000 (19:38 +0000)]
[OPENMP][NVPTX]Emit correct reduction code for teams/parallel
reductions.
Fixed previously committed code for the reduction support in
teams/parallel constructs taking into account new design of the NVPTX
support in the compiler. Teams reduction are not fully functional yet,
it is going to be fixed in the following patches.
Reid Kleckner [Fri, 16 Nov 2018 18:47:41 +0000 (18:47 +0000)]
[codeview] Expose -gcodeview-ghash for global type hashing
Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.
This removes the LLVM cl::opt and replaces it with a metadata flag.
After this change, users can do the following to use ghash:
- add -gcodeview-ghash to compiler flags
- replace /DEBUG with /DEBUG:GHASH in linker flags
[OpenCL] Enable address spaces for references in C++
Added references to the addr spaces deduction and enabled
CL2.0 features (program scope variables and storage class
qualifiers) to work in C++ mode too.
Fixed several address space conversion issues in CodeGen
for references.
George Rimar [Fri, 16 Nov 2018 07:59:24 +0000 (07:59 +0000)]
[clang] - Simplify tools::SplitDebugName.
This should be NFC change.
SplitDebugName recently started to accept the `Output` that
can be used to simplify the logic a bit, also it
seems that code in SplitDebugName that uses
OPT_fdebug_compilation_dir is simply dead.
Petr Hosek [Fri, 16 Nov 2018 04:46:48 +0000 (04:46 +0000)]
[CMake] Support cross-compiling with multi-stage builds
When using multi-stage builds, we would like support cross-compilation.
Example is 2-stage build when the first stage is compiled for host while
the second stage is compiled for the target.
Normally, the second stage would be also used for compiling runtimes,
but that's not possible when cross-compiling, so we use the first stage
compiler instead. However, we still want to use the second stage paths.
To do so, we set the -resource-dir of the first stage compiler to point
to the resource directory of the second stage.
We also need compiler tools that support the target architecture. These
tools are not guaranteed to be present on the host, but in case of
multi-stage build, we can build these tools in the first stage.
Zi Xuan Wu [Fri, 16 Nov 2018 03:00:00 +0000 (03:00 +0000)]
[Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error
There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to
choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example,
It fixes the case when Objective-C framework is added as a subframework
through a symlink. When parent framework infers a module map and fails
to detect a symlink, it would add a subframework as a submodule. And
when we parse module map for the subframework, we would encounter an
error like
> error: umbrella for module 'WithSubframework.Foo' already covers this directory
By implementing `getRealPath` "an egregious but useful hack" in
`ModuleMap::inferFrameworkModule` works as expected.
Kristof Umann [Fri, 16 Nov 2018 01:00:55 +0000 (01:00 +0000)]
[analyzer] ConversionChecker: handle floating point
Extend the alpha.core.Conversion checker to handle implicit converions
where a too large integer value is converted to a floating point type. Each
floating point type has a range where it can exactly represent all integers; we
emit a warning when the integer value is above this range. Although it is
possible to exactly represent some integers which are outside of this range
(those that are divisible by a large enough power of 2); we still report cast
involving those, because their usage may lead to bugs. (For example, if 1<<24
is stored in a float variable x, then x==x+1 holds.)
Heejin Ahn [Fri, 16 Nov 2018 00:48:58 +0000 (00:48 +0000)]
[WebAssembly] Change type of wake count to unsigned int
Summary:
We discussed this at the Nov 12th CG meeting, and decided to use the
unsigned semantics for the wake count.
Corresponding spec change:
https://github.com/WebAssembly/threads/pull/110
Bruno Ricci [Thu, 15 Nov 2018 17:31:16 +0000 (17:31 +0000)]
[AST] Store the string data in StringLiteral in a trailing array of chars
Use the newly available space in the bit-fields of Stmt and store the
string data in a trailing array of chars after the trailing array
of SourceLocation. This cuts the size of StringLiteral by 2 pointers.
Also refactor slightly StringLiteral::Create and StringLiteral::CreateEmpty
so that StringLiteral::Create is just responsible for the allocation, and the
constructor is responsible for doing all the initialization. This match what
is done for the other classes in general.
This patch should have no other functional changes apart from this.
A concern was raised during review about the interaction between
this patch and serialization abbreviations. I believe however that
there is currently no abbreviation defined for StringLiteral.
The only statements/expressions which have abbreviations are currently
DeclRefExpr, IntegerLiteral, CharacterLiteral and ImplicitCastExpr.
Bruno Ricci [Thu, 15 Nov 2018 16:42:14 +0000 (16:42 +0000)]
[AST][NFC] Various NFCs in StringLiteral
Factored out of D54166
([AST] Store the string data in StringLiteral in a trailing array of chars):
* For-range loops in containsNonAscii and containsNonAsciiOrNull.
* Comments and style fixes.
* int -> unsigned in mapCharByteWidth since TargetInfo::getCharWidth
and friends return an unsigned, and StringLiteral manipulates and
stores CharByteWidth as an unsigned.
David Blaikie [Thu, 15 Nov 2018 03:04:21 +0000 (03:04 +0000)]
Fix combining pragma __debug dump & parser_crash with -E
Previously these would be transformed into annotation tokens and the
preprocessor would then assume they were real tokens with source
locations and assert/UB.
Other pragmas that produce annotation tokens aren't a problem because
they aren't handled if the parser isn't hooked up - ParsePragma.cpp
registers those handlers & isn't run for pure preprocessing. So they're
treated as unknown pragmas & printed verbatim by the preprocessor.
Perhaps these pragmas should be treated the same way? But they got mixed
in with other __debug pragmas that do need to be handled during
preprocessing.
The third __debug pragma that produces an annotation token is 'captured'
- which had its own fix for this issue - by not inserting the annotation
token in the first place if it detected that it was in preprocessing
mode. I've removed that fix (from Lex/Pragma.cpp) in favor of the more
general one in Frontend/PrintPreprocessedOutput.cpp.
David Blaikie [Thu, 15 Nov 2018 03:04:19 +0000 (03:04 +0000)]
Rewrite-imports on crash: Simplify handling
-frewrite-imports already implies -frewrite-includes (it piggy-backs
on/extends the implementation) so there's no need to conditionally pass
-frewrite-includes when already using -frewrite-imports (& especially I
don't think these would want to be different between crash reporting and
not crash reporting)
JF Bastien [Thu, 15 Nov 2018 00:19:18 +0000 (00:19 +0000)]
CGDecl::emitStoresForConstant fix synthesized constant's name
Summary: The name of the synthesized constants for constant initialization was using mangling for statics, which isn't generally correct and (in a yet-uncommitted patch) causes the mangler to assert out because the static ends up trying to mangle function parameters and this makes no sense. Instead, mangle to `"__const." + FunctionName + "." + DeclName`.
Reid Kleckner [Wed, 14 Nov 2018 22:59:27 +0000 (22:59 +0000)]
[codeview] Make "clang -g" emit codeview by default when targetting MSVC
Summary:
If you're using the Microsoft ABI, chances are that you want PDBs and
codeview debug info. Currently, everyone has to remember to specific
-gcodeview by default, when it would be nice if the standard -g option
did the right thing by default.
Also, do some related cleanup of -cc1 options. When targetting the MS
C++ ABI, we probably shouldn't pass -debugger-tuning=gdb. We were also
passing -gcodeview twice, which is silly.
Richard Smith [Wed, 14 Nov 2018 21:04:34 +0000 (21:04 +0000)]
[c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.
This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
Scott Linder [Wed, 14 Nov 2018 19:39:59 +0000 (19:39 +0000)]
[Support] Teach YAMLIO about polymorphic types
Add support for "polymorphic" types to YAMLIO.
PolymorphicTraits can dynamically switch between other traits (Scalar, Map, or
Sequence). When inputting, the PolymorphicTraits type is told which type to
become, and when outputting the PolymorphicTraits type is asked which type it
currently is.
Also add support for TaggedScalarTraits to allow dynamically differentiating
between multiple scalar types using YAML tags.
Serialize empty maps as "{}" and empty sequences as "[]", so that types
are preserved when round-tripping PolymorphicTraits. This change has
equivalent semantics, but may break e.g. tests which compare output
verbatim.
Sam McCall [Wed, 14 Nov 2018 10:33:30 +0000 (10:33 +0000)]
[AST] Allow limiting the scope of common AST traversals (getParents, RAV).
Summary:
The goal is to allow analyses such as clang-tidy checks to run on a
subset of the AST, e.g. "only on main-file decls" for interactive tools.
Today, these become "problematically global" by running RecursiveASTVisitors
rooted at the TUDecl, or by navigating up via ASTContext::getParent().
The scope is restricted using a set of top-level-decls that RecursiveASTVisitors
should be rooted at. This also applies to the visitor that populates the
parent map, and so the top-level-decls are considered to have no parents.
This patch makes the traversal scope a mutable property of ASTContext.
The more obvious way to do this is to pass the top-level decls to
relevant functions directly, but this has some problems:
- it's error-prone: accidentally mixing restricted and unrestricted
scopes is a performance trap. Interleaving multiple analyses is
common (many clang-tidy checks run matchers or RAVs from matcher callbacks)
- it doesn't map well to the actual use cases, where we really do want
*all* traversals to be restricted.
- it involves a lot of plumbing in parts of the code that don't care
about traversals.
This approach was tried out in D54259 and D54261, I wanted to like it
but it feels pretty awful in practice.
Caveats: to get scope-limiting behavior of RecursiveASTVisitors, callers
have to call the new TraverseAST(Ctx) function instead of TraverseDecl(TU).
I think this is an improvement to the API regardless.
George Rimar [Wed, 14 Nov 2018 09:22:16 +0000 (09:22 +0000)]
[Clang] - Add '-gsplit-dwarf[=split,=single]' version for '-gsplit-dwarf' option.
The DWARF5 specification says(Appendix F.1):
"The sections that do not require relocation, however, can be
written to the relocatable object (.o) file but ignored by the
linker or they can be written to a separate DWARF object (.dwo)
file that need not be accessed by the linker."
The first part describes a single file split DWARF feature and there
is no way to trigger this behavior atm.
Fortunately, no many changes are required to keep *.dwo sections
in a .o, the patch does that.
Alex Lorenz [Wed, 14 Nov 2018 01:08:03 +0000 (01:08 +0000)]
[HeaderSearch] loadSubdirectoryModuleMaps should respect -working-directory
Include search paths can be relative paths. The loadSubdirectoryModuleMaps function
should account for that and respect the -working-directory parameter given to Clang.
Matt Arsenault [Tue, 13 Nov 2018 22:30:35 +0000 (22:30 +0000)]
OpenCL: Don't warn on v printf modifier
This avoids spurious warnings, but could use
a lot of work. For example the number of vector
elements is not verified, and the passed
value type is not checked.
David Greene [Tue, 13 Nov 2018 21:38:45 +0000 (21:38 +0000)]
[Driver] Support g++ headers in include/g++
ray's gcc installation puts C++ headers in PREFIX/include/g++ without
indicating a gcc version at all. Typically this is because the version
is encoded somewhere in PREFIX.
David Blaikie [Tue, 13 Nov 2018 20:08:13 +0000 (20:08 +0000)]
DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.
Summary:
This saves a lot of relocations in optimized object files (at the cost
of some cost/increase in linked executable bytes), but gold's 32 bit
gdb-index support has a bug (
https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't
switch to this unconditionally. (& even if it weren't for that bug, one
might argue that some users would want to optimize in one direction or
the other - prioritizing object size or linked executable size)
Bruno Ricci [Tue, 13 Nov 2018 19:27:39 +0000 (19:27 +0000)]
[AST][NFC] Style fixes for UnaryOperator
In preparation for the patch which will move some data to the bit-fields
of Stmt. In particular, rename the private variable "Val" -> "Operand"
since the substatement is the operand of the unary operator.
Run clang-format on UnaryOperator. NFC otherwise.
Erich Keane [Tue, 13 Nov 2018 15:48:08 +0000 (15:48 +0000)]
[NFC] Move storage of dispatch-version to GlobalDecl
As suggested by Richard Smith, and initially put up for review here:
https://reviews.llvm.org/D53341, this patch removes a hack that was used
to ensure that proper target-feature lists were used when emitting
cpu-dispatch (and eventually, target-clones) implementations. As a part
of this, the GlobalDecl object is proliferated to a bunch more
locations.
Originally, this was put up for review (see above) to get acceptance on
the approach, though discussion with Richard in San Diego showed he
approved of the approach taken here. Thus, I believe this is acceptable
for Review-After-commit
[clang-format] Do not treat the asm clobber [ as ObjCExpr
Summary:
The opening square of an inline asm clobber was being annotated as an ObjCExpr.
This caused, amongst other things, the ObjCGuesser to guess header files
containing that pattern as ObjC files.
Takuto Ikuta [Tue, 13 Nov 2018 04:14:09 +0000 (04:14 +0000)]
[clang-cl] Do not allow using both /Zc:dllexportInlines- and /fallback flag
Summary: /Zc:dllexportInlines with /fallback may cause unexpected linker error. It is better to disallow compile rather than warn for this combination.
Tom Stellard [Tue, 13 Nov 2018 03:42:46 +0000 (03:42 +0000)]
CMake: Deprecate using llvm-config to detect llvm installation
Summary:
clang currently uses llvm-config to determine the installation paths
for llvm's headers and binaries. clang is also using LLVM's cmake
files to determine other information about the LLVM build, like
LLVM_LIBDIR_SUFFIX, LLVM_VERSION_*, etc. Since the installation
paths are also available via the cmake files, we can simplify the code
by only relying on information from cmake about the LLVM install and
dropping the use of llvm-config altogether.
In addition to simplifying the code, the cmake files have more
accurate information about the llvm installation paths. llvm-config
assumes that the lib, bin, and cmake directories are always located
in the same place relative to the path of the llvm-config executable.
This can be wrong if a user decides to install headers, binaries
or libraries to a non-standard location: e.g. static libraries
installed to /usr/lib/llvm6.0/
This patch takes the first step towards dropping llvm-config by
removing the automatic detection of llvm-config (users can still
manually supply a path to llvm-config by passing
-DLLVM_CONFIG=/usr/bin/llvm-config to cmake) and adding a
deprecation warning when users try to use this option.
Jordan Rupprecht [Mon, 12 Nov 2018 18:15:04 +0000 (18:15 +0000)]
[clang-format] Support breaking consecutive string literals for TableGen
Summary:
clang-format can get confused by string literals in TableGen: it knows that strings can be broken up, but doesn't seem to understand how that can be indented across line breaks, and arranges them in a weird triangular pattern. Take this output example from `clang-format tools/llvm-objcopy/ObjcopyOpts.td` (which has now been formatted in rL345896 with this patch applied):
```
defm keep_global_symbols
: Eq<
"keep-global-symbols", "Reads a list of symbols from <filename> and "
"runs as if " "--keep-global-symbol=<symbol> "
"is set for each one. "
"<filename> " "contains one "
"symbol per line "
"and may contain "
"comments "
"beginning " "with"
" '#'"
". "
"Lead"
"ing "
```
Kristof Umann [Mon, 12 Nov 2018 17:49:51 +0000 (17:49 +0000)]
[analyzer] Drastically simplify the tblgen files used for checkers
Interestingly, only about the quarter of the emitter file is used, the DescFile
entry hasn't ever been touched [1], and the entire concept of groups is a
mystery, so I removed them.
Ilya Biryukov [Mon, 12 Nov 2018 13:55:55 +0000 (13:55 +0000)]
Make clang-based tools find libc++ on MacOS
Summary:
When they read compiler args from compile_commands.json.
This change allows to run clang-based tools, like clang-tidy or clangd,
built from head using the compile_commands.json file produced for XCode
toolchains.
On MacOS clang can find the C++ standard library relative to the
compiler installation dir.
The logic to do this was based on resource dir as an approximation of
where the compiler is installed. This broke the tools that read
'compile_commands.json' and don't ship with the compiler, as they
typically change resource dir.
To workaround this, we now use compiler install dir detected by the driver
to better mimic the behavior of the original compiler when replaying the
compilations using other tools.
Calixte Denizet [Mon, 12 Nov 2018 09:52:14 +0000 (09:52 +0000)]
[GCOV] fix test after patch rL346642
Summary:
Test is failing under windows, so fix it.
Should fix:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/1390/steps/stage%201%20check/logs/stdio
Calixte Denizet [Mon, 12 Nov 2018 09:12:27 +0000 (09:12 +0000)]
[Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov
Summary:
These options are taking regex separated by colons to filter files.
- if both are empty then all files are instrumented
- if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented
- if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented
- if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented
- this patch is a follow-up of https://reviews.llvm.org/D52033
Jan Kratochvil [Mon, 12 Nov 2018 06:48:02 +0000 (06:48 +0000)]
Fix compatibility with z3-4.8.1
With z3-4.8.1:
../tools/clang/lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp:49:40: error:
'Z3_get_error_msg_ex' was not declared in this scope
../tools/clang/lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp:49:40: note:
suggested alternative: 'Z3_get_error_msg'
Formerly used Z3_get_error_msg_ex() as one could find in z3-4.7.1 states:
"Retained function name for backwards compatibility within v4.1"
And it is implemented only as a forwarding call:
return Z3_get_error_msg(c, err);
Michael Wu [Mon, 12 Nov 2018 02:44:33 +0000 (02:44 +0000)]
Support Swift in platform availability attribute
Summary: This adds support for Swift platform availability attributes. It's largely a port of the changes made to https://github.com/apple/swift-clang/ for Swift availability attributes. Specifically, https://github.com/apple/swift-clang/commit/84b5a21c31cb5b0d7d958a478bc01964939b6952 and https://github.com/apple/swift-clang/commit/e5b87f265aede41c8381094bbf54e2715c8293b0 . The implementation of attribute_availability_swift is a little different and additional tests in test/Index/availability.c were added.
projects / clang / log