Summary:
The "previous definition is here" note is not helpful if there is no location information. The note will reference nothing in such a case. This patch first checks to see if there is location data, and if so the note diagnostic is emitted.
This fixes PR15409. The issue in the first comment seems to already be resolved. This patch addresses the second example.
Reviewers: bruno, rsmith
Reviewed By: bruno
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44901
llvm-svn: 328712
When the declare target variables are emitted for the device,
constructors|destructors for these variables must emitted and registered
by the runtime in the offloading sections.
llvm-svn: 328705
Summary:
This patch doing more check and verify the -march= string and will issue
an error if it's a invalid combination.
Reviewers: asb, apazos
Differential Revision: https://reviews.llvm.org/D44189
Patch by Kito Cheng.
llvm-svn: 328690
The diagnostic system for Clang can already handle many AST nodes. Instead
of converting them to strings first, just hand the AST node directly to
the diagnostic system and let it handle the output. Minor changes in some
diagnostic output.
llvm-svn: 328688
structs.
r326307 and r327870 made changes that allowed using non-trivial C
structs with fields qualified with __strong or __weak. This commit makes
the following C++ triviality type traits available to non-trivial C
structs:
__has_trivial_assign
__has_trivial_move_assign
__has_trivial_copy
__has_trivial_move_constructor
__has_trivial_constructor
__has_trivial_destructor
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44913
llvm-svn: 328680
When SemaCoroutine looks for await_resume, it means it. No need for helpful: "Did you mean await_ready?" messages.
Fixes PR33477 and a couple of FIXMEs in test/SemaCXX/coroutines.cpp
llvm-svn: 328663
When we have a category implementation without a corresponding interface
(which is an error by itself), semantic checks for property accesses
will attempt to access a null interface declaration and then segfault.
Error out in such cases instead.
Differential Revision: https://reviews.llvm.org/D44916
llvm-svn: 328654
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
llvm-svn: 328636
Summary:
This fixes an issue brought up by djasper@ in his review of D44790. We
handled top-level child lines, but if those child lines themselves
had child lines, we didn't handle them.
Rather than use recursion (which could blow out the stack), I use a
DenseSet to hold the set of lines we haven't yet checked (since order
doesn't matter), and update the set to add the children of each
line as we check it.
Test Plan: New tests added. Confirmed tests failed before fix
and passed after fix.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44831
llvm-svn: 328628
Summary:
Previously, `clang-format` would sometimes insert a space
before the closing brace in an Objective-C dictionary literal.
Unlike array literals (which obey `Style.SpacesInContainerLiterals`
to add a space after `[` and before `]`), Objective-C dictionary
literals currently are not meant to insert a space after `{` and before
`}`, regardless of `Style.SpacesInContainerLiterals`.
However, some constructs like `@{foo : @(bar)}` caused `clang-format`
to insert a space between `)` and `}`.
This fixes the issue and adds tests. (I understand the behavior is
not consistent between array literals and dictionary literals, but
that's existing behavior that's a much larger change.)
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, Wizard
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44816
llvm-svn: 328627
Extended the matched assignment operators when checking for bound changes in a body of the loop by using the freshly added isAssignmentOperator matcher.
This covers all the (current) possible assignments, tests added as well.
Differential Revision: https://reviews.llvm.org/D38921
llvm-svn: 328619
Adding a matcher for BinaryOperator and cxxOperatorCallExpr to be able to
decide whether it is any kind of assignment operator or not. This would be
useful since allows us to easily detect assignments via matchers for static
analysis (Tidy, SA) purposes.
Differential Revision: https://reviews.llvm.org/D44893
llvm-svn: 328618
Summary:
Currently an invalid source range is generated for the member call expressions of `co_await`. The end location of the call expression is the `co_await` token loc, while the start is the location of the operand. This causes crashes when the source range is used to produce diagnostics.
This patch fixes the issues by using the expression location instead of the token location when building the member calls.
Reviewers: GorNishanov, rsmith, vsk, aaron.ballman
Reviewed By: vsk
Subscribers: cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D44915
llvm-svn: 328606
Previously, anytime the result of the resume expression in
operator co_await was unused, a warning was generated. This
patch fixes the issue by only generating the unused result warning
if calling `await_resume()` would also generate a warning.
llvm-svn: 328602
Summary:
This fixes PR33561 and PR34185.
Don't store pending template instantiations for late-parsed templates in
the normal PendingInstantiations queue. Instead, use a separate list
that will only be parsed and instantiated at end of TU when late
template parsing actually works and doesn't infinite loop.
Reviewers: rsmith, thakis, hans
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44846
llvm-svn: 328567
Summary:
r318093 sets fma, fmaf, fmal as const for Gnu and MSVC. Android also
does not set errno for these functions. So mark these const for
Android.
Reviewers: spatel, efriedma, srhines, chh, enh
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D44852
llvm-svn: 328552
If the link clause is used on the declare target directive, the object
should be linked on target or target data directives, not during the
codegen. Patch adds support for this clause.
llvm-svn: 328544
Declaring "_Pragma("clang optimize off")" before the body of a
function with a lambda leads to the lambda functions in the body
not being affected.
Differential Revision: https://reviews.llvm.org/D43821
llvm-svn: 328494
Summary:
As the title says, this makes following code compile:
```
template<typename> struct Foo {};
Foo() -> Foo<void>;
Foo f; // ok
```
Thanks Nicolas Lesser for coining the fix.
Reviewers: rsmith, lichray
Reviewed By: rsmith, lichray
Subscribers: lichray, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38216
llvm-svn: 328409
Summary:
Disables certain CMP optimizations to improve fuzzing signal under -O1
and -O2.
Switches all fuzzer tests to -O2 except for a few leak tests where the
leak is optimized out under -O2.
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D44798
llvm-svn: 328384
Launching a kernel from the host code does not generate code for the
kernel itself. This fixes an issue with clang erroneously reporting
an error for a HD->D call from within the kernel.
Differential Revision: https://reviews.llvm.org/D44837
llvm-svn: 328362
Summary: Porting HWASan to Linux x86-64, the third of the three patches, clang part.
Reviewers: eugenis
Subscribers: cryptoad, cfe-commits
Differential Revision: https://reviews.llvm.org/D44745
llvm-svn: 328361
Need to override convertConstraint to recognise amdgpu specific register names.
Differential Revision: https://reviews.llvm.org/D44533
llvm-svn: 328359
Add two additional implicit arguments for OpenCL for the AMDGPU target using the AMDHSA runtime to support device enqueue.
Differential Revision: https://reviews.llvm.org/D44696
llvm-svn: 328350
- Remove use of the opencl and amdopencl environment member of the target triple for the AMDGPU target.
- Use a function attribute to communicate to the AMDGPU backend.
Differential Revision: https://reviews.llvm.org/D43735
llvm-svn: 328347
This make -ivfsoverlay behave more like other fatal errors (e.g. missing
-include file) by skipping the missing file instead of bailing out of
the whole compilation. This makes it possible for libclang to still
provide some functionallity as well as to correctly produce the fatal
error diagnostic (previously we lost the diagnostic in libclang since
there was no TU to tie it to).
rdar://33385423
llvm-svn: 328337
The issues was that we were setting hidden visibility if, when
processing a hidden class, we found out that we needed to emit a
reference to a vtable provided by the standard library.
Original message:
Set dso_local on vtables.
llvm-svn: 328288
I'm not sure /why/ this is causing issues for libclang, but it is.
Unbreak the buildbots since it's already consumed an hour of my time.
llvm-svn: 328286
Changes the analyzer to believe that methods annotated with _Nonnull
from system frameworks indeed return non null objects.
Local methods with such annotation are still distrusted.
rdar://24291919
Differential Revision: https://reviews.llvm.org/D44341
llvm-svn: 328282
Current location is very confusing, especially because there is already
WorkList.h, and other code in CoreEngine.cpp is not related to work list
implementation.
Differential Revision: https://reviews.llvm.org/D44759
llvm-svn: 328280
Putting back the code in commit r327189 that was reverted in r322737. The code is being committed in three stages and this one is the last stage: 1) r327455 fp16 feature flags, 2) r327836 pass half type or i16 based on FullFP16, and 3) the code here which the front-end fp16 vector intrinsic for ARM.
Differential revision https://reviews.llvm.org/D43650
llvm-svn: 328277
When a temporary is constructed with a proper construction context, it should
be safe to inline the destructor. We have added suppressions for some of the
common false positives caused by such inlining, so there should be - and from my
observations there indeed is - more benefit than harm from enabling destructor
inlining.
Differential Revision: https://reviews.llvm.org/D44721
llvm-svn: 328258
CXXCtorInitializer-based constructors are also affected by the C++17 mandatory
copy elision, like variable constructors and return value constructors.
Extend r328248 to support those.
Differential Revision: https://reviews.llvm.org/D44763
llvm-svn: 328255
Function return values can be constructed directly in variables or passed
directly into return statements, without even an elidable copy in between.
This is how the C++17 mandatory copy elision AST behaves. The behavior we'll
have in such cases is the "old" behavior that we've had before we've
implemented destructor inlining and proper lifetime extension support.
Differential Revision: https://reviews.llvm.org/D44755
llvm-svn: 328253
David Blaikie