Summary:
This allows us to do the following:
clang -fxray-modes=none ... -fxray-modes=xray-basic
It's important to be able to do this in cases where we'd like to
specialise the configuration for the invocation of the compiler, in
various scripting environments.
This is related to llvm.org/PR37066, a follow-up to D45474.
Reviewers: eizan, kpw, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45610
llvm-svn: 329989
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
"-mllvm" options get parsed slightly earlier, and -arm-restrict-it is
only available if the ARM target is compiled in. Invoke "clang -cc1"
directly to avoid the issue.
llvm-svn: 329968
It means the same thing as -mllvm; there isn't any reason to have two
options which do the same thing.
Differential Revision: https://reviews.llvm.org/D45109
llvm-svn: 329965
This makes it consistent with libstdc++ and the other default
include directories.
If these headers are found in both locations and one isn't a
symlink to the other, this will cause errors due to libc++ headers
having wrapper headers for some standard C headers, wrappers that
do #include_next the actual one.
If the same libc++ standard C wrapper header exists in more than one
include directory before the real system one, the header include
guard will stop it from doing another #include_next to pick up the
real one, breaking things.
As this is a rather uncommon situation, this should be acceptable
and toolchain maintainers can adapt accordingly if necessary.
Also simplify some of the existing code with a local variable.
Differential Revision: https://reviews.llvm.org/D45500
llvm-svn: 329946
Summary: The logic was broken for Linux triples as it returns true in the switch for Triple.isOSLinux().
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: kito-cheng, shiva0217, cfe-commits
Differential Revision: https://reviews.llvm.org/D45237
llvm-svn: 329941
A previously missing intrinsic for an old instruction.
Reviewers: craig.topper, echristo
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45311
llvm-svn: 329937
I broke this test in D45498 when I changed the formatter to remove
spaces before Objective-C lightweight generics.
This fixes the test.
Test Plan:
% make -j16 check-llvm-tools-llvm-lit && ./bin/llvm-lit -sv ../llvm/tools/clang/test/Index/comment-objc-parameterized-classes.m
llvm-svn: 329921
Summary:
Previously, `clang-format` would break Objective-C
category extensions after the opening parenthesis to avoid
breaking the protocol list:
```
% echo "@interface ccccccccccccc (ccccccccccc) <ccccccccccccc> { }" | \
clang-format -assume-filename=foo.h -style="{BasedOnStyle: llvm, \
ColumnLimit: 40}"
@interface ccccccccccccc (
ccccccccccc) <ccccccccccccc> {
}
```
This looks fairly odd, as we could have kept the category extension
on the previous line.
Category extensions are a single item, so they are generally very
short compared to protocol lists. We should prefer breaking after the
opening `<` of the protocol list over breaking after the opening `(`
of the category extension.
With this diff, we now avoid breaking after the category extension's
open paren, which causes us to break after the protocol list's
open angle bracket:
```
% echo "@interface ccccccccccccc (ccccccccccc) <ccccccccccccc> { }" | \
./bin/clang-format -assume-filename=foo.h -style="{BasedOnStyle: llvm, \
ColumnLimit: 40}"
@interface ccccccccccccc (ccccccccccc) <
ccccccccccccc> {
}
```
Test Plan: New test added. Confirmed test failed before diff and
passed after diff by running:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45526
llvm-svn: 329919
Summary:
This diff improves the Objective-C guessing heuristic by
replacing the hard-coded list of a subset of Objective-C @keywords
with a general check which supports all @keywords.
I also added a few more Foundation keywords which were missing from
the heuristic.
Test Plan: Unit tests updated. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45521
llvm-svn: 329918
Summary:
In D45185, I added clang-format parser support for Objective-C
generics. However, I didn't touch the whitespace logic, so they
got the same space logic as Objective-C protocol lists.
In every example in the Apple SDK and in the documentation,
there is no space between the class name and the opening `<`
for the lightweight generic specification, so this diff
removes the space and updates the tests.
Test Plan: Tests updated. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45498
llvm-svn: 329917
Summary:
Currently, indentation of Objective-C method names which are wrapped
onto the next line due to a long return type is controlled by the
style option `IndentWrappedFunctionNames`.
This diff changes the behavior so we always indent wrapped Objective-C
selector names.
NOTE: I partially reverted 6159c0fbd1 / rL242484, as it was causing wrapped selectors to be double-indented. Its tests in FormatTestObjC.cpp still pass.
Test Plan: Tests updated. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, stephanemoore, thakis
Reviewed By: djasper
Subscribers: stephanemoore, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45004
llvm-svn: 329916
Summary:
This patch adds two new diagnostics, which are off by default:
**-Wreturn-std-move**
This diagnostic is enabled by `-Wreturn-std-move`, `-Wmove`, or `-Wall`.
Diagnose cases of `return x` or `throw x`, where `x` is the name of a local variable or parameter, in which a copy operation is performed when a move operation would have been available. The user probably expected a move, but they're not getting a move, perhaps because the type of "x" is different from the return type of the function.
A place where this comes up in the wild is `stdext::inplace_function<Sig, N>` which implements conversion via a conversion operator rather than a converting constructor; see https://github.com/WG21-SG14/SG14/issues/125#issue-297201412
Another place where this has come up in the wild, but where the fix ended up being different, was
try { ... } catch (ExceptionType ex) {
throw ex;
}
where the appropriate fix in that case was to replace `throw ex;` with `throw;`, and incidentally to catch by reference instead of by value. (But one could contrive a scenario where the slicing was intentional, in which case throw-by-move would have been the appropriate fix after all.)
Another example (intentional slicing to a base class) is dissected in https://github.com/accuBayArea/Slides/blob/master/slides/2018-03-07.pdf
**-Wreturn-std-move-in-c++11**
This diagnostic is enabled only by the exact spelling `-Wreturn-std-move-in-c++11`.
Diagnose cases of "return x;" or "throw x;" which in this version of Clang *do* produce moves, but which prior to Clang 3.9 / GCC 5.1 produced copies instead. This is useful in codebases which care about portability to those older compilers.
The name "-in-c++11" is not technically correct; what caused the version-to-version change in behavior here was actually CWG 1579, not C++14. I think it's likely that codebases that need portability to GCC 4.9-and-earlier may understand "C++11" as a colloquialism for "older compilers." The wording of this diagnostic is based on feedback from @rsmith.
**Discussion**
Notice that this patch is kind of a negative-space version of Richard Trieu's `-Wpessimizing-move`. That diagnostic warns about cases of `return std::move(x)` that should be `return x` for speed. These diagnostics warn about cases of `return x` that should be `return std::move(x)` for speed. (The two diagnostics' bailiwicks do not overlap: we don't have to worry about a `return` statement flipping between the two states indefinitely.)
I propose to write a paper for San Diego that would relax the implicit-move rules so that in C++2a the user //would// see the moves they expect, and the diagnostic could be re-worded in a later version of Clang to suggest explicit `std::move` only "in C++17 and earlier." But in the meantime (and/or forever if that proposal is not well received), this diagnostic will be useful to detect accidental copy operations.
Reviewers: rtrieu, rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, Rakete1111, rsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43322
Patch by Arthur O'Dwyer.
llvm-svn: 329914
Summary:
Protocols that were being referenced but could not be fully realized were being emitted without `properties`/`optional_properties`. Since all v3 protocols must be 9 processor words wide, the lack of these fields is catastrophic for the runtime.
As an example, the runtime cannot know [here](https://github.com/gnustep/libobjc2/blob/master/protocol.c#L73) that `properties` and `optional_properties` are invalid.
Reviewers: rjmccall, theraven
Reviewed By: rjmccall, theraven
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D45305
llvm-svn: 329882
type.
Copy the code in ActOnStartOfFunctionDef that checks a function's return
type to ActOnStartOfObjCMethodDef. This fixes an assertion failure in
IRGen caused by an uninstantiated return type.
rdar://problem/38691818
llvm-svn: 329879
The order of argument construction is reversed on MS ABI on Windows.
When `macros` was invoked, the `end` call is made prior to `begin`. In
such a case, the DenseMap (`ModuleMap`) is populated after the `end`
iterator is constructed. This reversal results in the invalidation of
the end iterator, resulting in a failure at runtime (assertion failure
in `DenseMap<T>::operator!=` that "handles are not in sync!"). Ensure
that the end iterator is constructed after the begin iterator. This
fixes the use of `macros(bool)`, which symptomized as an assertion
failure in the swift compiler in the clang importer.
llvm-svn: 329866
The WBNOINVD instruction writes back all modified
cache lines in the processor’s internal cache to main memory
but does not invalidate (flush) the internal caches.
Reviewers: craig.topper, zvi, ashlykov
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D43817
llvm-svn: 329848
When we enter a __finally block, the CGF's CurCodeDecl will be null
(because CodeGenFunction::StartFunction is given an empty GlobalDecl for
a __finally block), and so the dyn_cast here will result in an assertion
failure. Change it to dyn_cast_or_null to handle this case.
Differential Revision: https://reviews.llvm.org/D45523
llvm-svn: 329836
When NVPTX TARGET_BUILTIN specifies sm_XX or ptxYY as required feature,
consider those features available if we're compiling for GPU >= sm_XX or have
enabled PTX version >= ptxYY.
Differential Revision: https://reviews.llvm.org/D45061
llvm-svn: 329829
Summary:
After a remark on a FreeBSD mailing list that the clang man page did
not have any list of possible values for the `-std=` flag, I have now
attempted to exhaustively list those, for each available language.
I also documented the default standard for each language, if there was
more than one choice.
Reviewers: rsmith, dexonsmith, sylvestre.ledru, mgorny
Reviewed By: rsmith
Subscribers: fhahn, emaste, cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D45406
llvm-svn: 329827
Sometimes when people compile bpf programs with
"clang ... -target bpf ...", the kernel header
files may contain host arch inline assembly codes
as in the patch https://patchwork.kernel.org/patch/10119683/
by Arnaldo Carvaldo de Melo.
The current workaround in the above patch
is to guard the inline assembly with "#ifndef __BPF__"
marco. So when __BPF__ is defined, these macros will
have no use.
Such a method is not extensible. As a matter of fact,
most of these inline assembly codes will be thrown away
at the end of clang compilation.
So for bpf target, this patch accepts all asm register
names in clang AST stage. The name will be checked
again during llc code generation if the inline assembly
code is indeed for bpf programs.
With this patch, the above "#ifndef __BPF__" is not needed
any more in https://patchwork.kernel.org/patch/10119683/.
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 329823
Previously, we would format:
int a() { ... }
[[unused]] int b() { ... }
as...
int a() {} [[unused] int b() {}
Now we correctly format each on its own line.
Similarly, we would detect:
[[unused]] int b() { return 42; }
As a lambda and leave it on a single line, even if that was disallowed
by the format style.
llvm-svn: 329816
C++ [over.built] p4:
"For every pair (T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exist candidate operator functions of the form
VQ T& operator--(VQ T&);
T operator--(VQ T&, int);
"
The bool type is in position LastPromotedIntegralType in BuiltinOperatorOverloadBuilder::getArithmeticType::ArithmeticTypes, but addPlusPlusMinusMinusArithmeticOverloads() was expecting it at position 0.
Differential Revision: https://reviews.llvm.org/D44988
rdar://problem/34255516
llvm-svn: 329804
Summary:
"-std c++11" is not valid in compiler, we have to use "-std=c++11".
Test in vscode with this patch, code completion for header works as expected.
Reviewers: sammccall
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D45512
llvm-svn: 329786
Avoid storing duplicated "std::string"s.
clangd's global-symbol-builder takes 20+GB memory running across LLVM
repository. With this patch, the used memory is ~10GB (running on 48
threads, most of meory are AST-related).
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45479
llvm-svn: 329784
Since the range-based constraint manager (default) is weak in handling comparisons where symbols are on both sides it is wise to rearrange them to have symbols only on the left side. Thus e.g. A + n >= B + m becomes A - B >= m - n which enables the constraint manager to store a range m - n .. MAX_VALUE for the symbolic expression A - B. This can be used later to check whether e.g. A + k == B + l can be true, which is also rearranged to A - B == l - k so the constraint manager can check whether l - k is in the range (thus greater than or equal to m - n).
The restriction in this version is the the rearrangement happens only if both the symbols and the concrete integers are within the range [min/4 .. max/4] where min and max are the minimal and maximal values of their type.
The rearrangement is not enabled by default. It has to be enabled by using -analyzer-config aggressive-relational-comparison-simplification=true.
Co-author of this patch is Artem Dergachev (NoQ).
Differential Revision: https://reviews.llvm.org/D41938
llvm-svn: 329780
Summary:
This patch implements the `-fxray-modes=` flag which allows users
building with XRay instrumentation to decide which modes to pre-package
into the binary being linked. The default is the status quo, which will
link all the available modes.
For this to work we're also breaking apart the mode implementations
(xray-fdr and xray-basic) from the main xray runtime. This gives more
granular control of which modes are pre-packaged, and picked from
clang's invocation.
This fixes llvm.org/PR37066.
Note that in the future, we may change the default for clang to only
contain the profiling implementation under development in D44620, when
that implementation is ready.
Reviewers: echristo, eizan, chandlerc
Reviewed By: echristo
Subscribers: mgorny, mgrang, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D45474
llvm-svn: 329772
Dean Michael Berris