This change fixes a crash on initialization of a reference from ({}) during
template instantiation and incidentally improves diagnostics.
This reverts a prior attempt to handle this in r286721. Instead, we teach the
initialization code that initialization cannot be performed if a source type
is required and the initializer is an initializer list (which is not an
expression and does not have a type), and likewise for function-style cast
expressions.
llvm-svn: 298676
instantiation.
In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).
llvm-svn: 295686
After r260016 and r260017 disabled typo correction for ivars and properties
clang didn't report errors about unresolved identifier in the base of ivar and
property ref expressions. This meant that clang invoked CodeGen on invalid AST
which then caused a crash.
This commit re-enables typo correction for ivars and properites, and fixes the
PR25113 & PR26486 (that were originally fixed in r260017 and r260016) in a
different manner by transforming the Objective-C ivar reference expression with
'IsFreeIvar' preserved.
rdar://30310772
llvm-svn: 294008
This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)
This fixes PR31638, PR31639, and PR31640.
Differential Revision: https://reviews.llvm.org/D28889
llvm-svn: 293360
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
This commit improves the mismatched destructor type error by detecting when the
destructor call has used a '.' instead of a '->' on a pointer to the destructed
type. The diagnostic now suggests to use '->' instead of '.', and adds a fixit
where appropriate.
rdar://28766702
Differential Revision: https://reviews.llvm.org/D25817
llvm-svn: 292615
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).
As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).
When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.
llvm-svn: 292518
Summary:
Warn when a lambda explicitly captures something that is not used in its body.
The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture.
Reviewers: rsmith, arphaman, jbcoe, aaron.ballman
Subscribers: Quuxplusone, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D28467
llvm-svn: 291905
This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.
No functionality change intended.
llvm-svn: 291737
Most code paths would already bail out in this case, but certain paths,
particularly overload resolution and typo correction, would not. Carrying on
with an invalid declaration could in some cases result in crashes due to
downstream code relying on declaration invariants that are not necessarily
met for invalid declarations, and in other cases just resulted in undesirable
follow-on diagnostics.
llvm-svn: 291030
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.
llvm-svn: 290203
This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.
Replied on the commit with more details.
llvm-svn: 290173
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.
Reviewers: Anastasia
Subscribers: cfe-commits, yaxunl, bader
Differential Revision: https://reviews.llvm.org/D27569
llvm-svn: 290171
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
llvm-svn: 290080
constructs that can do so into the initialization code. This fixes a number
of different cases in which we used to fail to check for abstract types.
Thanks to Tim Shen for inspiring the weird code that uncovered this!
llvm-svn: 289753
Although not specifically mentioned in the documentation, MSVC accepts
__uuidof(…) and declspec(uuid("…")) attributes on enumeration types in
addition to structs/classes. This is meaningful, as such types *do* have
associated UUIDs in ActiveX typelibs, and such attributes are included
by default in the wrappers generated by their #import construct, so they
are not particularly unusual.
clang currently rejects the declspec with a –Wignored-attributes
warning, and errors on __uuidof() with “cannot call operator __uuidof on
a type with no GUID” (because it rejected the uuid attribute, and
therefore finds no value). This is causing problems for us while trying
to use clang-tidy on a codebase that makes heavy use of ActiveX.
I believe I have found the relevant places to add this functionality,
this patch adds this case to clang’s implementation of these MS
extensions. patch is against r285994 (or actually the git mirror
80464680ce).
Both include an update to test/Parser/MicrosoftExtensions.cpp to
exercise the new functionality.
This is my first time contributing to LLVM, so if I’ve missed anything
else needed to prepare this for review just let me know!
__uuidof: https://msdn.microsoft.com/en-us/library/zaah6a61.aspx
declspec(uuid("…")): https://msdn.microsoft.com/en-us/library/3b6wkewa.aspx
#import: https://msdn.microsoft.com/en-us/library/8etzzkb6.aspx
Reviewers: aaron.ballman, majnemer, rnk
Differential Revision: https://reviews.llvm.org/D26846
llvm-svn: 289567
mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.
In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.
llvm-svn: 289250
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.
llvm-svn: 288866
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
llvm-svn: 288301
Since r274049, for an inheriting constructor declaration, the name of the using
declaration (and using shadow declaration comes from the using declaration) is
the name of a derived class, not the base class (line 8225-8232 of
lib/Sema/SemaDeclCXX.cpp in https://reviews.llvm.org/rL274049). Because of
this, name-based lookup performed inside Sema::LookupConstructors returns not
only CXXConstructorDecls but also Using(Shadow)Decls, which results assertion
failure reported in PR29087.
Patch by Taewook Oh, thanks!
Differential Revision: https://reviews.llvm.org/D23765
llvm-svn: 287999
Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.
Fixes PR31121
Reviewers: thakis, rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27007
llvm-svn: 287774
If initializer contains parentheses around braced list where it is not allowed,
as in construct int({0}), clang issued message like `functional-style cast
from 'void' to 'int' is not allowed`, which does not help much. Both gcc and
msvc issue message `list-initializer for non-class type must not be
parenthesized`, which is more descriptive. This change implements similar
message for clang.
Differential Revision: https://reviews.llvm.org/D25816
llvm-svn: 286721
Clang emits error message for the following code:
```
template <class F> void parallel_loop(F &&f) { f(0); }
int main() {
int x;
parallel_loop([&](auto y) {
{
x = y;
};
});
}
```
$ clang++ --std=gnu++14 clang_test.cc -o clang_test
clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
x = y;
^
clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
template <class F> void parallel_loop(F &&f) { f(0); }
^
clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
^
clang_test.cc:5:7: note: 'x' declared here
int x;
^
1 error generated.
Patch fixes this issue.
llvm-svn: 286584
mismatched dynamic exception specifications in expressions from an error to a
warning, since this is no longer ill-formed in C++1z.
Allow reference binding of a reference-to-non-noexcept function to a noexcept
function lvalue. As defect resolutions, also allow a conditional between
noexcept and non-noexcept function lvalues to produce a non-noexcept function
lvalue (rather than decaying to a function pointer), and allow function
template argument deduction to deduce a reference to non-noexcept function when
binding to a noexcept function type.
llvm-svn: 284905
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
This is a re-commit of r284800.
llvm-svn: 284890
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
llvm-svn: 284800
Original commit message:
[c++1z] Teach composite pointer type computation how to compute the composite
pointer type of two function pointers with different noexcept specifications.
While I'm here, also teach it how to merge dynamic exception specifications.
llvm-svn: 284785
pointer type of two function pointers with different noexcept specifications.
While I'm here, also teach it how to merge dynamic exception specifications.
llvm-svn: 284753
Summary:
Together these let you easily create diagnostics that
- are never emitted for host code
- are always emitted for __device__ and __global__ functions, and
- are emitted for __host__ __device__ functions iff these functions are
codegen'ed.
At the moment there are only three diagnostics that need this treatment,
but I have more to add, and it's not sustainable to write code for emitting
every such diagnostic twice, and from a special wrapper in SemaCUDA.cpp.
While we're at it, don't emit the function name in
err_cuda_device_exceptions: It's not necessary to print it, and making
this work in the new framework in the face of a null value for
dyn_cast<FunctionDecl>(CurContext) isn't worth the effort.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D25139
llvm-svn: 284143
match other CUDA preference orders, per discussion with jlebar. We now model
this in an attempt to match overload resolution as closely as possible:
- First, we throw out all non-callable (due to CUDA host/device mismatch)
operator delete functions.
- Then we apply sizedness / alignedness preferences based on whether the type
is overaligned and whether the deallocation function is a member.
- Finally, we use the CUDA callability preference as a tiebreaker.
llvm-svn: 283830
CheckSingleAssignmentConstraints. These no longer produce ExprError() when they
have not emitted an error, and reliably inform the caller when they *have*
emitted an error.
This fixes some serious issues where we would fail to emit any diagnostic for
invalid code and then attempt to emit code for an invalid AST, and conversely
some issues where we would emit two diagnostics for the same problem.
llvm-svn: 283508
new expression, distinguish between the case of a constant and non-constant
initializer. In the former case, if the bound is erroneous (too many
initializer elements, bound is negative, or allocated size overflows), reject,
and take the bound into account when determining whether we need to
default-construct any elements. In the remanining cases, move the logic to
check for default-constructibility of trailing elements into the initialization
code rather than inventing a bogus array bound, to cope with cases where the
number of initialized elements is not the same as the number of initializer
list elements (this can happen due to string literal initialization or brace
elision).
This also fixes rejects-valid and crash-on-valid errors when initializing a
new'd array of character type from a braced string literal.
llvm-svn: 283406
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.
llvm-svn: 282974
