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
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
FunctionDecls.
This commit silences an incorrect warning that is issued when a function
pointer is cast to another function pointer type. The warning gets
issued because alignments of the source and destination do not match in
Sema::CheckCastAlign, which happens because ASTContext::getTypeInfoImpl
and ASTContext::getDeclAlign return different values for functions (the
former returns 4 while the latter returns 1).
This should fix PR31558.
rdar://problem/29533528
Differential Revision: https://reviews.llvm.org/D27478
llvm-svn: 291253
Summary:
We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir.
On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis.
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits
Differential Revision: https://reviews.llvm.org/D28048
llvm-svn: 290436
* In C++, never create a FunctionNoProtoType for a builtin (fixes C++1z
crasher from r289754).
* Fix type of __sync_synchronize to be a no-parameter function rather than a
varargs function. This matches GCC.
* Fix type of vfprintf to match its actual type. We gave it a wrong type due
to PR4290 (apparently autoconf generates invalid code and expects compilers
to choke it down or it miscompiles the program; the relevant error in clang
was downgraded to a warning in r122744 to fix other occurrences of this
autoconf brokenness, so we don't need this workaround any more).
* Turn off vararg argument checking for __noop, since it's not *really* a
varargs function. Alternatively we could add custom type checking for it
and synthesize parameter types matching the actual arguments in each call,
but that seemed like overkill.
llvm-svn: 290146
* a dependent non-type using-declaration within a function template can be
valid, as it can refer to an enumerator, so don't reject it in the template
definition
* we can partially substitute into a dependent using-declaration if it appears
within a (local class in a) generic lambda within a function template, which
means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl.
llvm-svn: 290071
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.
Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.
Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.
Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.
This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.
This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.
Differential Revision: https://reviews.llvm.org/D26196
llvm-svn: 289252
This adds the access qualifier to the Pipe Type, rather than using a class
hierarchy.
It also fixes mergeTypes for Pipes, by disallowing merges. Only identical
pipe types can be merged. The test case in invalid-pipes-cl2.0.cl is added
to check that.
llvm-svn: 288332
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
Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:
void test(int values[_Nullable]);
This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:
#if __has_feature(nullability_on_arrays)
One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.
This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:
#pragma clang assume_nonnull begin
void test(void *pointers[]);
#pragma clang assume_nonnull end
void test(void * _Nonnull pointers[]);
This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.
Part of rdar://problem/25846421
llvm-svn: 286519
Extend lifetime of ExceptionTypeStorage, as it is referenced by
CanonicalEPI and used outside the block (ExceptionSpec.Exceptions is an
ArrayRef)
Patch by Sam McCall!
Differential Revision: https://reviews.llvm.org/D25983
llvm-svn: 285192
This has the following ABI impact:
1) Functions whose parameter or return types are non-throwing function pointer
types have different manglings in c++1z mode from prior modes. This is
necessary because c++1z permits overloading on the noexceptness of function
pointer parameter types. A warning is issued for cases that will change
manglings in c++1z mode.
2) Functions whose parameter or return types contain instantiation-dependent
exception specifications change manglings in all modes. This is necessary
to support overloading on / SFINAE in these exception specifications, which
a careful reading of the standard indicates has essentially always been
permitted.
Note that, in order to be affected by these changes, the code in question must
specify an exception specification on a function pointer/reference type that is
written syntactically within the declaration of another function. Such
declarations are very rare, and I have so far been unable to find any code
that would be affected by this. (Note that such things will probably become
more common in C++17, since it's a lot easier to get a noexcept function type
as a function parameter / return type there.)
This change does not affect the set of symbols produced by a build of clang,
libc++, or libc++abi.
llvm-svn: 285150
dependent noexcept specifications result in the same canonical function type.
We still use non-canonical hashing when deduplicating type sugar so that
diagnostics will point to the right place.
llvm-svn: 284457
This reverts commit r284176. It still marks some modules as invisible
that should be visible. Will follow up with the author with a test case.
llvm-svn: 284382
compiles without -fmodules-local-submodule-visibility. Original commit message:
[modules] When merging one definition into another, propagate the list of
re-exporting modules from the discarded definition to the retained definition.
llvm-svn: 284176
Summary: It doesn't need to be refcounted anymore, either.
Reviewers: timshen
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25420
llvm-svn: 283768
For ObjC type parameter, we used to have TypedefType that is canonicalized to
id or the bound type. We can't represent "T <protocol>" and thus will lose
the type information in the following example:
@interface MyMutableDictionary<KeyType, ObjectType> : NSObject
- (void)setObject:(ObjectType)obj forKeyedSubscript:(KeyType <NSCopying>)key;
@end
MyMutableDictionary<NSString *, NSString *> *stringsByString;
NSNumber *n1, *n2;
stringsByString[n1] = n2;
--> no warning on type mismatch of the key.
To fix the problem, we introduce a new type ObjCTypeParamType that supports
a list of protocol qualifiers.
We create ObjCTypeParamType for ObjCTypeParamDecl when we create
ObjCTypeParamDecl. We also substitute ObjCTypeParamType instead of TypedefType
on an ObjCTypeParamDecl.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D23080
llvm-svn: 281358
We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the
representation of "T <protocol>" where T is a type parameter. Before this,
we use TypedefType to represent the type parameter for ObjC.
ObjCTypeParamType has "ObjCTypeParamDecl *OTPDecl" and it extends from
ObjCProtocolQualifiers. It is a non-canonical type and is canonicalized
to the underlying type with the protocol qualifiers.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D23079
llvm-svn: 281355
To construct the canonical type of ObjCTypeParamType, we need to apply
qualifiers on ObjCObjectPointerType. The updated applyObjCProtocolQualifiers
handles this case by merging the protocol lists, constructing a new
ObjCObjectType, then a new ObjCObjectPointerType.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D24059
llvm-svn: 281353
Check that ExpandStructures is true before visiting the list of ivars.
rdar://problem/27135221
Differential revision: https://reviews.llvm.org/D22929
llvm-svn: 278956
The size of image type is reported incorrectly as size of a pointer to address space 0, which causes error when casting image type to pointers by __builtin_astype.
The fix is to get image address space from TargetInfo then report the size accordingly.
Differential Revision: https://reviews.llvm.org/D22927
llvm-svn: 277647
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (3d4eec6162).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
we first touch any part of that module. Instead, defer them until the first
time that module is (transitively) imported. The initializer step for a module
then recursively initializes modules that its own headers imported.
For example, this avoids running the <iostream> global initializer in programs
that don't actually use iostreams, but do use other parts of the standard
library.
llvm-svn: 276159