Commit Graph

4897 Commits

Author SHA1 Message Date
Richard Smith 7bf8f6fa8a PR42104: Support instantiations of lambdas that implicitly 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.

This reinstates r362358 (reverted in r362375) with a fix for an
uninitialized variable use in UpdateMarkingForLValueToRValue.

llvm-svn: 362531
2019-06-04 17:17:20 +00:00
Erich Keane dd0adae65a Fix test failure from r362435
Apparently I forgot to do an open brace in a namespace, so we get an
error about an extra closing brace.

llvm-svn: 362443
2019-06-03 19:57:52 +00:00
Erich Keane bf37536a35 Make NoThrow FunctionLike, make FunctionLike include references, fix
prettyprint

__declspec(nothrow) should work on function pointers as well as function
references, so this changes it to FunctionLike.  Additionally,
FunctionLike needed to be modified to permit function references.

Finally, the TypePrinter didn't properly print the NoThrow exception
specifier, so make sure we get that right as well.

llvm-svn: 362435
2019-06-03 18:36:33 +00:00
Erich Keane 81ef625080 Permit Exception Spec mismatch with NoThrow on inherited Virtual
As reported here: https://bugs.llvm.org/show_bug.cgi?id=42100

This fairly common pattern ends up being an error in MinGW, so relax it
in all cases to a warning.

llvm-svn: 362434
2019-06-03 18:36:26 +00:00
Simon Pilgrim c716e5d6de Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly 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
2019-06-03 09:56:09 +00:00
Richard Smith ea0c66be55 PR42104: Support instantiations of lambdas that implicitly 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.

llvm-svn: 362358
2019-06-03 06:02:10 +00:00
Brian Gesiak 38f11825d1 [coroutines][PR41909] Don't build dependent coroutine statements for generic lambda
Summary:
https://bugs.llvm.org/show_bug.cgi?id=41909 describes an issue in which
a generic lambda that takes a dependent argument `auto set` causes the
template instantiation machinery for coroutine body statements to crash
with an ICE. The issue is two-fold:

1. The paths taken by the template instantiator contain several asserts
   that the coroutine promise must not have a dependent type.
2. The template instantiator unconditionally builds corotuine statements
   that depend on the promise type, which cannot be dependent.

To work around the issue, prevent the template instantiator from building
dependent coroutine statements if the coroutine promise type is dependent.
Since we only expect this to occur in the case of a generic lambda, limit
the workaround behavior to just that case.

Reviewers: GorNishanov, EricWF, lewissbaker, tks2103

Reviewed By: GorNishanov

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62550

llvm-svn: 362348
2019-06-03 00:47:32 +00:00
Erich Keane c61762797e Suppress nothrow/Exception spec conflict warning when we dont know the ES.
In any situation where the Exception Spec isn't clear, suppress the
warning to avoid false positives.

llvm-svn: 362243
2019-05-31 16:46:38 +00:00
Erich Keane 24016eb374 Suppress nothrow/exception spec conflict warning when ES is parsed.
The previously added warning ended up causing false positives when
nothrow was used on member functions, where the exception specification
wasn't yet parsed.  So, throw() and noexcept(true) both were incorrectly
warning.  There doesn't seem to be a good way to force these to be parsed
to identify which they are (and likely should not be), so suppress the warning.

For now, unevaluated/uninstantiated are left as warnings as I am not
creative enough to find a reproducer that causes a false positive for
either.

llvm-svn: 362236
2019-05-31 15:56:27 +00:00
Erich Keane 54182eb7b0 Fix for PR42089, regression from r362119
The implementation of the NoThrow ExceptionSpecificationType missed a
switch statement for forming the diagnostic when an out-of-line member
redeclaration misses the exception specification.  This patch adds the
correct case statement.

llvm-svn: 362225
2019-05-31 14:26:19 +00:00
Richard Smith dbd3ce92e6 PR39728: When completing a class, complete the destructor first.
We need to know whether the destructor is trivial in order to tell
whether other parts of the class are valid (in particular, this affects
whether the type is a literal type, which affects whether defaulted
special members can be declared constexpr or are implicitly constexpr).

llvm-svn: 362184
2019-05-31 01:25:16 +00:00
Richard Smith b5a45bb77e Defer building 'this' captures until we have left the capturing region
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
2019-05-31 01:17:04 +00:00
Erich Keane fc3dfd3e35 Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.
As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was
possible to get the constexpr version of __builtin_*_overflow to give
the wrong answer.

This was because when extending the operands to fit the largest type (so
that the math could be done), the decision on whether to sign/zero
extend the operands was based on the result signedness, not on the
operands signedness.

In the reported case, (unsigned char)255 - (int)100 needed
to have each extended to the int in order to do the math.  However, when
extending the first operand to 'int', we incorrectly sign extended it
instead of zero extending.  Thus, the result didnt fit back into the
unsigned char.

The fix for this was simply to choose zero/sign extension based on the
sign of the operand itself.

Differential Revision: https://reviews.llvm.org/D62665

llvm-svn: 362157
2019-05-30 21:35:32 +00:00
Richard Smith a481b01e95 [c++2a] Fix assertion failure if we would walk over more than one level
of derived-to-base conversion path when implicitly starting union
subobject lifetimes in constant evaluation.

llvm-svn: 362147
2019-05-30 20:45:12 +00:00
Erich Keane d02f4a1043 Add Attribute NoThrow as an Exception Specifier Type
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
2019-05-30 17:31:54 +00:00
Richard Smith 8cb63232d9 If capturing a variable fails, add a capture anyway (and mark it
invalid) so that we can avoid repeated diagnostics for the same capture.

llvm-svn: 361891
2019-05-28 23:09:44 +00:00
Richard Smith 0353e5a6cd Permit static local structured bindings to be named from arbitrary scopes inside their declaring scope.
llvm-svn: 361686
2019-05-25 01:04:17 +00:00
Richard Smith de47d66191 Default arguments are potentially constant evaluated.
We need to eagerly instantiate constexpr functions used in them even if
the default argument is never actually used, because we might evaluate
portions of it when performing semantic checks.

llvm-svn: 361670
2019-05-24 21:08:12 +00:00
Eric Fiselier ffafdb9afc Fix hang during constant evaluation of union assignment.
HandleUnionActiveMemberChange forgot to walk over a nop implicit
conversion node and got stuck in the process.

As a cleanup I changed the declaration of `E` so it can't
be accidentally accessed after the loop.

llvm-svn: 361571
2019-05-23 23:34:43 +00:00
Richard Smith 13bf9892dc Part of P1091R3: permit structured bindings to be declared 'static' and
'thread_local' in C++20.

llvm-svn: 361424
2019-05-22 19:52:55 +00:00
Richard Smith 31c69a3d63 [c++20] P1330R0: permit simple-assignments that change the active member
of a union within constant expression evaluation.

llvm-svn: 361329
2019-05-21 23:15:20 +00:00
Aaron Ballman b0573608b0 Rename identifiers to spell out analyze; NFC.
llvm-svn: 361325
2019-05-21 22:43:48 +00:00
Nicolas Lesser f53d172710 Added a better diagnostic when using the delete operator with lambdas
Summary:
This adds a new error for missing parentheses around lambdas in delete operators.

```
int main() {
  delete []() { return new int(); }();
}
```

This will result in:

```
test.cpp:2:3: error: '[]' after delete interpreted as 'delete[]'
  delete []() { return new int(); }();
  ^~~~~~~~~
test.cpp:2:9: note: add parentheses around the lambda
  delete []() { return new int(); }();
        ^
        (                          )
```

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: riccibruno, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D36357

llvm-svn: 361119
2019-05-19 15:07:58 +00:00
Richard Smith a933030f84 [c++20] P1327R1: Support for typeid applied to objects of polymorphic
class type in constant evaluation.

This reinstates r360977, reverted in r360987, now that its rerequisite
patch is reinstated and fixed.

llvm-svn: 361067
2019-05-17 19:19:28 +00:00
Nico Weber 762b3ef078 Attempt to fix test on Windows after r360998
llvm-svn: 361054
2019-05-17 17:33:54 +00:00
Richard Smith 51ce8444f0 Fix crash if, during evaluation of __builtin_object_size, we try to load
through an invalid base.

llvm-svn: 360998
2019-05-17 08:01:34 +00:00
Richard Smith ee0ce302c5 Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

This reinstates r360974, reverted in r360988, with a fix for a
static_assert failure on 32-bit builds: force Type base class to have
8-byte alignment like the rest of Clang's AST nodes.

llvm-svn: 360995
2019-05-17 07:06:46 +00:00
Chris Bieneman a971003e46 Revert Refactor constant evaluation of typeid(T) to track a symbolic type_info object rather than tracking the originating expression.
This reverts r360974 (git commit 7ee4307bd4)

llvm-svn: 360988
2019-05-17 05:46:03 +00:00
Chris Bieneman a5a4124c49 Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic class type in constant evaluation.
This reverts r360977 (git commit f51dc8d2f9)

llvm-svn: 360987
2019-05-17 05:45:57 +00:00
Richard Smith f51dc8d2f9 [c++20] P1327R1: Support for typeid applied to objects of polymorphic
class type in constant evaluation.

llvm-svn: 360977
2019-05-17 02:16:45 +00:00
Richard Smith 7ee4307bd4 Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

llvm-svn: 360974
2019-05-17 01:46:05 +00:00
Eric Fiselier 708afb56c1 Implement __builtin_LINE() et. al. to support source location capture.
Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).

With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. 

Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong

Reviewed By: rsmith

Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits

Differential Revision: https://reviews.llvm.org/D37035

llvm-svn: 360937
2019-05-16 21:04:15 +00:00
Richard Smith 7bd54ab586 [c++20] For P1327R1: support dynamic_cast in constant expression
evaluation.

llvm-svn: 360806
2019-05-15 20:22:21 +00:00
Richard Smith 921f132a0f [c++20] P1064R0: Allow virtual function calls in constant expression
evaluation.

This reinstates r360559, reverted in r360580, with a fix to avoid
crashing if evaluation-for-overflow mode encounters a virtual call on an
object of a class with a virtual base class, and to generally not try to
resolve virtual function calls to objects whose (notional) vptrs are not
readable. (The standard rules are unclear here, but this seems like a
reasonable approach.)

llvm-svn: 360635
2019-05-13 23:35:21 +00:00
Marshall Clow ce78105558 Make more friendly with unions. Reviewed as https://reviews.llvm.org/D61858
llvm-svn: 360614
2019-05-13 19:29:23 +00:00
Hans Wennborg d5fb162563 Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant expression evaluation."
This caused Chromium builds to hit the new "can't handle virtual calls with
virtual bases" assert. Reduced repro coming up.

llvm-svn: 360580
2019-05-13 13:19:09 +00:00
Richard Smith dab287b550 PR41854: Don't assert when constant-evaluating a member function call on an invalid designator.
llvm-svn: 360560
2019-05-13 07:51:29 +00:00
Richard Smith 5c5be6b2f7 [c++20] P1064R0: Allow virtual function calls in constant expression
evaluation.

llvm-svn: 360559
2019-05-13 07:42:10 +00:00
Richard Smith debad6460b Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.

This is undefined behavior per [class.cdtor]p2.

We continue to allow this for objects whose values are not visible
within the constant evaluation, because there's no way we can tell
whether the access is defined or not, existing code relies on the
ability to make such calls, and every other compiler allows such
calls.

This reinstates r360499, reverted in r360531.

llvm-svn: 360538
2019-05-12 09:39:08 +00:00
Richard Smith d3d6f4f65c Fix handling of objects under construction during constant expression
evaluation.

It's not enough to just track the LValueBase that we're evaluating, we
need to also track the path to the objects whose constructors are
running.

This reinstates r360464 (reverted in r360531) with a workaround for an
MSVC bug that previously caused the Windows bots to fail.

llvm-svn: 360537
2019-05-12 08:57:59 +00:00
Simon Pilgrim 73e8b67438 Revert rL360499 and rL360464 from cfe/trunk:
Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.

This is undefined behavior per [class.cdtor]p2.

We continue to allow this for objects whose values are not visible
within the constant evaluation, because there's no way we can tell
whether the access is defined or not, existing code relies on the
ability to make such calls, and every other compiler allows such
calls.
........
Fix handling of objects under construction during constant expression
evaluation.

It's not enough to just track the LValueBase that we're evaluating, we
need to also track the path to the objects whose constructors are
running.
........
Fixes windows buildbots

llvm-svn: 360531
2019-05-11 20:21:59 +00:00
Richard Smith d05df0ef43 Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.

This is undefined behavior per [class.cdtor]p2.

We continue to allow this for objects whose values are not visible
within the constant evaluation, because there's no way we can tell
whether the access is defined or not, existing code relies on the
ability to make such calls, and every other compiler allows such
calls.

llvm-svn: 360499
2019-05-11 02:00:06 +00:00
Richard Smith c0fe5eb39c Fix handling of objects under construction during constant expression
evaluation.

It's not enough to just track the LValueBase that we're evaluating, we
need to also track the path to the objects whose constructors are
running.

llvm-svn: 360464
2019-05-10 20:05:32 +00:00
Erik Pilkington f8ccf05293 [Sema] Mark array element destructors referenced during initialization
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
2019-05-10 17:52:26 +00:00
Akira Hatanaka c39a243da6 Assume `__cxa_allocate_exception` returns an under-aligned memory on
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
2019-05-10 02:16:37 +00:00
Richard Smith d9c6b039db DR1872: don't allow any calls to virtual functions in constant
evaluation.

Not even in cases where we would not actually perform virtual dispatch.

llvm-svn: 360370
2019-05-09 19:45:49 +00:00
Richard Smith 76b9027f35 [c++20] Add support for explicit(bool), as described in P0892R2.
Patch by Tyker!

Differential Revision: https://reviews.llvm.org/D60934

llvm-svn: 360311
2019-05-09 03:59:21 +00:00
Richard Smith b23c5e8c3d [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whose
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
2019-05-09 03:31:27 +00:00
Richard Smith 2194fb6ed9 When typo-correcting a function name, consider correcting to a type name
for a function-style cast.

llvm-svn: 360302
2019-05-09 00:57:24 +00:00
Aaron Ballman 6de5576af7 Allow 'static' storage specifier on an out-of-line class member template declaration in MSVCCompat mode.
Patch by Soumi Manna.

llvm-svn: 360250
2019-05-08 13:24:36 +00:00