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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Summary:
The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1]
```
// error {{never produces a constant expression}}
void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {}
void test() { foo("abc"); }
```
Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression.
The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions.
[1] https://godbolt.org/z/ksAjmq
Reviewers: rsmith, hans, sbenza
Reviewed By: rsmith
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59038
llvm-svn: 355743
This change adds a new diagnostic for mismatching address spaces
to be used for C++ casts (only enabled in C style cast for now,
the rest will follow!).
The change extends C-style cast rules to account for address spaces.
It also adds a separate function for address space cast checking that
can be used to map from a separate address space cast operator
addrspace_cast (to be added as a follow up patch).
Note, that after this change clang will no longer allows arbitrary
address space conversions in reinterpret_casts because they can lead
to accidental errors. The implicit safe conversions would still be
allowed.
Differential Revision: https://reviews.llvm.org/D58346
llvm-svn: 355609
Add some tests for unsequenced operations with members and references.
For now most of it is unhandled but it shows what work needs to be done.
Also merge the tests for the C++17 sequencing rules in warn-unsequenced.cpp
since we want to make sure that the appropriate warnings are still present
in C++17 without duplicating the whole content of warn-unsequenced.cpp.
llvm-svn: 354151
Summary:
The idea is that the code here isn't written, so doesn't indicate a bug.
Similar to code expanded from macros.
This means the warning no longer fires on this code:
for (auto C : collection) {
process(C);
return;
}
handleEmptyCollection();
Unclear whether this is more often a bug or not in practice, I think it's a
reasonable idiom in some cases.
Either way, if we want to warn on "loop that doesn't loop", I think it should be
a separate warning, and catch `while(1) break;`
Reviewers: ilya-biryukov, ioeric
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58134
llvm-svn: 354102
We were warning on valid ObjC property reference exprs, and passing
in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly
worded diagnostic).
rdar://47644670
Differential revision: https://reviews.llvm.org/D58145
llvm-svn: 354074
Summary:
This makes it consistent with `memcmp` and `__builtin_bcmp`.
Also see the discussion in https://reviews.llvm.org/D56593.
Reviewers: jyknight
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58120
llvm-svn: 354023
Summary:
When this was rewritten in D43737, the logic changed to better explore infinite loops. The check for a reachable exit block was deleted which accidentally introduced false positives in case the exit node was unreachable.
We were testing for cases like this, but @steven_wu provided an additional test case that I've included in the regression tests for this patch.
Reviewers: steven_wu, rtrieu
Reviewed By: steven_wu, rtrieu
Subscribers: cfe-commits, steven_wu
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58122
llvm-svn: 353984
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.
This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization. If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray. This shouldn't
affect the memory usage for other string literals. (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)
The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check. I this this is fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 .
llvm-svn: 353569
When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets
the default standard to something other than C++14, there are a number of lit
tests that fail as they rely on the C++14 default.
This patch just adds the language standard option explicitly to such test cases.
Differential revision: https://reviews.llvm.org/D57581
llvm-svn: 353163
Clang allows users to enable or disable various types of allocation
and deallocation regardless of the C++ dialect. When extended new/delete
overloads are enabled in older dialects, we need to treat them as if
they're usual.
Also, disabling one usual deallocation form shouldn't
disable any others. For example, disabling aligned allocation in C++2a
should have no effect on destroying delete.
llvm-svn: 352980
I recently ran into this code:
```
\#include <iostream>
void foo(const std::string &s, const std::string& = "");
\#include <string>
void test() { foo(""); }
```
The diagnostic produced said it can't bind char[1] to std::string
const&. It didn't mention std::string is incomplete. The user had to
infer that.
This patch causes the diagnostic to now say "incomplete type".
llvm-svn: 352927
Summary:
Given the following test program:
```
class C {
public:
int A(int a, int& b);
};
int C::A(const int a, int b) {
return a * b;
}
```
Clang would produce an error message that correctly diagnosed the
redeclaration of `C::A` to not match the original declaration (the
parameters to the two declarations do not match -- the original takes an
`int &` as its 2nd parameter, but the redeclaration takes an `int`). However,
it also produced a note diagnostic that inaccurately pointed to the
first parameter, claiming that `const int` in the redeclaration did not
match the unqualified `int` in the original. The diagnostic is
misleading because it has nothing to do with why the program does not
compile.
The logic for checking for a function overload, in
`Sema::FunctionParamTypesAreEqual`, discards cv-qualifiers before
checking whether the types are equal. Do the same when producing the
overload diagnostic.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cpplearner, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57032
llvm-svn: 352831
Summary:
We use the existing diag::note_locked_here to tell the user where we saw
the first locking.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56967
llvm-svn: 352549
Summary:
Trying to use structure binding with a structure that doesn't implement
std::tuple_size, should unpack the data members. When the struct is a
template though, clang might hit an assertion (if the type has not been
completed before), because CXXRecordDecl::DefinitionData is nullptr.
This commit fixes the problem by completing the type while trying to
decompose the structured binding.
The ICE happens in real world code, for example, when trying to iterate
a protobuf generated map with a range-based for loop and structure
bindings (because google::protobuf::MapPair is a template and doesn't
support std::tuple_size).
Reported-by: nicholas.sun@nlsun.com
Patch by Daniele Di Proietto
Reviewers: #clang, rsmith
Reviewed By: #clang, rsmith
Subscribers: cpplearner, Rakete1111, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56974
llvm-svn: 352323
Float16 support was disabled recently on many platforms, however that
commit still allowed literals of Float16 type to work. This commit
removes those based on the same logic as Float16 disable.
Change-Id: I72243048ae2db3dc47bd3d699843e3edf9c395ea
llvm-svn: 352229
declaration in MSVCCompat mode
Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.
This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).
Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.
Patch By: Manna
Differential Revision: https://reviews.llvm.org/D56473
Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702
llvm-svn: 352219
When attempting to correct a misspelled pseudo destructor call as in:
struct Foo;
void foo(Foo *p) {
p.~Foo();
}
a call is made in canRecoverDotPseudoDestructorCallsOnPointerObjects
to LookupDestructor without checking that the record has a definition.
This causes an assertion later in LookupSpecialMember which assumes that
the record has a definition.
Patch By Roman Zhikharevich!
Differential Revision: https://reviews.llvm.org/D57111
Reviewed By: riccibruno
llvm-svn: 352047
With commit r351627, LLVM gained the ability to apply (existing) IPO
optimizations on indirections through callbacks, or transitive calls.
The general idea is that we use an abstraction to hide the middle man
and represent the callback call in the context of the initial caller.
It is described in more detail in the commit message of the LLVM patch
r351627, the llvm::AbstractCallSite class description, and the
language reference section on callback-metadata.
This commit enables clang to emit !callback metadata that is
understood by LLVM. It does so in three different cases:
1) For known broker functions declarations that are directly
generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
2) For known broker functions that are identified by their name and
source location through the builtin detection, e.g.,
pthread_create from the POSIX thread API.
3) For user annotated functions that carry the "callback(callee, ...)"
attribute. The attribute has to include the name, or index, of
the callback callee and how the passed arguments can be
identified (as many as the callback callee has). See the callback
attribute documentation for detailed information.
Differential Revision: https://reviews.llvm.org/D55483
llvm-svn: 351629
Summary:
This attribute will allow users to opt specific functions out of
speculative load hardening. This compliments the Clang attribute
named speculative_load_hardening. When this attribute or the attribute
speculative_load_hardening is used in combination with the flags
-mno-speculative-load-hardening or -mspeculative-load-hardening,
the function level attribute will override the default during LLVM IR
generation. For example, in the case, where the flag opposes the
function attribute, the function attribute will take precendence.
The sticky inlining behavior of the speculative_load_hardening attribute
may cause a function with the no_speculative_load_hardening attribute
to be tagged with the speculative_load_hardening tag in
subsequent compiler phases which is desired behavior since the
speculative_load_hardening LLVM attribute is designed to be maximally
conservative.
If both attributes are specified for a function, then an error will be
thrown.
Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54909
llvm-svn: 351565
The test has problems due to some platforms having a different type for
ptrdiff_t, so the error message is different. The error message doesn't
matter to the test for anything other than an incompatible intger to
pointer conversion, so this patch removes the integral type from the
expected message.
Change-Id: I80e786f9b80268163813774bbf25a9ca25b6c60c
llvm-svn: 351550
As reported in PR40362, allowing the conversion from an integral to a
pointer type (despite being illegal in the C++ standard) will cause
surprsing results when testing for certain behaviors in SFINAE. This
patch converts the error to a SFINAE Error and adds a test to ensure
that it is still a warning in non-SFINAE but an error in it.
Change-Id: I1f475637fa4d83217ae37dc6b5dbf653e118fae4
llvm-svn: 351495
Summary:
Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are designed to support it and not just types that *happen* to work with it.
This patch implements the `-Wctad-maybe-unsupported` warning, which is off by default, which warns when CTAD is used on a type that does not define any deduction guides.
The following pattern can be used to suppress the warning in cases where the type intentionally doesn't define any deduction guides:
```
struct allow_ctad_t;
template <class T>
struct TestSuppression {
TestSuppression(T) {}
};
TestSuppression(allow_ctad_t)->TestSuppression<void>; // guides with incomplete parameter types are never considered.
```
Reviewers: rsmith, james.dennett, gromer
Reviewed By: rsmith
Subscribers: jdennett, Quuxplusone, lebedev.ri, cfe-commits
Differential Revision: https://reviews.llvm.org/D56731
llvm-svn: 351484
member enum and then its enclosing class.
There are situations where ADL will collect a class but not the complete
set of associated classes / namespaces of that class. When that
happened, and we later tried to collect those associated classes /
namespaces, we would previously short-circuit the lookup and not find
them. Eg, for:
struct A : B { enum E; };
if we first looked for associated classes/namespaces of A::E, we'd find
only A. But if we then tried to also collect associated
classes/namespaces of A (which should include the base class B), we
would not add B because we had already visited A.
This also fixes a minor issue where we would fail to collect associated
classes from an overloaded class member access expression naming a
static member function.
llvm-svn: 351382
When -faligned-allocation is specified in C++03 libc++ defines
std::align_val_t as an unscoped enumeration type (because Clang didn't
provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with
the sized deallocation overloads which aren't enabled. This caused Clang
to call the aligned deallocation function as if it were the sized
deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
llvm-svn: 351294
Summary: In the [expr.sub] p1, we can read that for a given E1[E2], E1 is sequenced before E2.
Patch by Mateusz Janek.
Reviewers: rsmith, Rakete1111
Reviewed By: rsmith, Rakete1111
Subscribers: riccibruno, lebedev.ri, Rakete1111, hiraditya, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50766
llvm-svn: 350874
This group controls two diagnostics: deleting an abstract class with
a non-virtual dtor, which is a guaranteed crash, and deleting a
non-abstract polymorphic class with a non-virtual dtor, which is just
suspicious.
rdar://40380564
Differential revision: https://reviews.llvm.org/D56405
llvm-svn: 350856
Summary:
r306722 added diagnostics when aligned allocation is used with deployment
targets that do not support it, but the first macosx supporting aligned
allocation was incorrectly set to 10.13. In reality, the dylib shipped
with macosx10.13 does not support aligned allocation, but the dylib
shipped with macosx10.14 does.
Reviewers: ahatanak
Subscribers: christof, jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D56445
llvm-svn: 350649
When the type of the base expression after IgnoreParenCasts is incomplete,
it is still possible to diagnose an array access which precedes the array
bounds.
This is a follow-up on D55862 which added an early return when the type of
the base expression after IgnoreParenCasts was incomplete.
Differential Revision: https://reviews.llvm.org/D56050
Reviewed By: efriedma
llvm-svn: 350622
-Wdelete-non-virtual-dtor previously controlled two diagnostics: 1)
calling a non-virtual dtor from an abstract class, and 2) calling a
non-virtual dtor from a polymorphic class. 1) is a lot more severe
than 2), since 1) is a guaranteed crash, but 2) is just "code smell".
Previously, projects compiled with -Wall -Wno-delete-non-virtual-dtor,
which is somewhat reasonable, silently crashed on 1).
rdar://40380564
Differential revision: https://reviews.llvm.org/D56405
llvm-svn: 350585
template specialization if there is no matching non-template function.
This exposed a couple of related bugs:
- we would sometimes substitute into a friend template instead of a
suitable non-friend declaration; this would now crash because we'd
decide the specialization of the friend is a redeclaration of itself
- ADL failed to properly handle the case where an invisible local
extern declaration redeclares an invisible friend
Both are fixed herein: in particular, we now never make invisible
friends or local extern declarations visible to name lookup unless
they are the only declaration of the entity. (We already mostly did
this for local extern declarations.)
llvm-svn: 350505
Summary:
The documentation for RecursiveASTVisitor::TraverseDecl states that the
Decl being traversed may be null. In fact, this is the case when a
CXXCatchStmt with no exception decl is traversed. Because the visitor
for diagnosing unexpanded parameter packs does not check for null, it
ends up crashing when it attempts to call the Decl::isParameterPack
method on a null Decl pointer.
Add a null check to prevent an ICE, and a test case that would crash
otherwise. Also, because the test requires C++ exceptions and C++14,
change the test parameters for the entire test file. (Alternatively, I
thought about adding a new test file, but went with this approach for my
own convenience.)
Co-authored-by: Andreas Molzer <andreas.molzer@gmx.de>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56271
llvm-svn: 350501
Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement.
This patch fixes PR39837.
llvm-svn: 350404
Qualifiers can now be streamed into the DiagnosticEngine using
regular << operator. If Qualifiers are empty 'unqualified' will
be printed in the diagnostic otherwise regular qual syntax is
used.
Differential Revision: https://reviews.llvm.org/D56198
llvm-svn: 350386
functions that are unavailable on Darwin are explicitly called or called
from deleting destructors.
rdar://problem/40736230
Differential Revision: https://reviews.llvm.org/D47757
llvm-svn: 349890
When checking that the array access is not out-of-bounds in CheckArrayAccess
it is possible that the type of the base expression after IgnoreParenCasts is
incomplete, even though the type of the base expression before IgnoreParenCasts
is complete. In this case we have no information about whether the array access
is out-of-bounds and we should just bail-out instead. This fixes PR39746 which
was caused by trying to obtain the size of an incomplete type.
Differential Revision: https://reviews.llvm.org/D55862
Reviewed By: efriedma
llvm-svn: 349811
Summary:
The pattern is problematic with C++ exceptions, and not as widespread as
scoped locks, but it's still used by some, for example Chromium.
We are a bit stricter here at join points, patterns that are allowed for
scoped locks aren't allowed here. That could still be changed in the
future, but I'd argue we should only relax this if people ask for it.
Fixes PR36162.
Reviewers: aaron.ballman, delesley, pwnall
Reviewed By: delesley, pwnall
Subscribers: pwnall, cfe-commits
Differential Revision: https://reviews.llvm.org/D52578
llvm-svn: 349300
This reverts commit 46efdf2ccc2a80aefebf8433dbf9c7c959f6e629.
Richard Smith commented just after I submitted this that this is the
wrong solution. Reverting so that I can fix differently.
llvm-svn: 349206
Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
conversions from nullptr_t be equal to nullptr.
However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.
Differential Revision: https://reviews.llvm.org/D53713
Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885
llvm-svn: 349201
Summary:
This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC.
I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables.
Reviewers: rnk, majnemer, rsmith
Reviewed By: rsmith
Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek
Differential Revision: https://reviews.llvm.org/D40218
llvm-svn: 349195
Summary:
`memchr` and `memcmp` operate upon the character units of the object
representation; that is, the `size_t` parameter expresses the number of
character units. The constant folding implementation is updated in this
patch to account for multibyte element types in the arrays passed to
`memchr`/`memcmp` and, in the case of `memcmp`, to account for the
possibility that the arrays may have differing element types (even when
they are byte-sized).
Actual inspection of the object representation is not implemented.
Comparisons are done only between elements with the same object size;
that is, `memchr` will fail when inspecting at least one character unit
of a multibyte element. The integer types are assumed to have two's
complement representation with 0 for `false`, 1 for `true`, and no
padding bits.
`memcmp` on multibyte elements will only be able to fold in cases where
enough elements are equal for the answer to be 0.
Various tests are added to guard against incorrect folding for cases
that miscompile on some system or other prior to this patch. At the same
time, the unsigned 32-bit `wchar_t` testing in
`test/SemaCXX/constexpr-string.cpp` is restored.
Reviewers: rsmith, aaron.ballman, hfinkel
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55510
llvm-svn: 348938
Friend function template defined in a class template becomes available if
the enclosing class template is instantiated. Until the function template
is used, it does not have a body, but still is considered a definition for
the purpose of redeclaration checks.
This change modifies redefinition check so that it can find the friend
function template definitions in instantiated classes.
Differential Revision: http://reviews.llvm.org/D21508
llvm-svn: 348473
We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead.
llvm-svn: 348400
We should have been checking that this state is consistent, but its
possible for it to be filled later, so it isn't really sound to check
it here anyways.
Fixes llvm.org/PR39742
llvm-svn: 348325
Summary:
In our codebase, `static_assert(std::some_type_trait<Ts...>::value, "msg")`
(where `some_type_trait` is an std type_trait and `Ts...` is the
appropriate template parameters) account for 11.2% of the `static_assert`s.
In these cases, the `Ts` are typically not spelled out explicitly, e.g.
`static_assert(std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value, "message");`
The diagnostic when the assert fails is typically not very useful, e.g.
`static_assert failed due to requirement 'std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value' "message"`
This change makes the diagnostic spell out the types explicitly , e.g.
`static_assert failed due to requirement 'std::is_same<int, float>::value' "message"`
See tests for more examples.
After this is submitted, I intend to handle
`static_assert(!std::some_type_trait<Ts...>::value, "msg")`,
which is another 6.6% of static_asserts.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54903
llvm-svn: 348239
headers.
Previously, we would only check whether the new declaration is in a
system header, but that requires the user to be able to correctly guess
whether a declaration in a system header is declared as a struct or a
class when specializing standard library traits templates.
We now entirely ignore declarations for which the warning was disabled
when determining whether to warn on a tag mismatch.
Also extend the diagnostic message to clarify that
a) code containing such a tag mismatch is in fact valid and correct,
and
b) the (non-coding-style) reason to emit such a warning is that the
Microsoft C++ ABI is broken and includes the tag kind in decorated
names,
as it seems a lot of users are confused by our diagnostic here (either
not understanding why we produce it, or believing that it represents an
actual language rule).
llvm-svn: 348233
It seems the two failing tests can be simply fixed after r348037
Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now
llvm-svn: 348053
Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:
extern char extern_var;
struct { int a; } a = {__builtin_constant_p(extern_var)};
llvm-svn: 348039
This moves everything primarily testing the functionality of -ast-dump and -ast-print into their own directory, rather than leaving the tests spread around the testing directory.
llvm-svn: 348017
This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.
llvm-svn: 347756
Summary:
Resubmit this with no changes because I think the build was broken
by a different diff.
-----
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff
clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp
----- Summary from Previous Diff (Still Accurate) -----
LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function basis.
This can be applied to functions and Objective C methods.
Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54915
llvm-svn: 347701
This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:
static bool f(int *a, int *b) {
return !__builtin_constant_p(b - a) || (!(b - a));
}
int arr[] = {1,2,3};
bool g() {
return f(arr, arr + 3);
}
$ clang -O2 -S -emit-llvm a.cc -o -
g() should return true, but after r347417 it became false for some reason.
This also reverts the follow-up commits.
r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!
r347446:
> The result of is.constant() is unsigned.
r347480:
> A __builtin_constant_p() returns 0 with a function type.
r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.
r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.
llvm-svn: 347656
until I figure out why the build is failing or timing out
***************************
Summary:
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff
clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp
LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function
basis.
This can be applied to functions and Objective C methods.
Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54915
This reverts commit a5b3c232d1e3613f23efbc3960f8e23ea70f2a79.
(r347617)
llvm-svn: 347628
Summary:
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff
clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp
----- Summary from Previous Diff (Still Accurate) -----
LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function basis.
This can be applied to functions and Objective C methods.
Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54915
llvm-svn: 347617
Summary:
LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function basis.
This can be applied to functions and Objective C methods.
Reviewers: chandlerc, echristo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54555
llvm-svn: 347586
Assume that we're in a constant context if we're asking if the expression can
be compiled into a constant initializer. This fixes the issue where a
__builtin_constant_p() in a compound literal was diagnosed as not being
constant, even though it's always possible to convert the builtin into a
constant.
llvm-svn: 347512
Summary:
A __builtin_constant_p may end up with a constant after inlining. Use
the is.constant intrinsic if it's a variable that's in a context where
it may resolve to a constant, e.g., an argument to a function after
inlining.
Reviewers: rsmith, shafik
Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight
Differential Revision: https://reviews.llvm.org/D54355
llvm-svn: 347294
If PerformConstructorInitialization of a direct initializer list constructor is
called while instantiating a template, it has brace locations in its BraceLoc
arguments but not in the Kind argument.
This reverts the hunk https://reviews.llvm.org/D41921#inline-468844.
Patch by Orivej Desh!
Differential Revision: https://reviews.llvm.org/D53231
llvm-svn: 347261
There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to
choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example,
typedef float __v4sf __attribute__((__vector_size__(16)));
void f(vector float);
void f(vector signed int);
int main {
__v4sf a;
f(a);
}
Here, we'd like to choose f(vector float) but not report an ambiguous call error.
Differential revision: https://reviews.llvm.org/D53417
llvm-svn: 347019
This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
This matches a similar behavior with GCC accepting [[gnu::__attr__]] as a alias for [[gnu::attr]] in that clang attributes can now be spelled with two leading and trailing underscores.
I had always intended for this to work, but missed the critical bit. We already had an existing test in test/Preprocessor/has_attribute.cpp for [[clang::__fallthrough__]] but using that spelling would still give an "unknown attribute" diagnostic.
llvm-svn: 346547
Currently, we only accept clang as the scoped attribute identifier for double square bracket attributes provided by Clang, but this has the potential to conflict with user-defined macros. To help alleviate these concerns, this introduces the _Clang scoped attribute identifier as an alias for clang. It also introduces a warning with a fixit on the off chance someone attempts to use __clang__ as the scoped attribute (which is a predefined compiler identification macro).
llvm-svn: 346521
Summary:
Compound literals, enums, file-scoped arrays, etc. require their
initializers and size specifiers to be constant. Wrap the initializer
expressions in a ConstantExpr so that we can easily check for this later
on.
Reviewers: rsmith, shafik
Reviewed By: rsmith
Subscribers: cfe-commits, jyknight, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D53921
llvm-svn: 346455
Summary:
Previously the TemplateSpecialization instance for 'template_alias', in the example below, returned the type info of the canonical type (int). This ignored the type alias if the template type happen to be aliased.
Before this patch, the assert would trigger with an alignment of 4:
```
typedef int __attribute__(( aligned( 16 ) )) aligned_int;
template < typename >
using template_alias = aligned_int;
static_assert( alignof( template_alias<void>) == 16, "" );
```
This patch checks if the TemplateSpecialization type has an alias, and if so will return the type information for the aliased type, else the canonical type's info is returned (original behavior). I believe that this is the desired behavior.
Reviewers: aaron.ballman, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54048
llvm-svn: 346146
Summary:
The test case added in this diff would incorrectly warn that control
flow may fall through without returning. Here's a standalone example:
https://godbolt.org/z/dCwXEi
The same program, but using `return` instead of `co_return`, does not
produce a warning: https://godbolt.org/z/mVldqQ
The issue was in how Clang analysis would structure its representation
of the control-flow graph. Specifically, when constructing the CFG,
`CFGBuilder::Visit` had special handling of a `ReturnStmt`, in which it
would place object destructors in the same CFG block as a `return` statement,
immediately after it. Doing so would allow the logic in
`lib/Sema/AnalysisBasedWarning.cpp` `CheckFallThrough` to work properly in the
program that used `return`, correctly determining that no "plain edges" preceded
the exit block of the function.
Because a `co_return` statement would not enjoy the same treatment when
it was being built into the control-flow graph, object destructors
would not be placed in the same CFG block as the `co_return`, thus
resulting in a "plain edge" preceding the exit block of the function,
and so the warning logic would be triggered.
Add special casing for `co_return` to Clang analysis, thereby
remedying the mistaken warning.
Test Plan: `check-clang`
Reviewers: GorNishanov, tks2103, rsmith
Reviewed By: GorNishanov
Subscribers: EricWF, lewissbaker, cfe-commits
Differential Revision: https://reviews.llvm.org/D54075
llvm-svn: 346074
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof
Patch by Nicole Mazzuca!
Differential Revision: https://reviews.llvm.org/D53207
llvm-svn: 345419
Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.
```
int main() {
int a;
auto f = [a](int a) { return a; };
}
```
results in:
```
main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity
auto f = [a](int a) { return a; };
^
main.cpp:3:13: note: variable a is explicitly captured here
auto f = [a](int a) { return a; };
^
```
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53595
llvm-svn: 345308
Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53508
llvm-svn: 345296
MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope.
This avoids a compile-time crash due to confusing a member access for a constructor name.
Test case included. All tests pass.
Differential Revision: https://reviews.llvm.org/D53441
llvm-svn: 345258
There is a small difference in the scope flags for C89 versus the other C/C++
dialects. This change ensures that the -Wcomma warning won't be duplicated or
issued in the wrong location. Also, the test case is refactored into C and C++
parts, with the C++ parts guarded by a #ifdef to allow the test to run in both
modes.
https://bugs.llvm.org/show_bug.cgi?id=32370
llvm-svn: 345228
Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53508
llvm-svn: 345211
When there is a dependent type inside a cast, the CastKind becomes CK_Dependent
instead of CK_ToVoid. This fix will check that there is a dependent cast,
the original type is dependent, and the target type is void to ignore the cast.
https://bugs.llvm.org/show_bug.cgi?id=39375
llvm-svn: 345111
Amends r344259 so that enumerators shadowing types are not diagnosed, as shadowing under those circumstances is rarely (if ever) an issue in practice.
llvm-svn: 344898
For now, disable the "variable in loop condition not modified" warning to not
be emitted when there is a structured binding variable in the loop condition.
https://bugs.llvm.org/show_bug.cgi?id=39285
llvm-svn: 344828
Rather, they are subexpressions of the enclosing lambda-expression, and
any temporaries in them are destroyed at the end of that
full-expression, or when the corresponding lambda-expression is
destroyed if they are lifetime-extended.
llvm-svn: 344801
The test added in r344146 was failing because the ABI on Windows is
different, and that test includes ABI-specific details. The test now
harcodes which ABI to use so we can rely on those details.
llvm-svn: 344159
The problem was that MergeFunctionDecl sometimes needs the injected template
arguments of a FunctionTemplateDecl, but is called before adding the new
template to the redecl chain. This leads to multiple common pointers in the same
redecl chain, each with their own identical instantiation. Fix this by merging
the the common state before inserting the new template into the redecl chain.
rdar://44810129
Differential revision: https://reviews.llvm.org/D53046
llvm-svn: 344157
Summary:
Addressing https://bugs.llvm.org/show_bug.cgi?id=37265.
Implements [class.copy]/33 of coroutines TS.
When the criteria for elision of a copy/move operation are met, but not
for an exception-declaration, and the object to be copied is designated by an
lvalue, or when the expression in a return or co_return statement is a
(possibly parenthesized) id-expression that names an object with automatic
storage duration declared in the body or parameter-declaration-clause of the
innermost enclosing function or lambda-expression, overload resolution to select
the constructor for the copy or the return_value overload to call is first
performed as if the object were designated by an rvalue.
Patch by Tanoy Sinha!
Reviewers: modocache, GorNishanov
Reviewed By: modocache, GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51741
llvm-svn: 343949
Summary:
We unwrap conditional expressions containing try-lock functions.
Additionally we don't acquire on conditional expression branches, since
that is usually not helpful. When joining the branches we would almost
certainly get a warning then.
Hopefully fixes an issue that was raised in D52398.
Reviewers: aaron.ballman, delesley, hokein
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52888
llvm-svn: 343902
The comment said it was intentionally not emitting any diagnostic
because the declaration itself was already diagnosed. However,
everywhere else that wants to not emit a diagnostic without an extra
note emits note_invalid_subexpr_in_const_expr instead, which gets
suppressed later.
This was the only place which did not emit a diagnostic note.
Differential Revision: https://reviews.llvm.org/D52919
llvm-svn: 343867
Summary:
Instead of only examining call arguments, we also examine constructor
arguments applying the same rules.
That was an opportunity for refactoring the examination procedure to
work with iterators instead of integer indices. For the case of
CallExprs no functional change is intended.
Reviewers: aaron.ballman, delesley
Reviewed By: delesley
Subscribers: JonasToth, cfe-commits
Differential Revision: https://reviews.llvm.org/D52443
llvm-svn: 343831
Summary:
This attribute allows excluding a member of a class template from being part
of an explicit template instantiation of that class template. This also makes
sure that code using such a member will not take for granted that an external
instantiation exists in another translation unit. The attribute was discussed
on cfe-dev at [1] and is primarily motivated by the removal of always_inline
in libc++ to control what's part of the ABI (see links in [1]).
[1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html
rdar://problem/43428125
Reviewers: rsmith
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51789
llvm-svn: 343790
Fix code for constant evaluation of __builtin_memcpy() and
__builtin_memmove() that would attempt to divide by zero when given two
pointers to an incomplete array.
Differential Revision: https://reviews.llvm.org/D51855
llvm-svn: 343761
Richard Smith