Commit Graph

5053 Commits

Author SHA1 Message Date
Nandor Licker a6bef738bf Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370584 (git commit afcb3de117)

llvm-svn: 370588
2019-08-31 15:15:39 +00:00
Nandor Licker afcb3de117 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 370584
2019-08-31 15:00:38 +00:00
Richard Smith 082754176f [c++20] Disallow template argument deduction from a braced-init-list
containing designators. The C++20 wording doesn't actually say what
happens in this case, but treating this as a non-deduced context seems
like the most natural behavior.

(We might want to consider deducing through array designators as an
extension in the future, but will need to be careful to deduce the array
bound properly if we do so. That's not permitted herein.)

llvm-svn: 370555
2019-08-31 00:05:50 +00:00
Richard Smith 5030928d60 [c++20] Implement semantic restrictions for C++20 designated
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
2019-08-30 22:52:55 +00:00
Nandor Licker 0300c3536a Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370531 (git commit d4c1002e0b)

llvm-svn: 370535
2019-08-30 21:32:00 +00:00
Nandor Licker d4c1002e0b [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 370531
2019-08-30 21:17:03 +00:00
Nandor Licker 5c8b94a672 Revert [Clang Interpreter] Initial patch for the constexpr interpreter
This reverts r370476 (git commit a559095054)

llvm-svn: 370481
2019-08-30 15:41:45 +00:00
Nandor Licker a559095054 [Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 370476
2019-08-30 15:02:09 +00:00
Richard Smith cd839ccf99 Fix silent wrong-code bugs and crashes with designated initialization.
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
2019-08-29 22:49:34 +00:00
Aaron Ballman 9fac4a5d35 Diagnose both _Complex and _Imaginary as C99 extensions.
llvm-svn: 370100
2019-08-27 19:15:24 +00:00
Reid Kleckner 39aa8954a4 Move EH spec mismatches under -fms-compatibility
-fms-extensions is intended to enable conforming language extensions and
-fms-compatibility is intended to language rule relaxations, so a user
could plausibly compile with -fno-ms-compatibility on Windows while
still using dllexport, for example.  This exception specification
validation behavior has been handled as a warning since before
-fms-compatibility was added in 2011. I think it's just an oversight
that it hasn't been moved yet.

This will help users find conformance issues in their code such as those
found in _com_ptr_t as described in https://llvm.org/PR42842.

Reviewers: hans

Subscribers: STL_MSFT, cfe-commits

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

llvm-svn: 370087
2019-08-27 17:52:03 +00:00
Richard Smith b26bc34e3a PR42587: diagnose unexpanded uses of a pack parameter of a generic
lambda from within the lambda-declarator.

Instead of trying to reconstruct whether a parameter pack was declared
inside a lambda (which we can't do correctly in general because we might
not have attached parameters to their declaration contexts yet), track
the set of parameter packs introduced in each live lambda scope, and
require only those parameters to be immediately expanded when they
appear inside that lambda.

In passing, fix incorrect disambiguation of a lambda-expression starting
with an init-capture pack in a braced-init-list. We previously
incorrectly parsed that as a designated initializer.

llvm-svn: 369985
2019-08-26 22:51:28 +00:00
Richard Smith cb167c85b4 PR42513: Enter the proper DeclContext before substituting into an
default template argument expression.

We already did this for type template parameters and template template
parameters, but apparently forgot to do so for non-type template
parameters. This causes the substituted default argument expression to
be substituted in the proper context, and in particular to properly mark
its subexpressions as odr-used.

llvm-svn: 369834
2019-08-24 02:30:00 +00:00
Richard Smith fefdc9371b Revert "PR42587: diagnose unexpanded uses of a pack parameter of a generic" due to buildbot breakage.
This reverts commit r369722.

llvm-svn: 369725
2019-08-23 02:33:46 +00:00
Richard Smith 7fbadf3b27 PR42587: diagnose unexpanded uses of a pack parameter of a generic
lambda from within the lambda-declarator.

llvm-svn: 369722
2019-08-23 01:41:48 +00:00
Richard Smith 966eea91ad Revert "[LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)"
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
2019-08-22 17:48:11 +00:00
Matthias Gehre b1c7801290 [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)
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
2019-08-21 22:08:59 +00:00
Nathan Huckleberry 1e0affb6e5 [Attr] Support _attribute__ ((fallthrough))
Summary: Fixed extraneous matches of non-NullStmt

Reviewers: aaron.ballman, rsmith, efriedma, xbolva00

Reviewed By: aaron.ballman, rsmith, xbolva00

Subscribers: riccibruno, arphaman, ziangwan, ojeda, xbolva00, nickdesaulniers, cfe-commits

Tags: #clang

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

llvm-svn: 369414
2019-08-20 17:16:49 +00:00
Erich Keane f04d246d7d Fix test where diagnostics changed in P1668 implementation
llvm-svn: 369284
2019-08-19 18:08:52 +00:00
Erich Keane 62b072d413 Implement P1668R1
Allow inline assembly statements in unexecuted branches of constexpr
functions.

llvm-svn: 369281
2019-08-19 17:39:59 +00:00
David Bolvansky 920890e268 [Diagnostics] Diagnose misused xor as pow
Summary:
Motivation:
https://twitter.com/jfbastien/status/1139298419988549632
https://twitter.com/mikemx7f/status/1139335901790625793
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E&search=Search

Reviewers: jfb, rsmith, regehr, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: lebedev.ri, Quuxplusone, erik.pilkington, riccibruno, dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 369217
2019-08-18 19:14:14 +00:00
Aaron Ballman 2ed4573e8f Allow standards-based attributes to have leading and trailing underscores.
This gives library implementers a way to use standards-based attributes that do not conflict with user-defined macros of the same name. Attributes in C2x require this behavior normatively (C2x 6.7.11p4), but there's no reason to not have the same behavior in C++, especially given that such attributes may be used by a C library consumed by a C++ compilation.

llvm-svn: 369033
2019-08-15 18:35:44 +00:00
Richard Smith 9e77f524b5 Fix handling of class member access into a vector type.
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
2019-08-14 22:57:50 +00:00
Erik Pilkington 0a223d981e [Sema] Require a complete type for __builtin_bit_cast operands
Fixes llvm.org/PR42936

llvm-svn: 368600
2019-08-12 18:31:27 +00:00
Peter Collingbourne 0e497d1554 cfi-icall: Allow the jump table to be optionally made non-canonical.
The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the output file's symbol table
with the address of a jump table entry which will pass CFI checks. We refer
to this as making the jump table `canonical`. This property allows code that
was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address
of a function, but it comes with a couple of caveats that are especially
relevant for users of cross-DSO CFI:

- There is a performance and code size overhead associated with each
  exported function, because each such function must have an associated
  jump table entry, which must be emitted even in the common case where the
  function is never address-taken anywhere in the program, and must be used
  even for direct calls between DSOs, in addition to the PLT overhead.

- There is no good way to take a CFI-valid address of a function written in
  assembly or a language not supported by Clang. The reason is that the code
  generator would need to insert a jump table in order to form a CFI-valid
  address for assembly functions, but there is no way in general for the
  code generator to determine the language of the function. This may be
  possible with LTO in the intra-DSO case, but in the cross-DSO case the only
  information available is the function declaration. One possible solution
  is to add a C wrapper for each assembly function, but these wrappers can
  present a significant maintenance burden for heavy users of assembly in
  addition to adding runtime overhead.

For these reasons, we provide the option of making the jump table non-canonical
with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump
table is made non-canonical, symbol table entries point directly to the
function body. Any instances of a function's address being taken in C will
be replaced with a jump table address.

This scheme does have its own caveats, however. It does end up breaking
function address equality more aggressively than the default behavior,
especially in cross-DSO mode which normally preserves function address
equality entirely.

Furthermore, it is occasionally necessary for code not compiled with
``-fsanitize=cfi-icall`` to take a function address that is valid
for CFI. For example, this is necessary when a function's address
is taken by assembly code and then called by CFI-checking C code. The
``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make
the jump table entry of a specific function canonical so that the external
code will end up taking a address for the function that will pass CFI checks.

Fixes PR41972.

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

llvm-svn: 368495
2019-08-09 22:31:59 +00:00
Diogo N. Sampaio 9427aa2d54 [ARM] Set default alignment to 64bits
Summary:
The maximum alignment used by ARM arch
is 64bits, not 128.

This could cause overaligned memory
access for 128 bit neon vector that
have unpredictable behaviour.

This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668

Reviewers: ostannard, dmgreen, srhines, danalbert, pirama, peter.smith

Reviewed By: pirama, peter.smith

Subscribers: phosek, thegameg, thakis, llvm-commits, carwil, peter.smith, javed.absar, kristof.beyls, cfe-commits

Tags: #clang, #llvm

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

llvm-svn: 368288
2019-08-08 12:50:36 +00:00
Richard Trieu 155b8d02c3 Update fix-it hints for std::move warnings.
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
2019-08-08 00:12:51 +00:00
Matthias Gehre 23092ca9ba gsl::Owner/gsl::Pointer: Add implicit annotations for some std types
Summary:
Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions
some types explicitly. Generally, all containers and their iterators are
covered. For iterators, we cover both the case that they are defined
as an nested class or as an typedef/using. I have started to test this
implementation against some real standard library implementations, namely
libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5,
libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0,
libstdc++ 8.3.0 and libstdc++ 9.1.0.

The tests are currently here
  https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.sh
  https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp
I think due to their dependency on a standard library, they are not a good fit
for clang/test/. Where else could I put them?

Reviewers: gribozavr, xazax.hun

Subscribers: rnkovacs, cfe-commits

Tags: #clang

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

llvm-svn: 368147
2019-08-07 10:45:36 +00:00
Fangrui Song e93341f7c8 [Sema] Disable -Wbitwise-op-parentheses and -Wlogical-op-parentheses by default
Summary:
The -Wparentheses warnings are enabled by default in clang but they are under
-Wall in gcc (gcc/c-family/c.opt). Some of the operator precedence warnings are
oftentimes criticized as noise (clang: default; gcc: -Wall). If a warning is
very controversial, it is probably not a good idea to enable it by default.
This patch disables the rather annoying ones:

-Wbitwise-op-parentheses, e.g. i & i | i
-Wlogical-op-parentheses, e.g. i && i || i

After this change:

```
* = enabled by default

-Wall
  -Wparentheses
    -Wlogical-op-parentheses
    -Wlogical-not-parentheses*
    -Wbitwise-op-parentheses
    -Wshift-op-parentheses*
    -Woverloaded-shift-op-parentheses*
    -Wparentheses-equality*
    -Wdangling-else*
```

-Woverloaded-shift-op-parentheses is typically followed by overload
resolution failure. We can instead improve the error message, and
probably delete -Woverloaded-shift-op-parentheses in the future. Keep it
for now because it gives some diagnostics.

Reviewers: akyrtzi, jyknight, rtrieu, rsmith, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 367690
2019-08-02 16:31:38 +00:00
Anastasia Stulova 8d99a5c0e6 [OpenCL] Allow OpenCL C style vector initialization in C++
Allow creating vector literals from other vectors.

 float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
 float4 v = (float4)(a.s23, a.s01);

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

llvm-svn: 367675
2019-08-02 11:19:35 +00:00
Erik Pilkington 4cae092099 [Sema] Actually map a variable template specialization from pattern to instantiation
We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.

Fixes llvm.org/PR42779.

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

llvm-svn: 367367
2019-07-30 23:38:18 +00:00
Richard Smith e8b659fc1f Give the 'signed/unsigned wchar_t' extension a warning flag, and follow
GCC 9 in promoting it to an error by default.

llvm-svn: 367255
2019-07-29 20:00:46 +00:00
Richard Smith a625da716c When determining whether a lambda-expression is implicitly constexpr,
check the formal rules rather than seeing if the normal checks produce a
diagnostic.

This fixes the handling of C++2a extensions in lambdas in C++17 mode,
as well as some corner cases in earlier language modes where we issue
diagnostics for things other than not satisfying the formal constexpr
requirements.

llvm-svn: 367254
2019-07-29 19:59:45 +00:00
Petr Hosek 92a2e1bbb9 Revert "[ARM] Set default alignment to 64bits"
This reverts commit r367119.

This broke several bots:

http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull

llvm-svn: 367166
2019-07-27 01:59:23 +00:00
Simi Pallipurath 92363a3ada [ARM] Set default alignment to 64bits
The maximum alignment used by ARM arch
is 64bits, not 128.

This could cause overaligned memory
access for 128 bit neon vector that
have unpredictable behaviour.

This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668

Patch by: Diogo Sampaio(diogo.sampaio@arm.com)

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

Change-Id: I5a62b766491f15dd51e4cfe6625929db897f67e3
llvm-svn: 367119
2019-07-26 15:05:19 +00:00
Matthias Gehre d293cbd5fd Add lifetime categories attributes
Summary:
This is the first part of work announced in
"[RFC] Adding lifetime analysis to clang" [0],
i.e. the addition of the [[gsl::Owner(T)]] and
[[gsl::Pointer(T)]] attributes, which
will enable user-defined types to participate in
the lifetime analysis (which will be part of the
next PR).
The type `T` here is called "DerefType" in the paper,
and denotes the type that an Owner owns and a Pointer
points to. E.g. `std::vector<int>` should be annotated
with `[[gsl::Owner(int)]]` and
a `std::vector<int>::iterator` with `[[gsl::Pointer(int)]]`.

[0] http://lists.llvm.org/pipermail/cfe-dev/2018-November/060355.html

Reviewers: gribozavr

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 367040
2019-07-25 17:50:51 +00:00
Richard Smith 6a38205039 [c++20] P1161R3: a[b,c] is deprecated.
llvm-svn: 366630
2019-07-20 09:32:27 +00:00
Aaron Ballman 3bef014e7d Implement P1301R4, which allows specifying an optional message on the [[nodiscard]] attribute.
This also bumps the attribute feature test value and introduces the notion of a C++2a extension warning.

llvm-svn: 366626
2019-07-20 07:56:34 +00:00
Sunil Srivastava 85d667fcb6 Renamed and changed the wording of warn_cconv_ignored
As discussed in D64780 the wording of this warning message is being
changed to say 'is not supported' instead of 'ignored', and the
diag ID itself is being changed to warn_cconv_not_supported.

llvm-svn: 366368
2019-07-17 20:41:26 +00:00
Evgeniy Stepanov c5e7f56249 ARM MTE stack sanitizer.
Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.

The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.

Reviewers: pcc, hctim, vitalybuka, ostannard

Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 366123
2019-07-15 20:02:23 +00:00
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
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
Sam McCall 835d67f6c7 [Sema] Correct typos in return statements so the return types of 'auto' functions are always deduced.
Summary:
e.g.
  auto foo() {
    return no_such_thing; // Return value is a TypoExpr
  }
  using T = decltype(foo()); // Uh-oh, undeduced auto.

Reviewers: rsmith

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 360224
2019-05-08 05:49:42 +00:00
Hans Wennborg d2b9fc88c8 Revert r359949 "[clang] adding explicit(bool) from c++2a"
This caused Clang to start erroring on the following:

  struct S {
    template <typename = int> explicit S();
  };

  struct T : S {};

  struct U : T {
    U();
  };
  U::U() {}

  $ clang -c /tmp/x.cc
  /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
  U::U() {}
     ^
  /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
    because base class 'S' has no default constructor
  struct T : S {};
             ^
  1 error generated.

See discussion on the cfe-commits email thread.

This also reverts the follow-ups r359966 and r359968.

> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934

llvm-svn: 360024
2019-05-06 09:51:10 +00:00
Richard Smith 2b45b267da P1286R2: Remove restriction that the exception specification of a
defaulted special member matches the implicit exception specification.

llvm-svn: 360011
2019-05-06 05:04:56 +00:00
Richard Smith 7d02ca4878 Use DiagRuntimeBehavior for -Wunsequenced to weed out false positives
where either the modification or the other access is unreachable.

This reverts r359984 (which reverted r359962). The bug in clang-tidy's
test suite exposed by the original commit was fixed in r360009.

llvm-svn: 360010
2019-05-06 04:14:01 +00:00
Richard Smith b9fb121a62 [c++20] Implement P1009R2: allow omitting the array bound in an array
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
2019-05-06 03:47:15 +00:00
Simon Pilgrim 4c3fbbf635 Revert rL359962 : Use DiagRuntimeBehavior for -Wunsequenced to weed out false positives
where either the modification or the other access is unreachable.
........
Try to fix buildbots

llvm-svn: 359984
2019-05-05 17:10:05 +00:00
Nicolas Lesser ee0571734f [C++] Interpret unknown identifier in parameter clause as unknown type
instead of as parameter name without a type.

llvm-svn: 359979
2019-05-05 12:15:17 +00:00
Hamza Sood 8205a814a6 [c++20] Implement P0428R2 - Familiar template syntax for generic lambdas
Differential Revision: https://reviews.llvm.org/D36527

llvm-svn: 359967
2019-05-04 10:49:46 +00:00
Richard Smith 5dbfa76334 Use DiagRuntimeBehavior for -Wunsequenced to weed out false positives
where either the modification or the other access is unreachable.

llvm-svn: 359962
2019-05-04 05:20:14 +00:00
Richard Smith 37be3363b5 Disallow the operand of __builtin_constant_p from modifying enclosing
state when it's encountered while evaluating a constexpr function.

We attempt to follow GCC trunk's behavior here, but it is somewhat
inscrutible, so our behavior is only approximately the same for now.
Specifically, we only permit modification of objects whose lifetime
began within the operand of the __builtin_constant_p. GCC appears to
have effectively the same restriction, but also some unknown restriction
based on where and how the local state of the constexpr function is
mentioned within the operand (see added testcases).

llvm-svn: 359958
2019-05-04 04:00:45 +00:00
Nicolas Lesser 5fe2ddbdf4 [clang] adding explicit(bool) from c++2a
this patch adds support for the explicit bool specifier.

Changes:
- The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
- The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
- Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
- Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
- The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
- Test for Semantic and Serialization were added.

This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.

Patch by Tyker

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

llvm-svn: 359949
2019-05-04 00:09:00 +00:00
Nico Weber ecc969caf9 Revert r359814 "[Sema] Emit warning for visibility attribute on internal-linkage declaration"
See cfe-commits thread for r359814.

llvm-svn: 359858
2019-05-03 03:16:07 +00:00
David Blaikie 5e32805050 SemaOverload: Complete candidates before emitting the error, to ensure 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
2019-05-03 00:44:50 +00:00
Scott Linder daa3c5b132 [Sema] Emit warning for visibility attribute on internal-linkage declaration
GCC warns on these cases, but we currently just silently ignore the attribute.

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

llvm-svn: 359814
2019-05-02 19:03:57 +00:00
Richard Smith bac77806c5 Diagnose non-dependent qualified friend function template declarations
that don't match any existing declaration. Don't get confused and treat
such declarations as template *specializations*.

llvm-svn: 359746
2019-05-02 00:49:05 +00:00
Volodymyr Sapsai 31f7c4aa77 [Parser] Avoid correcting delayed typos in array subscript multiple times.
We correct some typos in `ActOnArraySubscriptExpr` and
`ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can
end up correcting delayed typos in the same expressions again. In
general it is OK but when `NumTypos` is incorrect, we can hit the
assertion

> Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219.

Fix by replacing some subscript `ExprResult` with typo-corrected expressions
instead of keeping the original expressions. Thus if original expressions
contained `TypoExpr`, we'll use corrected expressions instead of trying to
correct them again.

rdar://problem/47403222

Reviewers: rsmith, erik.pilkington, majnemer

Reviewed By: erik.pilkington

Subscribers: jkorous, dexonsmith, cfe-commits

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

llvm-svn: 359713
2019-05-01 19:24:50 +00:00
David Bolvansky efba22cb6c [Diagnostics] Support -Wtype-limits for GCC compatibility
Summary:
GCC's  -Wtype-limits (part of -Wextra):
Warn if a comparison is always true or always false due to the limited range of the data type

Reviewers: rsmith, aaron.ballman, lebedev.ri, thakis

Reviewed By: rsmith

Subscribers: lebedev.ri, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 359516
2019-04-29 23:24:00 +00:00
Richard Smith 31cfb311c5 Reinstate r359059, reverted in r359361, with a fix to properly prevent
us emitting the operand of __builtin_constant_p if it has side-effects.

Original commit message:

Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
  * Clang now supports nullptr_t as the argument type for
    __builtin_constant_p
    * Clang now returns true from __builtin_constant_p if called with a
    null pointer
    * Clang now returns true from __builtin_constant_p if called with an
    integer cast to pointer type

llvm-svn: 359367
2019-04-27 02:58:17 +00:00
Jorge Gorbe Moya 1dbd42ab5b Revert Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC.
This reverts r359059 (git commit 0b098754b7)

llvm-svn: 359361
2019-04-27 00:32:04 +00:00
Martin Storsjo 5be69bc68a [MinGW] Fix dllexport of explicit template instantiation
Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute
on the template instantiation declaration, not on the definition.

Previously clang never marked explicit template instantiations as
dllexport in MinGW mode, if the instantiation had a previous
declaration, regardless of where the attribute was placed. This
makes Clang behave like GCC in this regard, and allows using the
same attribute form for both MinGW compilers.

This fixes PR40256.

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

llvm-svn: 359285
2019-04-26 08:09:51 +00:00
Richard Smith bb750689d5 C++ DR2387: a variable template declared wtih (or instantiated with) a
const-qualified type is not implicitly given internal linkage. But a
variable template declared 'static' is.

This reinstates part of r359048, reverted in r359076.

llvm-svn: 359260
2019-04-26 01:51:08 +00:00
Richard Smith 0d923af492 Add missing diagnostic for explicit instantiation declarations naming
internal linkage entities.

Such constructs are ill-formed by [temp.explicit]p13. We make a special
exception to permit an invalid construct used by libc++ in some build
modes: its <valarray> header declares some functions with the
internal_linkage attribute and then (meaninglessly) provides explicit
instantiation declarations for them. Luckily, Clang happens to
effectively ignore the explicit instantiation declaration when
generating code in this case, and this change codifies that behavior.

This reinstates part of r359048, reverted in r359076. (The libc++ issue
triggering the rollback has been addressed.)

llvm-svn: 359259
2019-04-26 01:51:07 +00:00
Ilya Biryukov b8292c955c Revert r359048: C++ DR2387: a variable template declared wthi
The change breaks libc++ with the follwing error:

In file included from valarray:4:
.../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t))
                                                           ^
.../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray())

llvm-svn: 359076
2019-04-24 08:50:24 +00:00
Eric Fiselier add16a8da9 [Builtins] Implement __builtin_is_constant_evaluated for use in C++2a
Summary:
This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`.

More tests to come, but early feedback is appreciated.

I plan to implement warnings for common mis-usages like those belowe in a following patch:
```
void foo(int x) {
  if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead.
   foo_constexpr(x);
  } else {
    foo_runtime(x);
  }
}
```



Reviewers: rsmith, MaskRay, bruno, void

Reviewed By: rsmith

Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits

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

llvm-svn: 359067
2019-04-24 02:23:30 +00:00
Richard Smith 42a22370f2 Revert r350917 "[Sema] If CheckPlaceholderExpr rewrites the initializer
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
2019-04-24 02:22:38 +00:00
Richard Smith 0b098754b7 Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
 * Clang now supports nullptr_t as the argument type for
   __builtin_constant_p
 * Clang now returns true from __builtin_constant_p if called with a
   null pointer
 * Clang now returns true from __builtin_constant_p if called with an
   integer cast to pointer type

llvm-svn: 359059
2019-04-24 01:29:28 +00:00
Richard Smith 3ac3e9ce04 Add missing diagnostic for anonymous struct/union definitions that don't
introduce any names.

llvm-svn: 359051
2019-04-24 00:08:02 +00:00
Richard Smith eeab4518e1 C++ DR2387: a variable template declared wtih (or instantiated with) a
const-qualified type is not implicitly given internal linkage. But a
variable template declared 'static' is.

llvm-svn: 359048
2019-04-23 23:48:00 +00:00
Joel E. Denny 3234887fe2 [APSInt][OpenMP] Fix isNegative, etc. for unsigned types
Without this patch, APSInt inherits APInt::isNegative, which merely
checks the sign bit without regard to whether the type is actually
signed.  isNonNegative and isStrictlyPositive call isNegative and so
are also affected.

This patch adjusts APSInt to override isNegative, isNonNegative, and
isStrictlyPositive with implementations that consider whether the type
is signed.

A large set of Clang OpenMP tests are affected.  Without this patch,
these tests assume that `true` is not a valid argument for clauses
like `collapse`.  Indeed, `true` fails APInt::isStrictlyPositive but
not APSInt::isStrictlyPositive.  This patch adjusts those tests to
assume `true` should be accepted.

This patch also adds tests revealing various other similar fixes due
to APSInt::isNegative calls in Clang's ExprConstant.cpp and
SemaExpr.cpp: `++` and `--` overflow in `constexpr`, evaluated object
size based on `alloc_size`, `<<` and `>>` shift count validation, and
OpenMP array section validation.

Reviewed By: lebedev.ri, ABataev, hfinkel

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

llvm-svn: 359012
2019-04-23 17:04:15 +00:00
Richard Smith e181de7f4f [c++2a] Implement semantic restrictions for 'export' declarations.
llvm-svn: 358932
2019-04-22 22:50:11 +00:00
Louis Dionne 0fa94ee318 Revert "[clang] Aligned allocation is actually supported in macosx 10.13"
This reverts r358409, which I think broke the bots in compiler-rt.
Since I'm having trouble reproducing the failure, I'm reverting this
until I can investigate locally.

llvm-svn: 358437
2019-04-15 19:08:52 +00:00
Louis Dionne f2073321c9 [clang] Aligned allocation is actually supported in macosx 10.13
Summary:
In r350649, I changed aligned allocation from being available starting
in macosx10.13 to macosx10.14. However, aligned allocation is indeed
available starting with macosx10.13, my investigation had been based
on the wrong libc++abi dylib.

This means that Clang before the fix will be more stringent when it
comes to aligned allocation -- it will not allow it when back-deploying
to macosx 10.13, when it would actually be safe to do so.

Note that a companion change will be coming to fix the libc++ tests.

Reviewers: ahatanak

Subscribers: jkorous, dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 358409
2019-04-15 14:14:45 +00:00
Dmitri Gribenko 66b6bb1766 Check i < FD->getNumParams() before querying
Summary:
As was already stated in a previous comment, the parameter isn't
necessarily referring to one of the DeclContext's parameter. We
should check the index is within the range to avoid out-of-boundary
access.

Reviewers: gribozavr, rsmith, lebedev.ri

Reviewed By: gribozavr, rsmith

Subscribers: lebedev.ri, cfe-commits

Tags: #clang

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

Patch by Violet.

llvm-svn: 358134
2019-04-10 20:25:07 +00:00
Volodymyr Sapsai 9e911f3a64 [Sema] Fix assertion when `auto` parameter in lambda has an attribute.
Fixes the assertion
> no Attr* for AttributedType*
> UNREACHABLE executed at llvm-project/clang/lib/Sema/SemaType.cpp:298!

In `TypeProcessingState::getAttributedType` we put into `AttrsForTypes`
types with `auto` but later in
`TypeProcessingState::takeAttrForAttributedType` we use transformed
types and that's why cannot find `Attr` corresponding to
`AttributedType`.

Fix by keeping `AttrsForTypes` up to date after replacing `AutoType`.

rdar://problem/47689465

Reviewers: rsmith, arphaman, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: jkorous, dexonsmith, jdoerfert, cfe-commits

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

llvm-svn: 357298
2019-03-29 18:47:07 +00:00
Michael Liao ce38992a30 [Sema] Fix a crash when nonnull checking
Summary:
- If a parameter is used, nonnull checking needs function prototype to
  retrieve the corresponding parameter's attributes. However, at the
  prototype substitution phase when a template is being instantiated,
  expression may be created and checked without a fully specialized
  prototype. Under such a scenario, skip nonnull checking on that
  argument.

Reviewers: rjmccall, tra, yaxunl

Subscribers: javed.absar, kristof.beyls, cfe-commits

Tags: #clang

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

llvm-svn: 357236
2019-03-29 03:55:52 +00:00
Erik Pilkington 14f6d1527c [Sema] Fix an assert when a block captures a constexpr local
MarkVarDeclODRUsed indirectly calls captureInBlock, which creates a copy
expression. The copy expression is insulated in it's own
ExpressionEvaluationContext, so it saves, mutates, and restores MaybeODRUseExprs
as CleanupVarDeclMarking is iterating through it, leading to a crash. Fix this
by iterating through a local copy of MaybeODRUseExprs.

rdar://47493525

https://reviews.llvm.org/D59670

llvm-svn: 357040
2019-03-26 23:21:19 +00:00
Reid Kleckner 1181c9f45d [MS] Add frontend support for __declspec(allocator)
The intention is to add metadata to direct call sites of functions
marked with __declspec(allocator), which will ultimately result in some
S_HEAPALLOCSITE debug info records when emitting codeview.

This is a piece of PR38491

llvm-svn: 356964
2019-03-25 23:20:18 +00:00
Bruno Ricci 95550e412f [Sema] Don't check for array bounds when the types in the base expression are dependent
Bail-out of CheckArrayAccess when the types of the base expression before
and after eventual casts are dependent. We will get another chance to check
for array bounds during instantiation. Fixes PR41087.

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

Reviewed By: efriedma

llvm-svn: 356957
2019-03-25 21:37:10 +00:00
Brian Gesiak b15c35aff8 Un-revert "[coroutines][PR40978] Emit error for co_yield within catch block"
Summary:
https://reviews.llvm.org/D59076 added a new coroutine error that
prevented users from using 'co_await' or 'co_yield' within a exception
handler. However, it was reverted in https://reviews.llvm.org/rC356774
because it caused a regression in nested scopes in C++ catch statements,
as documented by https://bugs.llvm.org/show_bug.cgi?id=41171.

The issue was due to an incorrect use of a `clang::ParseScope`. To fix:

1. Add a regression test for catch statement parsing that mimics the bug
   report from https://bugs.llvm.org/show_bug.cgi?id=41171.
2. Re-apply the coroutines error patch from
   https://reviews.llvm.org/D59076, but this time with the correct
   ParseScope behavior.

Reviewers: GorNishanov, tks2103, rsmith, riccibruno, jbulow

Reviewed By: riccibruno

Subscribers: EricWF, jdoerfert, lewissbaker, cfe-commits

Tags: #clang

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

llvm-svn: 356865
2019-03-25 00:53:10 +00:00
Brian Gesiak e8b3d63dd5 Revert "[coroutines][PR40978] Emit error for co_yield within catch block"
The commit https://reviews.llvm.org/rC356296 is causing a regression in nested
catch scopes, https://bugs.llvm.org/show_bug.cgi?id=41171. Revert this change
for now in order to un-break that problem report.

llvm-svn: 356774
2019-03-22 16:08:29 +00:00
Erich Keane 505427cb2f Permit redeclarations of a builtin to specify calling convention.
After https://reviews.llvm.org/rL355317 we noticed that quite a decent
amount of code redeclares builtins (memcpy in particular, I believe
reduced from an MSVC header) with a calling convention specified.
This gets particularly troublesome when the user specifies a new
'default' calling convention on the command line.

When looking to add a diagnostic for this case, it was noticed that we
had 3 other diagnostics that differed only slightly.  This patch ALSO
unifies those under a 'select'.  Unfortunately, the order of words in
ONE of these diagnostics was reversed ("'thiscall' calling convention"
vs "calling convention 'thiscall'"), so this patch also standardizes on
the former.

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

Change-Id: I79f99fe7c2301640755ffdd774b46eb44526bb22
llvm-svn: 356663
2019-03-21 13:30:56 +00:00
Erik Pilkington 13ee62f7d7 [Sema] Deduplicate some availability checking logic
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
2019-03-20 19:26:33 +00:00
Aaron Ballman 165435ffa0 Ensure that const variables declared at namespace scope correctly have external linkage when marked as dllexport and targeting the MSVC ABI.
Patch thanks to Zahira Ammarguellat.

llvm-svn: 356458
2019-03-19 14:53:52 +00:00
Aaron Puchert ad4d52a501 Thread safety analysis: Add note for unlock kind mismatch
Summary:
Similar to D56967, we add the existing diag::note_locked_here to tell
the user where we saw the locking that isn't matched correctly.

Reviewers: aaron.ballman, delesley

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 356427
2019-03-18 23:26:54 +00:00