| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
account MSVC compatibility version
Clang creates implicit move constructor/assign operator in all cases if
there is std=c++11. But MSVC supports such generation starting from
version 1900 only. As result we have some binary incompatibility.
Differential Revision: http://reviews.llvm.org/D19156
Patch by Andrew V. Tischenko
llvm-svn: 269400
|
|
|
|
|
|
|
|
|
| |
a base class via a using-declaration. If a class has a using-declaration
declaring either a constructor or an assignment operator, eagerly declare its
special members in case they need to displace a shadow declaration from a
using-declaration.
llvm-svn: 269398
|
|
|
|
|
|
|
|
|
| |
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.
llvm-svn: 269231
|
|
|
|
|
|
| |
using-declaration that names a class-scope enumerator.
llvm-svn: 268664
|
|
|
|
|
|
|
|
|
|
|
| |
enumerators:
* an unscoped enumerator whose enumeration is a class member is itself a class
member, so can only be the subject of a class-scope using-declaration.
* a scoped enumerator cannot be the subject of a class-scope using-declaration.
llvm-svn: 268594
|
|
|
|
|
|
|
|
|
|
|
| |
Fix crash in BuildCXXDefaultInitExpr when member of template class has
same name as the class itself.
Based on patch by Raphael "Teemperor" Isemann!
Differential Revision: http://reviews.llvm.org/D19721
llvm-svn: 268082
|
|
|
|
|
|
| |
is used (PR27319)
llvm-svn: 266242
|
|
|
|
|
|
| |
Patch by Erik Pilkington!
llvm-svn: 265571
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a prior UsingDecl -- those should not even really be found by the lookup
here, except that we use the same lookup results for two different checks, and
the other check needs them.
This happens to work in *almost all* cases, because either the lookup results
list the UsingDecl first (and the NonTag result gets replaced by something
else) or because the problematic declaration is a function (which causes us to
use different logic to detect conflicts). This can also be triggered from a
state only reachable through modules (where the name lookup results can contain
multiple UsingDecls in the same scope).
llvm-svn: 262105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relands r260194 with a fix. If we have a template that transitions from
an extern template to an explicitly instantiated dllexport template, we
would add that class to the delayed exported class list without flushing
it.
For explicit instantiations, we can just flush the list of delayed
classes immediately. We don't have to worry about the bug fixed in
r260194 in this case because explicit instantiations can only occur at
file and namespace scope.
Fixes PR26490.
llvm-svn: 262056
|
|
|
|
|
|
| |
Patch by Erik Pilkington!
llvm-svn: 261034
|
|
|
|
|
|
| |
No functional change is intended.
llvm-svn: 258769
|
|
|
|
|
|
|
|
|
|
| |
Per C++14 [class.virtual]p8, it is OK for the return type's class type
to be incomplete so long as the return type is the same between the base
and complete classes.
This fixes PR26297.
llvm-svn: 258768
|
|
|
|
|
|
|
|
|
|
| |
We were emitting diagnostics from our shiny new C-only overload
resolution mode. This patch attempts to silence all such diagnostics.
This fixes PR26085.
Differential Revision: http://reviews.llvm.org/D16159
llvm-svn: 257710
|
|
|
|
|
|
| |
equivalent internal linkage entities.
llvm-svn: 257512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI emits a special default constructor closure thunk if a
default constructor has a weird calling convention or default arguments.
The MS ABI has a quirk: there can be only one such thunk because the
mangling scheme does not have room for distinct manglings. We must
raise a diagnostic in this eventuality.
N.B. MSVC sorta gets this right. Multiple default constructors result
in the default constructor closure getting emitted but they seem to
get confused by which default constructors are reasonable to reference
from the closure. We try to be a little more careful which results in
mild differences in behavior.
llvm-svn: 256661
|
|
|
|
|
|
| |
the using declaration not at the thing it's using.
llvm-svn: 256602
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
llvm-svn: 256601
|
|
|
|
|
|
|
|
|
|
| |
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
llvm-svn: 256575
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes PR16677. The latter represents the case when due to
misprinted character class definition occurs in the scope of template
arguments. Base class of this class depends on the template parameter in the
same scope and cannot be resolved, it causes crash. Right behavior is to
make semantic processing even if the definition is wrong, as the code
that emits appropriate message is called after the processing.
llvm-svn: 256511
|
|
|
|
| |
llvm-svn: 256478
|
|
|
|
|
|
| |
It broke lldb build.
llvm-svn: 256403
|
|
|
|
| |
llvm-svn: 256399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
llvm-svn: 256049
|
|
|
|
|
|
|
|
| |
for the derived class into it. This is mostly just a cleanup, but could in
principle be a bugfix if there is some codepath that reaches here and didn't
previously require a complete type (I couldn't find any such codepath, though).
llvm-svn: 256037
|
|
|
|
|
|
| |
initializer list to name a base class. Patch by Shahms King!
llvm-svn: 255420
|
|
|
|
|
|
|
|
|
|
| |
nested) for all the platforms except PS4.
For PS4, generate explicit import for anonymous namespaces and mark it by DW_AT_artificial attribute.
Differential Revision: http://reviews.llvm.org/D12624
llvm-svn: 255281
|
|
|
|
|
|
|
|
|
| |
do scope-based lookup when looking for redeclarations of them. Add some related
missing checks for the scope-based redeclaration lookup: properly filter the
list of found declarations to match the scope, and diagnose shadowing of a
template parameter name.
llvm-svn: 254663
|
|
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
|
|
|
| |
llvm-svn: 253155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
llvm-svn: 252960
|
|
|
|
| |
llvm-svn: 252793
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 250935
|
|
|
|
|
|
|
|
|
|
| |
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replace empty bodies of default constructors and destructors with '= default'.
Reviewers: bkramer, klimek
Subscribers: klimek, alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D13890
llvm-svn: 250822
|
|
|
|
| |
llvm-svn: 249259
|
|
|
|
|
|
|
|
|
|
| |
Unqualified templated constructors cannot be friended and our lack of a
diagnostic led to violated invariants. Instead, raise a diagnostic when
processing the friend declaration.
This fixes PR20251.
llvm-svn: 248953
|
|
|
|
|
|
|
| |
Such declarations would be invalid anyway, and trying to make the
correction will lead to a crash. Fixes PR 24781.
llvm-svn: 248928
|
|
|
|
|
|
|
| |
for an existing entity, and as such a using-declaration doesn't need to
conflict with a hidden entity (nor vice versa).
llvm-svn: 247654
|
|
|
|
|
|
|
|
| |
constructor or destructor function-try-block, which is UB in C++.
This corresponds to the CERT secure coding rule ERR53-CPP.
llvm-svn: 246548
|
|
|
|
|
|
|
| |
whether it can ever produce a constant expression in the case where it has a
void return type and no return statements.
llvm-svn: 246347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR23542)
This enables Clang to correctly handle code such as:
struct __declspec(dllexport) S {
int x = 42;
};
where it would otherwise error due to trying to generate the default
constructor before the in-class initializer for x has been parsed.
Differential Revision: http://reviews.llvm.org/D11850
llvm-svn: 245139
|
|
|
|
|
|
|
|
|
| |
This lets us pass functors (and lambdas) without void * tricks. On the
downside we can't pass CXXRecordDecl's Find* members (which are now type
safe) to lookupInBases directly, but a lambda trampoline is a small
price to pay. No functionality change intended.
llvm-svn: 243217
|
|
|
|
| |
llvm-svn: 242670
|
|
|
|
|
|
| |
We now check for the exact range of IdealIndex.
llvm-svn: 242652
|
|
|
|
|
|
| |
This (hopefully) brings more clarity. No functional changes (intended).
llvm-svn: 242483
|
|
|
|
|
|
|
|
|
| |
++range)‘ pattern to range for loops.
The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obscure. No functionality change intended.
llvm-svn: 241300
|
|
|
|
|
|
| |
disambiguation in the parser rather than trying to do it in Sema.
llvm-svn: 241032
|
|
|
|
| |
llvm-svn: 240353
|