summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaInit.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* P0702R1: in class template argument deduction from a list of one element, ifRichard Smith2017-09-071-0/+21
| | | | | | | that element's type is (or is derived from) a specialization of the deduced template, skip the std::initializer_list special case. llvm-svn: 312703
* Fix PR 10758: Infinite recursion when dealing with copy-initializationAlex Lorenz2017-05-161-0/+38
| | | | | | | | | | | | | | | | | | This commit fixes a bug that's tracked by PR 10758 and duplicates like PR 30343. The bug causes clang to crash with a stack overflow while recursing infinitely trying to perform copy-initialization on a type without a copy constructor but with a constructor that accepts another type that can be constructed using the original type. The commit fixes this bug by detecting the recursive behavior and failing correctly with an appropriate error message. It also tries to provide a meaningful diagnostic note about the constructor which leads to this behavior. rdar://28483944 Differential Revision: https://reviews.llvm.org/D25051 llvm-svn: 303156
* [OpenCL] Handle OpenCL specific subelement typesEgor Churaev2017-05-101-1/+1
| | | | | | | | | | | | Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D32898 llvm-svn: 302633
* PR32280: Do not crash on nested initializers.Vassil Vassilev2017-04-141-8/+10
| | | | | | Patch by Yuka Takahashi (D31591)! llvm-svn: 300313
* Fix PR31934: forming refs to functions with enable_if attrs.George Burgess IV2017-04-131-0/+13
| | | | llvm-svn: 300283
* Fix lambda to block conversion in C++17 by avoiding copy elision for theAlex Lorenz2017-04-061-0/+17
| | | | | | | | | | | | | | | | lambda capture used by the created block The commit r288866 introduced guaranteed copy elision to C++ 17. This unfortunately broke the lambda to block conversion in C++17 (the compiler crashes when performing IRGen). This commit fixes the conversion by avoiding copy elision for the capture that captures the lambda that's used in the block created by the lambda to block conversion process. rdar://31385153 Differential Revision: https://reviews.llvm.org/D31669 llvm-svn: 299646
* [OpenCL] Extended diagnostics for atomic initializationEgor Churaev2017-04-051-0/+14
| | | | | | | | | | | | | | | | | | Summary: I saw the same changes in the following review: https://reviews.llvm.org/D17438 I don't know in that way I could determine that atomic variable was initialized by macro ATOMIC_VAR_INIT. Anyway I added check that atomic variables can be initialize only in global scope. I think that we can discuss this change. Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D30643 llvm-svn: 299537
* [OpenCL] Enables passing sampler initializer to function argumentEgor Churaev2017-04-051-1/+1
| | | | | | | | | | | | Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: yaxunl, bader Differential Revision: https://reviews.llvm.org/D31594 llvm-svn: 299524
* [Objective-C] Miscellaneous -fobjc-weak FixesBrian Kelley2017-03-291-8/+4
| | | | | | | | | | | | | | Summary: After examining the remaining uses of LangOptions.ObjCAutoRefCount, found a some additional places to also check for ObjCWeak not covered by previous test cases. Added a test file to verify all the code paths that were changed. Reviewers: rsmith, doug.gregor, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31007 llvm-svn: 299015
* Fix handling of initialization from parenthesized initializer list.Richard Smith2017-03-241-1/+31
| | | | | | | | | | | | | 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
* PR32044: Fix some cases where we would confuse a transparent init-list ↵Richard Smith2017-02-231-0/+5
| | | | | | expression with an aggregate init. llvm-svn: 296033
* Factor out function to determine whether we're performing a templateRichard Smith2017-02-211-2/+2
| | | | | | | | | 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
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-10/+11
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* [Sema] Add lvalue-to-rvalue cast in direct-list-initialization of enumVedant Kumar2017-02-161-0/+2
| | | | | | | | | | | | | | | | | After r264564, we allowed direct-list-initialization of an enum from an integral value in C++1z mode, so long as that value can convert to the enum's underlying type. In this kind of initialization, we need a lvalue-to-rvalue conversion for the initializer value if it is not a rvalue. This lets us accept the following code: enum class A : unsigned {}; A foo(unsigned x) { return A{x}; } Differential Revision: https://reviews.llvm.org/D29723 llvm-svn: 295266
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-34/+36
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* [c++1z] P0512R0: support for 'explicit' specifier on deduction-guides.Richard Smith2017-02-101-5/+6
| | | | llvm-svn: 294693
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-091-3/+217
| | | | | | deduction-guides. llvm-svn: 294613
* Remove apparently-unnecessary copy of constructor lookup result.Richard Smith2017-02-011-9/+1
| | | | | | | | | | | Contrary to the comment, DeclContext intends to guarantee that the lookup results for a particular name will be stable across non-AST-mutating operations, so a copy here should not be necessary. Further, if a copy *is* necessary, the other four instances of this pattern within this file would also be wrong, and we have no evidence of any problems with them; if this change unearths problems, we should fix all the instances of this pattern. llvm-svn: 293740
* PR31742: Don't emit a bogus "zero size array" extwarn when initializing aRichard Smith2017-01-241-1/+1
| | | | | | runtime-sized array from an empty list in an array new. llvm-svn: 292991
* [Sema] Fix bug in handling of designated initializer.Akira Hatanaka2017-01-171-0/+4
| | | | | | | | | | | | CheckDesignatedInitializer wasn't taking into account the base classes when computing the index for the field in the derived class, which caused the test case to crash during IRGen because of a malformed AST. rdar://problem/26795040 Differential Revision: https://reviews.llvm.org/D28705 llvm-svn: 292245
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-071-0/+7
| | | | | | | | | | | | | | | | | | | | | operands where possible. This implements something like the current direction of DR1581: we use a narrow syntactic check to determine the set of places where a constant expression could be evaluated, and only instantiate a constexpr function or variable if it's referenced in one of those contexts, or is odr-used. It's not yet clear whether this is the right set of syntactic locations; we currently consider all contexts within templates that would result in odr-uses after instantiation, and contexts within list-initialization (narrowing conversions take another victim...), as requiring instantiation. We could in principle restrict the former cases more (only const integral / reference variable initializers, and contexts in which a constant expression is required, perhaps). However, this is sufficient to allow us to accept libstdc++ code, which relies on GCC's behavior (which appears to be somewhat similar to this approach). llvm-svn: 291318
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-1/+40
| | | | | | | | | | | | | | operand." Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171 Reviewers: djasper, Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27981 llvm-svn: 290431
* Perform type-checking for a converted constant expression in a templateRichard Smith2016-12-211-1/+2
| | | | | | | | | | | argument even if the expression is value-dependent (we need to suppress the final portion of the narrowing check, but the rest of the checking can still be done eagerly). This affects template template argument validity and partial ordering under p0522r0. llvm-svn: 290276
* Fix defaulted-functions-in-C++98 extension to give the functions the sameRichard Smith2016-12-211-17/+15
| | | | | | | | effect they would have in C++11. In particular, they do not prevent value-initialization from performing zero-initialization, nor do they prevent a struct from being an aggregate. llvm-svn: 290229
* [c++1z] When initializing a const-qualified class type, don't forget to add onRichard Smith2016-12-211-11/+5
| | | | | | | the requested cv-qualifiers after construction. This usually doesn't matter, but it does matter within a ?: operator. llvm-svn: 290227
* Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."Daniel Jasper2016-12-201-40/+1
| | | | | | | | | | 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
* [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.Egor Churaev2016-12-201-1/+40
| | | | | | | | | | | | 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
* Move checks for creation of objects of abstract class type from the variousRichard Smith2016-12-151-1/+29
| | | | | | | | | 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
* [c++1z] P0217R3: Allow by-value structured binding of arrays.Richard Smith2016-12-141-7/+13
| | | | llvm-svn: 289630
* Remove custom handling of array copies in lambda by-value array capture andRichard Smith2016-12-141-2/+3
| | | | | | | | | | | copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop. This exposed a bug in the static analyzer where it was unable to differentiate between zero-initialized and unknown array values, which has also been fixed here. llvm-svn: 289618
* Add two new AST nodes to represent initialization of an array in terms ofRichard Smith2016-12-121-17/+137
| | | | | | | | | | | | | | | | | | | | initialization of each array element: * ArrayInitLoopExpr is a prvalue of array type with two subexpressions: a common expression (an OpaqueValueExpr) that represents the up-front computation of the source of the initialization, and a subexpression representing a per-element initializer * ArrayInitIndexExpr is a prvalue of type size_t representing the current position in the loop This will be used to replace the creation of explicit index variables in lambda capture of arrays and copy/move construction of classes with array elements, and also C++17 structured bindings of arrays by value (which inexplicably allow copying an array by value, unlike all of C++'s other array declarations). No uses of these nodes are introduced by this change, however. llvm-svn: 289413
* DR1295 and cleanup for P0135R1: Make our initialization code more directlyRichard Smith2016-12-091-229/+242
| | | | | | | | | | | | | | | 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
* [c++17] P0135R1: Guaranteed copy elision.Richard Smith2016-12-061-12/+67
| | | | | | | | 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
* DR1213: element access on an array xvalue or prvalue produces an xvalue. In theRichard Smith2016-12-051-3/+4
| | | | | | | | | | | | | | latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
* DR616, and part of P0135R1: member access (or pointer-to-member access) on aRichard Smith2016-12-031-9/+21
| | | | | | | temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
* Remove unnecessary distinction between Ref_Compatible andRichard Smith2016-10-211-4/+3
| | | | | | | Ref_Compatible_With_Added_Qualification. We always treated these two values the same way. llvm-svn: 284895
* [OpenCL] Allow partial initializer for array and structYaxun Liu2016-10-111-2/+3
| | | | | | | | | | | | | | Currently Clang allows partial initializer for C99 but not for OpenCL, e.g. float a[16][16] = {1.0f, 2.0f}; is allowed in C99 but not allowed in OpenCL. This patch fixes that. Differential Revision: https://reviews.llvm.org/D25335 llvm-svn: 283891
* PR22924, PR22845, some of CWG1464: When checking the initializer for an arrayRichard Smith2016-10-051-6/+18
| | | | | | | | | | | | | | | | | | 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
* Fix clang's handling of the copy performed in the second phase of classRichard Smith2016-09-071-119/+106
| | | | | | | | | | | | | | | | | | | | | | | copy-initialization. We previously got this wrong in a couple of ways: - we only looked for copy / move constructors and constructor templates for this copy, and thus would fail to copy in cases where doing so should use some other constructor (but see core issue 670), - we mishandled the special case for disabling user-defined conversions that blocks infinite recursion through repeated application of a copy constructor (applying it in slightly too many cases) -- though as far as I can tell, this does not ever actually affect the result of overload resolution, and - we misapplied the special-case rules for constructors taking a parameter whose type is a (reference to) the same class type by incorrectly assuming that only happens for copy/move constructors (it also happens for constructors instantiated from templates and those inherited from base classes). These changes should only affect strange corner cases (for instance, where the copy constructor exists but has a non-const-qualified parameter type), so for the most part it only causes us to produce more 'candidate' notes, but see the test changes for other cases whose behavior is affected. llvm-svn: 280776
* This patch implements PR#22821.Roger Ferrer Ibanez2016-08-121-0/+4
| | | | | | | | | | | | | | | | | | Taking the address of a packed member is dangerous since the reduced alignment of the pointee is lost. This can lead to memory alignment faults in some architectures if the pointer value is dereferenced. This change adds a new warning to clang emitted when taking the address of a packed member. A packed member is either a field/data member declared as attribute((packed)) or belonging to a struct/class declared as such. The associated flag is -Waddress-of-packed-member. Conversions (either implicit or via a valid casting) to pointer types with lower or equal alignment requirements (e.g. void* or char*) will silence the warning. Differential Revision: https://reviews.llvm.org/D20561 llvm-svn: 278483
* P0217R3: template instantiation support for decomposition declarations.Richard Smith2016-08-121-1/+3
| | | | llvm-svn: 278458
* P0217R3: Perform semantic checks and initialization for the bindings in aRichard Smith2016-08-111-4/+17
| | | | | | | decomposition declaration for arrays, aggregate-like structs, tuple-like types, and (as an extension) for complex and vector types. llvm-svn: 278435
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-8/+83
| | | | | | | | | | | | | | | | initializer 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 (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
* [NFC] Header cleanupMehdi Amini2016-07-181-2/+1
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* Reverting 275417Roger Ferrer Ibanez2016-07-141-13/+0
| | | | | | This change has triggered unexpected failures. llvm-svn: 275462
* Diagnose taking address and reference binding of packed membersRoger Ferrer Ibanez2016-07-141-0/+13
| | | | | | | | | | | | | | | | | | | | | | | This patch implements PR#22821. Taking the address of a packed member is dangerous since the reduced alignment of the pointee is lost. This can lead to memory alignment faults in some architectures if the pointer value is dereferenced. This change adds a new warning to clang emitted when taking the address of a packed member. A packed member is either a field/data member declared as attribute((packed)) or belonging to a struct/class declared as such. The associated flag is -Waddress-of-packed-member. Conversions (either implicit or via a valid casting) to pointer types with lower or equal alignment requirements (e.g. void* or char*) silence the warning. This change also adds a new error diagnostic when the user attempts to bind a reference to a packed member, regardless of the alignment. Differential Revision: https://reviews.llvm.org/D20561 llvm-svn: 275417
* [OpenCL] An implementation of device side enqueue (DSE) from OpenCL v2.0 ↵Anastasia Stulova2016-07-051-2/+2
| | | | | | | | | | | | | | | | | s6.13.17. - Added new Builtins: enqueue_kernel, get_kernel_work_group_size and get_kernel_preferred_work_group_size_multiple. These Builtins use custom check to diagnose parameters of the passed Blocks i. e. variable number of 'local void*' type params, and check different overloads specified in Table 6.31 of OpenCL v2.0. - IR is generated as an internal library call for each OpenCL Builtin, reusing ObjC Block implementation. Review: http://reviews.llvm.org/D20249 llvm-svn: 274540
* Mark inheriting constructors as deleted if the corresponding defaulted defaultRichard Smith2016-06-291-1/+4
| | | | | | | | constructor would be; this is effectively required by P0136R1. This has the effect of exposing the validity of the base class initialization steps to SFINAE checks. llvm-svn: 274088
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* Use ranges to concisely express iterationDavid Majnemer2016-06-231-3/+3
| | | | | | | No functional change is intended, this should just clean things up a little. llvm-svn: 273522
OpenPOWER on IntegriCloud