Commit Graph

4913 Commits

Author SHA1 Message Date
Paul Robinson 9e04b532df [CXX] Exercise all paths through these tests.
Differential Revision: https://reviews.llvm.org/D63894

llvm-svn: 365555
2019-07-09 20:49:07 +00:00
Aaron Ballman b1e511bf5a Ignore trailing NullStmts in StmtExprs for GCC compatibility.
Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions.

Patch by Dominic Ferreira.

llvm-svn: 365498
2019-07-09 15:02:07 +00:00
David Blaikie 793231c319 [cxx2a] P0624R2 fix: only lambdas with no lambda-capture are default-constructible and assignable.
This is a fix for rG864949 which only disabled default construction and
assignment for lambdas with capture-defaults, where the C++2a draft
disables them for lambdas with any lambda-capture at all.

Patch by Logan Smith!

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

llvm-svn: 365406
2019-07-08 23:24:41 +00:00
Richard Smith 9e52c43090 Treat the range of representable values of floating-point types as [-inf, +inf] not as [-max, +max].
Summary:
Prior to r329065, we used [-max, max] as the range of representable
values because LLVM's `fptrunc` did not guarantee defined behavior when
truncating from a larger floating-point type to a smaller one. Now that
has been fixed, we can make clang follow normal IEEE 754 semantics in this
regard and take the larger range [-inf, +inf] as the range of representable
values.

In practice, this affects two parts of the frontend:
 * the constant evaluator no longer treats floating-point evaluations
   that result in +-inf as being undefined (because they no longer leave
   the range of representable values of the type)
 * UBSan no longer treats conversions to floating-point type that are
   outside the [-max, +max] range as being undefined

In passing, also remove the float-divide-by-zero sanitizer from
-fsanitize=undefined, on the basis that while it's undefined per C++
rules (and we disallow it in constant expressions for that reason), it
is defined by Clang / LLVM / IEEE 754.

Reviewers: rnk, BillyONeal

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 365272
2019-07-06 21:05:52 +00:00
Erik Pilkington eee944e7f9 [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.

The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.

rdar://44987528

Differential revision: https://reviews.llvm.org/D62825

llvm-svn: 364954
2019-07-02 18:28:13 +00:00
Richard Smith 7939ba08ab [cxx2a] P1236R1: the validity of a left shift does not depend on the
value of the LHS operand.

llvm-svn: 364265
2019-06-25 01:45:26 +00:00
Anastasia Stulova 1da9e4c910 [Sema] Improved diagnostic for qualifiers in reference binding
Improved wording and also simplified by using printing
method from qualifiers.

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

llvm-svn: 364023
2019-06-21 10:50:02 +00:00
Richard Smith 78b239ea67 P0840R2: support for [[no_unique_address]] attribute
Summary:
Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI.

This depends on D63371.

Reviewers: rjmccall, aaron.ballman

Subscribers: dschuff, aheejin, cfe-commits

Tags: #clang

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

llvm-svn: 363976
2019-06-20 20:44:45 +00:00
Anastasia Stulova c25ea86d43 [Sema] Diagnose addr space mismatch while constructing objects
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
2019-06-20 16:23:28 +00:00
Vivek Pandya 3a0100ac30 Allow copy/move assignment operator to be coroutine as per N4775
This change fixes https://bugs.llvm.org/show_bug.cgi?id=40997.

Reviewers: GorNishanov, rsmith
Reviewed by: GorNishanov
Subscribers: cfe-commits, lewissbaker, modocache, llvm-commits

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

llvm-svn: 363804
2019-06-19 14:12:19 +00:00
Aaron Puchert 2b285c664d Fix tests after r363749
We changed -Wmissing-prototypes there, which was used in these tests via
-Weverything.

llvm-svn: 363754
2019-06-18 23:40:17 +00:00
Aaron Puchert df195d8aed Suggestions to fix -Wmissing-{prototypes,variable-declarations}
Summary:
I've found that most often the proper way to fix this warning is to add
`static`, because if the code otherwise compiles and links, the function
or variable is apparently not needed outside of the TU.

We can't provide a fix-it hint for variable declarations, because
multiple VarDecls can share the same type, and if we put static in front
of that, we affect all declared variables, some of which might have
previous declarations.

We also provide no fix-it hint for the rare case of an `extern` function
definition, because that would require removing `extern` and I have no
idea how to get the source location of the storage class specifier from
a FunctionDecl. I believe this information is only available earlier in
the AST construction from DeclSpec::getStorageClassSpecLoc(), but we
don't have that here.

Reviewed By: aaron.ballman

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

llvm-svn: 363749
2019-06-18 22:57:08 +00:00
Gauthier Harnisch 0bb4d46b2b [clang] perform semantic checking in constant context
Summary:
Since the addition of __builtin_is_constant_evaluated the result of an expression can change based on whether it is evaluated in constant context. a lot of semantic checking performs evaluations with out specifying context. which can lead to wrong diagnostics.
for example:
```
constexpr int i0 = (long long)__builtin_is_constant_evaluated() * (1ll << 33); //#1
constexpr int i1 = (long long)!__builtin_is_constant_evaluated() * (1ll << 33); //#2
```
before the patch, #2 was diagnosed incorrectly and #1 wasn't diagnosed.
after the patch #1 is diagnosed as it should and #2 isn't.

Changes:
 - add a flag to Sema to passe in constant context mode.
 - in SemaChecking.cpp calls to Expr::Evaluate* are now done in constant context when they should.
 - in SemaChecking.cpp diagnostics for UB are not checked for in constant context because an error will be emitted by the constant evaluator.
 - in SemaChecking.cpp diagnostics for construct that cannot appear in constant context are not checked for in constant context.
 - in SemaChecking.cpp diagnostics on constant expression are always emitted because constant expression are always evaluated.
 - semantic checking for initialization of constexpr variables is now done in constant context.
 - adapt test that were depending on warning changes.
 - add test.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 363488
2019-06-15 08:32:56 +00:00
Gauthier Harnisch 796ed03b84 [C++20] add Basic consteval specifier
Summary:
this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html

with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration.

Changes:
 - add the consteval keyword.
 - add parsing of consteval specifier for normal declarations and lambdas expressions.
 - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval.
 - adapt diagnostic about constexpr to print constexpr or consteval depending on the case.
 - add tests for basic semantic.

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: eraman, efriedma, rnkovacs, cfe-commits

Tags: #clang

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

llvm-svn: 363362
2019-06-14 08:56:20 +00:00
Gauthier Harnisch b63e577444 [clang] Fixing incorrect implicit deduction guides (PR41549)
Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=41549 | bug report ]]

Before this patch, implicit deduction guides were generated from the first declaration found by lookup.
With this patch implicit deduction guides are generated from the definition of the class template.
Also added test that was previously failing.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits, Quuxplusone

Tags: #clang

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

llvm-svn: 363361
2019-06-14 08:40:04 +00:00
Gauthier Harnisch ef629c7ef8 [clang] Don't segfault on incorrect using directive (PR41400)
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
2019-06-14 08:25:52 +00:00
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