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
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
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: 373474
r368237 attempted to improve fix-its for move warnings, but introduced some
regressions to -Wpessimizing-move. Revert that change and add the missing
test cases to the pessimizing move test to prevent future regressions.
llvm-svn: 373421
Reland after https://reviews.llvm.org/D66806 fixed the false-positive diagnostics.
Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)
inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).
and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).
We now add the attributes to all redeclarations to fix thos issues and make their usage easier.
Reviewers: gribozavr
Subscribers: Szelethus, xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66179
llvm-svn: 371182
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
We failed to correctly handle the 'holes' left behind by designated
initializers in VerifyOnly mode. This would result in us thinking that a
designated initialization would be valid, only to find that it is not
actually valid when we come to build it. In a +Asserts build, that would
assert, and in a -Asserts build, that would silently lose some part of
the initialization or crash.
With this change, when an InitListExpr contains any designators, we now
always build a structured list so that we can track the locations of the
'holes' that we need to go back and fill in.
We could in principle do better: we only need the structured form if
there is a designator that jumps backwards (and can otherwise check for
the holes as we progress through the initializer list), but dealing with
that turns out to be rather complicated, so it's not done as part of
this patch.
llvm-svn: 370419
list, rather than recursively checking multiple lists in C.
This simplification is in preparation for making InitListChecker
maintain more state that's specific to the explicit initializer list,
particularly when handling designated initialization.
llvm-svn: 370418
set to true in VerifyOnly mode in cases where it's also set to true when
actually building the initializer list.
Add FIXMEs for the two cases where that's not true. No functionality
change intended.
llvm-svn: 370417
Summary:
Clang performs various recursive operations (such as template instantiation),
and may use non-trivial amounts of stack space in each recursive step (for
instance, due to recursive AST walks). While we try to keep the stack space
used by such steps to a minimum and we have explicit limits on the number of
such steps we perform, it's impractical to guarantee that we won't blow out the
stack on deeply recursive template instantiations on complex ASTs, even with
only a moderately high instantiation depth limit.
The user experience in these cases is generally terrible: we crash with
no hint of what went wrong. Under this patch, we attempt to do better:
* Detect when the stack is nearly exhausted, and produce a warning with a
nice template instantiation backtrace, telling the user that we might
run slowly or crash.
* For cases where we're forced to trigger recursive template
instantiation in arbitrarily-deeply-nested contexts, check whether
we're nearly out of stack space and allocate a new stack (by spawning
a new thread) after producing the warning.
Reviewers: rnk, aaron.ballman
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66361
llvm-svn: 369940
This reverts commit r369591, because it causes the formerly-reliable
-Wreturn-stack-address warning to start issuing false positives.
Testcase provided on the commit thread.
llvm-svn: 369677
Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)
inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).
and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).
We now add the attributes to all redeclarations to fix thos issues and make their usage easier.
Reviewers: gribozavr
Subscribers: Szelethus, xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66179
llvm-svn: 369591
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
The sampler handling logic in SemaInit.cpp would inadvertently treat
parentheses around sampler arguments as an implicit cast, leading to
an unreachable "can't implicitly cast lvalue to rvalue with
this cast kind". Fix by ignoring parentheses once we are in the
sampler initializer case.
Differential Revision: https://reviews.llvm.org/D66080
llvm-svn: 368561
Fix -Wpessimizing-move and -Wredundant-move when warning on initializer lists.
The new fix-it hints for removing the std::move call will now also suggest
removing the braces for the initializer list so that the resulting code will
still be compilable.
This fixes PR42832
llvm-svn: 368237
This patch extends some existing warnings to utilize the knowledge about the gsl::Pointer and gsl::Owner attributes.
Differential Revision: https://reviews.llvm.org/D64256
llvm-svn: 368072
If we construct an object in some arbitrary non-default addr space
it should fail unless either:
- There is an implicit conversion from the address space to default
/generic address space.
- There is a matching ctor qualified with an address space that is
either exactly matching or convertible to the address space of an
object.
Differential Revision: https://reviews.llvm.org/D62156
llvm-svn: 363944
In addition to being unused and duplicating code, this was also wrong
(it didn't properly mark the operand as being potentially not odr-used).
This reinstates r363340, reverted in r363352.
llvm-svn: 363430
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
This reinstates r363337, reverted in r363352.
llvm-svn: 363429
Revert 363340 "Remove unused SK_LValueToRValue initialization step."
Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type"
Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression."
llvm-svn: 363352
In addition to being unused and duplicating code, this was also wrong
(it didn't properly mark the operand as being potentially not odr-used).
llvm-svn: 363340
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
This reinstates r345562, reverted in r346065, now that CodeGen's
handling of non-odr-used variables has been fixed.
llvm-svn: 363337
References to arbitrary address spaces can't always be bound to
temporaries. This change extends the reference binding logic to
check that the address space of a temporary can be implicitly
converted to the address space in a reference when temporary
materialization is performed.
Differential Revision: https://reviews.llvm.org/D61318
llvm-svn: 362604
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
Richard Smith