| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Clang was creating a DerivedToBase ImplicitCastExpr that was also
casting between address spaces as part of the second step in the
standard conversion sequence. Defer the address space conversion to
the third step in the sequence instead, such that we get a separate
ImplicitCastExpr for the address space conversion.
Differential Revision: https://reviews.llvm.org/D70605
|
| |
|
|
|
|
|
|
|
|
|
| |
When throwing objects with deleted copy constructors, the copy ctor
field of the catchable type should remain null and the mangle name
changes. This already worked in simple cases, but in cases involving
non-trivial subobjects, sometimes LookupCopyingConstructor could return
a non-null but deleted constructor decl. Skip those and don't reference
them.
Fixes PR43680
|
| |
|
|
|
|
|
|
|
|
|
| |
See also: D67515
- For the given call expression we would end up repeatedly
trying to transform the same expression over and over again
- Fix is to keep the old TransformCache when checking for ambiguity
Differential Revision: https://reviews.llvm.org/D69060
|
| |
|
|
| |
to the ambiguity, rather than noting all viable candidates.
|
| |
|
|
|
|
|
|
|
|
| |
This fixes an assertion failure in the case where an implicit conversion for a
function call involves an lvalue function conversion, and makes the AST for
initializations involving implicit lvalue function conversions more accurate.
Differential Revision: https://reviews.llvm.org/D66437
llvm-svn: 375313
|
| |
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 375101
|
| |
|
|
|
|
| |
__is_*_assignable(volatile T&, U).
llvm-svn: 374580
|
| |
|
|
|
|
|
|
|
|
|
|
| |
whose value is not ignored.
We don't warn on all the cases that are deprecated: specifically, we
choose to not warn for now if there are parentheses around the
assignment but its value is not actually used. This seems like a more
defensible rule, particularly for cases like sizeof(v = a), where the
parens are part of the operand rather than the sizeof syntax.
llvm-svn: 374135
|
| |
|
|
|
|
|
|
|
| |
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.
llvm-svn: 373685
|
| |
|
|
|
|
|
|
|
|
| |
of 'typeid'.
This is a rare place where it's valid for a function type to be
substituted but not valid for a qualified function type to be
substituted, so needs a special check.
llvm-svn: 373648
|
| |
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us.
llvm-svn: 373584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch fixes the __is_signed builtin type trait to work with floating point types and enums. Now, the builtin will return true if it is passed a floating point type and false for an enum type.
Reviewers: EricWF, rsmith, erichkeane, craig.topper, efriedma
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67897
llvm-svn: 372621
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a bug introduced in D62648, where Clang could infinite loop
if it became stuck on a single TypoCorrection when it was supposed to
be testing ambiguous corrections. Although not a common case, it could
happen if there are multiple possible corrections with the same edit
distance.
The fix is simply to wipe the TypoExpr from the `TransformCache` so that
the call to `TransformTypoExpr` doesn't use the `CachedEntry`.
Reviewers: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67515
llvm-svn: 371859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As Typo Resolution can create new TypoExprs while resolving typos,
it is necessary to recurse through the expression to search for more
typos.
This should fix the assertion failure in `clang::Sema::~Sema()`:
`DelayedTypos.empty() && "Uncorrected typos!"`
Notes:
- In case some TypoExprs are created but thrown away, Sema
now has a Vector that is used to keep track of newly created
typos.
- For expressions with multiple typos, we only give suggestions
if we are able to resolve all typos in the expression
- This patch is similar to D37521 except that it does not eagerly
commit to a correction for the first typo in the expression.
Instead, it will search for corrections which fix all of the
typos in the expression.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62648
llvm-svn: 369427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When handling a member access into a non-class, non-ObjC-object type, we
would perform a lookup into the surrounding scope as if for an
unqualified lookup. If the member access was followed by a '<' and this
lookup (or the typo-correction for it) found a template name, we'd treat
the member access as naming that template.
Now we treat such accesses as never naming a template if the type of the
object expression is of vector type, so that vector component accesses
are never misinterpreted as naming something else. This is not entirely
correct, since it is in fact valid to name a template from the enclosing
scope in this context, when invoking a pseudo-destructor for the vector
type via an alias template, but that's very much a corner case, and this
change leaves that case only as broken as the corresponding case for
Objective-C types is.
This incidentally adds support for dr2292, which permits a 'template'
keyword at the start of a member access naming a pseudo-destructor.
llvm-svn: 368940
|
| |
|
|
| |
llvm-svn: 366823
|
| |
|
|
|
|
|
|
|
| |
Clang doesn't implement OpenCL C++, change the comments to
reflect that.
Differential Revision: https://reviews.llvm.org/D64867
llvm-svn: 366421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Simplify code a bit and add assertion to address post-landing comments
from D64083.
Subscribers: yaxunl, Anastasia, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64804
llvm-svn: 366306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:
$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
-DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
-DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
-config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}
llvm-svn: 366177
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch ensures that the following code is compiled identically with
-cl-std=CL2.0 and -fblocks -cl-std=c++.
kernel void test(void) {
void (^const block_A)(void) = ^{
return;
};
}
A new test is not added because cl20-device-side-enqueue.cl will cover
this once blocks are further improved for C++ for OpenCL.
The changes to Sema::PerformImplicitConversion are based on
the parts of Sema::CheckAssignmentConstraints on block pointer
conversions.
Reviewers: rjmccall, Anastasia
Subscribers: yaxunl, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64083
llvm-svn: 365500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
spurious `-Warc-repeated-use-of-weak` warnings
This reverts r365382 (git commit 8b1becf2e31d9170ee356a19c7b6ea991d3a520f)
Appears to regress this semi-reduced fragment of valid code from windows
SDK headers:
#define InterlockedIncrement64 _InterlockedIncrement64
extern "C" __int64 InterlockedIncrement64(__int64 volatile *Addend);
#pragma intrinsic(_InterlockedIncrement64)
unsigned __int64 InterlockedIncrement(unsigned __int64 volatile *Addend) {
return (unsigned __int64)(InterlockedIncrement64)((volatile __int64 *)Addend);
}
Found on a buildbot here, but no mail was sent due to it already being
red:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48067
llvm-svn: 365393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
spurious `-Warc-repeated-use-of-weak` warnings
The spurious -Warc-repeated-use-of-weak warnings are issued when an
initializer expression uses a weak ObjC pointer.
My first attempt to silence the warnings (r350917) caused clang to
reject code that is legal in C++17. The patch is based on the feedback I
received from Richard when the patch was reverted.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268945.html
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268943.html
Differential Revision: https://reviews.llvm.org/D62645
llvm-svn: 365382
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Without an explicit declaration for placement new, clang would reject
uses of placement new with "'default new' is not supported in OpenCL
C++". This may mislead users into thinking that placement new is not
supported, see e.g. PR42060.
Clarify that placement new requires an explicit declaration.
Differential Revision: https://reviews.llvm.org/D63561
llvm-svn: 364423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
this is a bugfixe for [[ https://bugs.llvm.org/show_bug.cgi?id=41400 | PR41400 ]]
added nullptr check at the relevent place and test
Reviewers: rsmith, riccibruno
Reviewed By: rsmith
Subscribers: jkooker, jkorous, riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60523
llvm-svn: 363360
|
| |
|
|
|
|
|
| |
Begin restructuring to support the forms of non-odr-use reference
permitted by DR712.
llvm-svn: 363086
|
| |
|
|
|
|
|
|
| |
referenced.
This reinstates r362563, reverted in r362597.
llvm-svn: 362757
|
| |
|
|
|
|
|
|
|
|
| |
most / all other Expr subclasses.
This reinstates r362551, reverted in r362597, with a fix to a bug that
caused MemberExprs to sometimes have a null FoundDecl after a round-trip
through an AST file.
llvm-svn: 362756
|
| |
|
|
|
|
|
|
| |
"Convert MemberExpr creation and serialization to work the same way as"
This reverts commits r362551 and r362563. Crashes during modules selfhost.
llvm-svn: 362597
|
| |
|
|
|
|
| |
referenced.
llvm-svn: 362563
|
| |
|
|
|
|
| |
most / all other Expr subclasses.
llvm-svn: 362551
|
| |
|
|
| |
llvm-svn: 362537
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packs.
Two changes:
* Track odr-use via FunctionParmPackExprs to properly handle dependent
odr-uses of packs in generic lambdas.
* Do not instantiate implicit captures; instead, regenerate them by
instantiating the body of the lambda. This is necessary to
distinguish between cases where only one element of a pack is
captured and cases where the entire pack is captured.
This reinstates r362358 (reverted in r362375) with a fix for an
uninitialized variable use in UpdateMarkingForLValueToRValue.
llvm-svn: 362531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
capture packs.
Two changes:
* Track odr-use via FunctionParmPackExprs to properly handle dependent
odr-uses of packs in generic lambdas.
* Do not instantiate implicit captures; instead, regenerate them by
instantiating the body of the lambda. This is necessary to
distinguish between cases where only one element of a pack is
captured and cases where the entire pack is captured.
........
Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures
llvm-svn: 362375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
packs.
Two changes:
* Track odr-use via FunctionParmPackExprs to properly handle dependent
odr-uses of packs in generic lambdas.
* Do not instantiate implicit captures; instead, regenerate them by
instantiating the body of the lambda. This is necessary to
distinguish between cases where only one element of a pack is
captured and cases where the entire pack is captured.
llvm-svn: 362358
|
| |
|
|
|
|
|
|
|
|
| |
and returned to the context in which 'this' should be captured.
This means we now always mark 'this' referenced from the context in
which it's actually referenced, rather than potentially from some
context nested within that.
llvm-svn: 362182
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became
clear that the current mechanism of hacking through checks for the
exception specification of a function gets confused really quickly when
there are alternate exception specifiers.
This patch introcues EST_NoThrow, which is the equivilent of
EST_noexcept when caused by EST_noThrow. The existing implementation is
left in place to cover functions with no FunctionProtoType.
Differential Revision: https://reviews.llvm.org/D62435
llvm-svn: 362119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
capturing expression or statement.
No functionality change yet. The intent is that we will also delay
building the initialization expression until the enclosing context, so
that:
a) we build the initialization expression in the right context, and
b) we can elide captures that are not odr-used, as suggested by P0588R1.
This also consolidates some duplicated code building capture fields into
a single place.
llvm-svn: 361893
|
| |
|
|
|
|
|
|
| |
code.
No functional change intended.
llvm-svn: 361890
|
| |
|
|
|
|
| |
referenced.
llvm-svn: 361588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r355317 changed builtins/allocation functions to use the default calling
convention in order to support platforms that use non-cdecl calling
conventions by default.
However the default calling convention is overridable on Windows 32 bit
implementations with some of the /G options. The intent is to permit the
user to set the calling convention of normal functions, however it
should NOT apply to builtins and C++ allocation functions.
This patch ensures that the builtin/allocation functions always use the
Target specific Calling Convention, ignoring the user overridden version
of said default.
llvm-svn: 361507
|
| |
|
|
| |
llvm-svn: 360614
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a crash where we would neglect to mark a destructor referenced for an
__attribute__((no_destory)) array. The destructor is needed though, since if an
exception is thrown we need to cleanup the elements.
rdar://48462498
Differential revision: https://reviews.llvm.org/D61165
llvm-svn: 360446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Darwin if the version of libc++abi isn't new enough to include the fix
in r319123
This patch resurrects r264998, which was committed to work around a bug
in libc++abi that was causing _cxa_allocate_exception to return a memory
that wasn't double-word aligned.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160328/154332.html
In addition, this patch makes clang issue a warning if the type of the
thrown object requires an alignment that is larger than the minimum
guaranteed by the target C++ runtime.
rdar://problem/49864414
Differential Revision: https://reviews.llvm.org/D61667
llvm-svn: 360404
|
| |
|
|
|
|
| |
left-hand side of an -> operator is a pointer to class type.
llvm-svn: 360387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template name is not visible to unqualified lookup.
In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.
Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.
The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.
llvm-svn: 360308
|
| |
|
|
|
|
|
|
|
|
| |
new expression.
This was voted into C++20 as a defect report resolution, so we
retroactively apply it to all prior language modes (though it can never
actually be used before C++11 mode).
llvm-svn: 360006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostics emitted (or suppressed) during completion don't interfere with the overload notes
Because diagnostics and their notes are not connected at the API level,
if the error message for an overload is emitted, then the overload
candidates are completed - if a diagnostic is emitted during that work,
the notes related to overload candidates would be attached to the latter
diagnostic, not the original error. Sort of worse, if the latter
diagnostic was disabled, the notes are disabled.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D61357
llvm-svn: 359854
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of an auto"
This commit changed the initializer expression passed into
initialization (stripping off an enclosing pair of parentheses or
braces) and subtly changing the meaning of programs, typically by
inserting bogus calls to copy constructors.
See the added testcase in test/SemaCXX/cxx1y-init-captures.cpp for an
example of the breakage.
llvm-svn: 359066
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
llvm.org/PR40991
rdar://48564179
Differential revision: https://reviews.llvm.org/D59394
llvm-svn: 356599
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On SPIR targets, the default calling convention is SpirFunction.
However, operator new/delete and builtins were being created with CC_C.
The result is indirect references to new/delete (or builtins that are permitted
to be called indirectly have a mismatched type, as well as questionable codegen
in some cases.
This patch sets both to the default calling convention, so that it
properly matches the calling convention of the target.
Differential Revision: https://reviews.llvm.org/D58844
Change-Id: I52065bb00bc2655945caea8f29c409ba1e0ac24a
llvm-svn: 355317
|