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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257254 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256661 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256601 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256575 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256511 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256037 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254663 91177308-0d34-0410-b5e6-96231b3b80d8
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253283 91177308-0d34-0410-b5e6-96231b3b80d8
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++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252960 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248953 91177308-0d34-0410-b5e6-96231b3b80d8
Such declarations would be invalid anyway, and trying to make the
correction will lead to a crash. Fixes PR 24781.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248928 91177308-0d34-0410-b5e6-96231b3b80d8
for an existing entity, and as such a using-declaration doesn't need to
conflict with a hidden entity (nor vice versa).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247654 91177308-0d34-0410-b5e6-96231b3b80d8
whether it can ever produce a constant expression in the case where it has a
void return type and no return statements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246347 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245139 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243217 91177308-0d34-0410-b5e6-96231b3b80d8
The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obscure. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241300 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239375 91177308-0d34-0410-b5e6-96231b3b80d8
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239373 91177308-0d34-0410-b5e6-96231b3b80d8
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
(This is a step towards fixing PR21718.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239372 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we wouldn't call checkDLLAttribute() after the class template
specialization definition if the class template was already instantiated
by an explicit class template specialization declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238266 91177308-0d34-0410-b5e6-96231b3b80d8
The method wasn't an overrider but didn't have 'virtual' textually
written because our CXXMethodDecl was an out-of-line definition. Make
sure we use the canonical decl instead.
This fixes PR23629.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237999 91177308-0d34-0410-b5e6-96231b3b80d8
We now use an enum which maps the marketing name (almost always a year)
to the major version number.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236967 91177308-0d34-0410-b5e6-96231b3b80d8
This affects this test case:
void foo();
template <typename T> class C {
friend inline void foo();
};
inline void foo() {}
C<int> c;
Here, we instantiate the foo friend decl and add it to foo's redecl
chain. However, our previous decl pointer happens to reference the first
declaration of foo, which is not marked inline. When we check to see if
foo was already defined, we implicitly search all previous decls. We
should do the same for the inline check, instead of just checking this
particular previous decl.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D8872
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234374 91177308-0d34-0410-b5e6-96231b3b80d8
constructors, instead of having the typo-correction code also dispatch to the
inheriting constructor special case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233833 91177308-0d34-0410-b5e6-96231b3b80d8
Xiuli Pan