summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/TreeTransform.h
Commit message (Collapse)AuthorAgeFilesLines
* Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith2015-11-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | https://gcc.gnu.org/onlinedocs/gcc/Typeof.html Differences from the GCC extension: * __auto_type is also permitted in C++ (but only in places where it could appear in C), allowing its use in headers that might be shared across C and C++, or used from C++98 * __auto_type can be combined with a declarator, as with C++ auto (for instance, "__auto_type *p") * multiple variables can be declared in a single __auto_type declaration, with the C++ semantics (the deduced type must be the same in each case) This patch also adds a missing restriction on applying typeof to a bit-field, which GCC has historically rejected in C (due to lack of clarity as to whether the operand should be promoted). The same restriction also applies to __auto_type in C (in both GCC and Clang). This also fixes PR25449. Patch by Nicholas Allegra! llvm-svn: 252690
* N3922: direct-list-initialization of an auto-typed variable no longer deduces aRichard Smith2015-11-111-5/+6
| | | | | | | | | | | | | | | | | | | std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
* [coroutines] Creation of promise object, lookup of operator co_await, buildingRichard Smith2015-10-271-1/+77
| | | | | | of await_* calls, and AST representation for same. llvm-svn: 251387
* [coroutines] Initial stub Sema functionality for handling coroutine await / ↵Richard Smith2015-10-221-1/+3
| | | | | | yield / return. llvm-svn: 250993
* Use an ArrayRef<OffsetOfComponent> instead of pointer and size throughout ↵Craig Topper2015-10-221-7/+5
| | | | | | offsetof handling code. Also use a range-based for loop. NFC llvm-svn: 250989
* Re-land r250592 without rejecting field refs in unevaluated contextsReid Kleckner2015-10-201-2/+13
| | | | | | | | | | | This time, I went with the first approach from http://reviews.llvm.org/D6700, where clang actually attempts to form an implicit member reference from an UnresolvedLookupExpr. We know that there are only two possible outcomes at this point, a DeclRefExpr of the FieldDecl or an error, but its safer to reuse the existing machinery for this. llvm-svn: 250856
* Roll-back r250822.Angel Garcia Gomez2015-10-201-2/+2
| | | | | | | | | | Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
* Apply modernize-use-default to clang.Angel Garcia Gomez2015-10-201-2/+2
| | | | | | | | | | | | 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
* Revert "Diagnose UnresolvedLookupExprs that resolve to instance members in ↵Reid Kleckner2015-10-201-11/+1
| | | | | | | | | | | | | | | | | static methods" This reverts commit r250592. It has issues around unevaluated contexts, like this: template <class T> struct A { T i; }; template <class T> struct B : A<T> { using A<T>::i; typedef decltype(i) U; }; template struct B<int>; llvm-svn: 250774
* Diagnose UnresolvedLookupExprs that resolve to instance members in static ↵Reid Kleckner2015-10-171-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | methods During the initial template parse for this code, 'member' is unresolved and we don't know anything about it: struct A { int member }; template <typename T> struct B : public T { using T::member; static void f() { (void)member; // Could be static or non-static. } }; template class B<A>; The pattern declaration contains an UnresolvedLookupExpr rather than an UnresolvedMemberExpr because `f` is static, and `member` should never be a field. However, if the code is invalid, it may become a field, in which case we should diagnose it. Reviewers: rjmccall, rsmith Differential Revision: http://reviews.llvm.org/D6700 llvm-svn: 250592
* Fix Clang-tidy modernize-use-nullptr warnings in headers and generated ↵Hans Wennborg2015-09-291-2/+2
| | | | | | | | | | files; other minor cleanups. By Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13187 llvm-svn: 248828
* [OPENMP 4.1] Add 'simd' clause for 'ordered' directive.Alexey Bataev2015-09-281-0/+6
| | | | | | | | | | | Parsing and sema analysis for 'simd' clause in 'ordered' directive. Description If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered regions in the order of the loop iterations. Restrictions An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region llvm-svn: 248696
* [OPENMP 4.1] Add 'threads' clause for '#pragma omp ordered'.Alexey Bataev2015-09-251-0/+7
| | | | | | | | OpenMP 4.1 extends format of '#pragma omp ordered'. It adds 3 additional clauses: 'threads', 'simd' and 'depend'. If no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team executing the loop region execute ordered regions sequentially in the order of the loop iterations. The loop region to which an ordered region without any clause or with a threads clause binds must have an ordered clause without the parameter specified on the corresponding loop directive. llvm-svn: 248569
* PR14858: Initial support for proper sizeof... handling within alias templates.Richard Smith2015-09-231-47/+97
| | | | | | | This doesn't quite get alias template equivalence right yet, but handles the egregious cases where we would silently give the wrong answers. llvm-svn: 248431
* [OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause.Alexey Bataev2015-09-031-6/+10
| | | | | | | | | | | | | | | | | OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
* Fix assertion failure in TransformOpaqueValueExprHubert Tong2015-09-011-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: `OpaqueValueExpr`s may not have a source expression (as in the case when they are created due to a default argument error). This can cause an assertion failure in `TransformOpaqueValueExpr` during template instantiation. This patch fixes the assertion failure. Reviewers: hfinkel, rsmith Subscribers: fraggamuffin, cfe-commits Differential Revision: http://reviews.llvm.org/D11582 Patch by Rachel Craik! llvm-svn: 246600
* Add a new frontend warning for referencing members from the handler of a ↵Aaron Ballman2015-09-011-9/+15
| | | | | | | | constructor or destructor function-try-block, which is UB in C++. This corresponds to the CERT secure coding rule ERR53-CPP. llvm-svn: 246548
* [OPENMP 4.0] Initial support for array sections.Alexey Bataev2015-08-251-0/+43
| | | | | | | | Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0). Currently it is allowed to use array sections only in OpenMP clauses that accepts list of expressions. Differential Revision: http://reviews.llvm.org/D10732 llvm-svn: 245937
* [OPENMP 4.1] Initial support for 'simdlen' clause.Alexey Bataev2015-08-211-0/+20
| | | | | | Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter. llvm-svn: 245692
* [OPENMP 4.1] Initial support for modifiers in 'linear' clause.Alexey Bataev2015-08-201-4/+7
| | | | | | | | | | | | | | | | | | | | | | OpenMP 4.1 adds 3 optional modifiers to 'linear' clause. Format of 'linear' clause has changed to: ``` linear(linear-list[ : linear-step]) ``` where linear-list is one of the following ``` list modifier(list) ``` where modifier is one of the following: ``` ref (C++) val (C/C++) uval (C++) ``` Patch adds parsing and sema analysis for these modifiers. llvm-svn: 245550
* [TreeTransform] Simplify code. No functionality change.Benjamin Kramer2015-08-181-3/+1
| | | | llvm-svn: 245271
* This patch commits OpenMP 4 target device clausesMichael Wong2015-08-071-0/+21
| | | | | | | This is committed on behalf of Kelvin Li http://reviews.llvm.org/D11469?id=31227 llvm-svn: 244325
* [OPENMP 4.1] Initial support for extended 'ordered' clause.Alexey Bataev2015-07-301-2/+18
| | | | | | | | OpenMP 4.1 introduces optional argument '(n)' for 'ordered' clause, where 'n' is a number of loops that immediately follow the directive. 'n' must be constant positive integer expressions and it must be less or equal than the number of the loops in the resulting loop nest. Patch adds parsing and semantic analysis for this optional argument. llvm-svn: 243635
* [sema] Fix crash when typo-transforming an expression containing an ObjC ↵Argyrios Kyrtzidis2015-07-281-5/+4
| | | | | | | | super message expression. rdar://21427916 llvm-svn: 243387
* Commit for http://reviews.llvm.org/D10765Michael Wong2015-07-211-0/+11
| | | | | | | for OpenMP 4 target data directive parsing and sema. This commit is on behalf of Kelvin Li. llvm-svn: 242785
* Sema: Allow null names to be passed in to isAcceptableTagRedeclarationJustin Bogner2015-07-101-1/+1
| | | | | | | | | | | | | It's possible for TagRedeclarations to involve decls without a name, ie, anonymous enums. We hit some undefined behaviour if we bind these null names to the reference here. We never dereference the name, so it's harmless if it's null - make it a pointer to allow that. Fixes the Modules/submodules-merge-defs.cpp test under ubsan. llvm-svn: 241963
* C++ support for Objective-C lightweight generics.Douglas Gregor2015-07-071-6/+187
| | | | | | | | | | | | | | | | | | | Teach C++'s tentative parsing to handle specializations of Objective-C class types (e.g., NSArray<NSString *>) as well as Objective-C protocol qualifiers (id<NSCopying>) by extending type-annotation tokens to handle this case. As part of this, remove Objective-C protocol qualifiers from the declaration specifiers, which never really made sense: instead, provide Sema entry points to make them part of the type annotation token. Among other things, this properly diagnoses bogus types such as "<NSCopying> id" which should have been written as "id <NSCopying>". Implements template instantiation support for, e.g., NSArray<T>* in C++. Note that parameterized classes are not templates in the C++ sense, so that cannot (for example) be used as a template argument for a template template parameter. Part of rdar://problem/6294649. llvm-svn: 241545
* [OPENMP 4.0] Initial support for 'omp cancel' construct.Alexey Bataev2015-07-021-0/+13
| | | | | | Implemented parsing/sema analysis + (de)serialization. llvm-svn: 241253
* [OPENMP 4.0] Initial support for 'omp cancellation point' construct.Alexey Bataev2015-07-011-4/+20
| | | | | | Add parsing and sema analysis for 'omp cancellation point' directive. llvm-svn: 241145
* [Sema] Maintain ellipsis location when transforming lambda capturesMeador Inge2015-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a crash caused by the following case: template<typename T> auto f(T x) { auto g = [](auto ... args) { auto h = [args...]() -> int { return 0; }; return h; }; return g; } auto x = f(0)(); When the templated function 'f' is instantiated and the inner-most lambda is transformed the ellipsis location on the captured variable is lost. Then the lambda returned by 'f' is instantiated and the tree transformer chokes on the invalid ellipsis location. The problem is fixed by making a minor change to properly track the ellipsis location. This fixes PR23716. Differential Revision: http://reviews.llvm.org/D10590 llvm-svn: 240740
* Replace __double_underscored type nullability qualifiers with ↵Douglas Gregor2015-06-241-1/+1
| | | | | | | | | | | | | | | | _Uppercase_underscored Addresses a conflict with glibc's __nonnull macro by renaming the type nullability qualifiers as follows: __nonnull -> _Nonnull __nullable -> _Nullable __null_unspecified -> _Null_unspecified This is the major part of rdar://problem/21530726, but does not yet provide the Darwin-specific behavior for the old names. llvm-svn: 240596
* [OPENMP] Initial support for 'depend' clause (4.0).Alexey Bataev2015-06-231-0/+29
| | | | | | Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
* [OPENMP] Do not emit references to original variables in 'private' clause.Alexey Bataev2015-06-231-0/+2
| | | | | | | Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy. Differential Revision: http://reviews.llvm.org/D9550 llvm-svn: 240377
* Extend type nullability qualifiers for Objective-C.Douglas Gregor2015-06-191-1/+1
| | | | | | | | | | | | | | | Introduce context-sensitive, non-underscored nullability specifiers (nonnull, nullable, null_unspecified) for Objective-C method return types, method parameter types, and properties. Introduce Objective-C-specific semantics, including computation of the nullability of the result of a message send, merging of nullability information from the @interface of a class into its @implementation, etc . This is the Objective-C part of rdar://problem/18868820. llvm-svn: 240154
* Introduce type nullability specifiers for C/C++.Douglas Gregor2015-06-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
* [OPENMP] Support for '#pragma omp taskgroup' directive.Alexey Bataev2015-06-181-0/+11
| | | | | | | | | | | | | Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0). The code for directive is generated the following way: #pragma omp taskgroup <body> void __kmpc_taskgroup(<loc>, thread_id); <body> void __kmpc_end_taskgroup(<loc>, thread_id); llvm-svn: 240011
* Implementing C99 partial re-initialization behavior (DR-253)Yunzhong Gao2015-06-101-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | Based on previous discussion on the mailing list, clang currently lacks support for C99 partial re-initialization behavior: Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm This patch attempts to fix this problem. Given the following code snippet, struct P1 { char x[6]; }; struct LP1 { struct P1 p1; }; struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' }; // this example is adapted from the example for "struct fred x[]" in DR-253; // currently clang produces in l: { "\0\0x" }, // whereas gcc 4.8 produces { "fox" }; // with this fix, clang will also produce: { "fox" }; Differential Review: http://reviews.llvm.org/D5789 llvm-svn: 239446
* Replace the broken LambdaCapture::isInitCapture API.James Dennett2015-05-071-2/+2
| | | | | | | | | | | | | | | A LambdaCapture does not have sufficient information to correctly determine whether it is an init-capture or not. Doing so requires knowledge held in the LambdaExpr itself. It the case of a nested capture of an init-capture it is not sufficient to check (as LambdaCapture::isInitCapture did) whether the associated VarDecl was from an init-capture. This patch moves isInitCapture to LambdaExpr and updates Capture->isInitCapture() to Lambda->isInitCapture(Capture). llvm-svn: 236760
* PR23334: Perform semantic checking of lambda capture initialization in the ↵Richard Smith2015-04-271-45/+35
| | | | | | | | | | | | | | | | | | right context. Previously we'd try to perform checks on the captures from the middle of parsing the lambda's body, at the point where we detected that a variable needed to be captured. This was wrong in a number of subtle ways. In PR23334, we couldn't correctly handle the list of potential odr-uses resulting from the capture, and our attempt to recover from that resulted in a use-after-free. We now defer building the initialization expression until we leave the lambda body and return to the enclosing context, where the initialization does the right thing. This patch only covers lambda-expressions, but we should apply the same change to blocks and captured statements too. llvm-svn: 235921
* [OPENMP] Fix crash on private variables not used in OpenMP region in templates.Alexey Bataev2015-04-021-1/+10
| | | | llvm-svn: 233913
* [Objective-C patch]. Amend TransformObjCMessageExpr to handle callFariborz Jahanian2015-03-301-0/+38
| | | | | | | to 'super' of instance/class methods and not assert. rdar://20350364 llvm-svn: 233642
* Track the source location of the dot or arrow operator in a MemberExpr.Aaron Ballman2015-03-241-5/+3
| | | | | | Patch by Joe Ranieri! llvm-svn: 233085
* Warn when jumping out of a __finally block via continue, break, return, __leave.Nico Weber2015-03-091-1/+1
| | | | | | | | | | | | | | | Since continue, break, return are much more common than __finally, this tries to keep the work for continue, break, return O(1). Sema keeps a stack of active __finally scopes (to do this, ActOnSEHFinally() is split into ActOnStartSEHFinally() and ActOnFinishSEHFinally()), and the various jump statements then check if the current __finally scope (if present) is deeper than then destination scope of the jump. The same warning for goto statements is still missing. This is the moral equivalent of MSVC's C4532. llvm-svn: 231623
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-5/+3
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* Various fixes to mangling of list-initialization.Richard Smith2015-02-051-2/+9
| | | | llvm-svn: 228274
* Handle errors in lambda prototype instantiation correctlyReid Kleckner2014-12-151-2/+8
| | | | | | | | | | | | Previously we would attempt to build a TypeSourceInfo for a null type, and then we would forget to pop the function scope before returning an error. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D6665 llvm-svn: 224271
* Remove code that tries to avoid transforming non-dependent call operator typesRichard Smith2014-11-201-78/+24
| | | | | | | | | | for lambda expressions. That can't ever work; we need to transform the parameters in order to create new ones in the new call operator context. Fixes a rejects-valid when transforming a context containing a lambda-expression that uses its function parameters in C++14 mode. llvm-svn: 222482
* Try a different workaround for GCC 4.7.2 lambda capture bug. The previousRichard Smith2014-11-121-7/+8
| | | | | | workaround took us from wrong-code to ICE. llvm-svn: 221754
* Instantiate exception specifications when instantiating function types (otherRichard Smith2014-11-121-17/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
* [c++1z] N4295: fold-expressions.Richard Smith2014-11-081-0/+143
| | | | | | | | | | | | | | | | This is a new form of expression of the form: (expr op ... op expr) where one of the exprs is a parameter pack. It expands into (expr1 op (expr2onwards op ... op expr)) (and likewise if the pack is on the right). The non-pack operand can be omitted; in that case, an empty pack gives a fallback value or an error, depending on the operator. llvm-svn: 221573
OpenPOWER on IntegriCloud