summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Store decls in prototypes on the declarator instead of in the ASTReid Kleckner2016-12-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This saves two pointers from FunctionDecl that were being used for some rare and questionable C-only functionality. The DeclsInPrototypeScope ArrayRef was added in r151712 in order to parse this kind of C code: enum e {x, y}; int f(enum {y, x} n) { return x; // should return 1, not 0 } The challenge is that we parse 'int f(enum {y, x} n)' it its own function prototype scope that gets popped before we build the FunctionDecl for 'f'. The original change was doing two questionable things: 1. Saving all tag decls introduced in prototype scope on a TU-global Sema variable. This is problematic when you have cases like this, where 'x' and 'y' shouldn't be visible in 'f': void f(void (*fp)(enum { x, y } e)) { /* no x */ } This patch fixes that, so now 'f' can't see 'x', which is consistent with GCC. 2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that they could be used in ActOnStartOfFunctionDef. This is just an inefficient way to move information around. The AST lives forever, but the list of non-parameter decls in prototype scope is short lived. Moving these things to the Declarator solves both of these issues. Reviewers: rsmith Subscribers: jmolloy, cfe-commits Differential Revision: https://reviews.llvm.org/D27279 llvm-svn: 289225
* Add missing warning for use of C++1z init-statements in C++14 and before.Richard Smith2016-10-181-0/+4
| | | | llvm-svn: 284530
* [CUDA] Emit a warning if a CUDA host/device/global attribute is placed after ↵Justin Lebar2016-09-301-0/+16
| | | | | | | | | | | | | | | | | | | | | | | '(...)'. Summary: This is probably the sane place for the attribute to go, but nvcc specifically rejects it. Other GNU-style attributes are allowed in this position (although judging from the warning it emits for host/device/global, those attributes are applied to the lambda's anonymous struct, not to the function itself). It would be nice to have a FixIt message here, but doing so, or even just getting the correct range for the attribute, including its '((' and '))'s, is apparently Hard. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25115 llvm-svn: 282911
* [CUDA] Fix up MaybeParseGNUAttributes call used for out-of-place attributes ↵Justin Lebar2016-09-301-5/+3
| | | | | | | | | | | | | | on CUDA lambdas. Summary: There's an overload that we can use to make this a bit cleaner. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25114 llvm-svn: 282910
* [CUDA] Handle attributes on CUDA lambdas appearing between [...] and (...).Justin Lebar2016-09-301-7/+12
| | | | | | | | | | | | Summary: This is ugh, but it makes us compatible with NVCC. Fixes bug 26341. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25103 llvm-svn: 282879
* Pass information in a record instead of stack. NFCSerge Pavlov2016-08-081-8/+7
| | | | | | | | | Functions of Sema that work with building of nested name specifiers have too many parameters (BuildCXXNestedNameSpecifier already expects 10 arguments). With this change the information about identifier and its context is packed into a structure, which is then passes to the semantic functions. llvm-svn: 277976
* P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith2016-07-221-0/+1
| | | | | | | | | | | decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
* P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.Richard Smith2016-06-291-5/+30
| | | | | | | | | | | | | | | | | | No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
* Parser::ParseCXXCondition(): Prune \param in r273548 [-Wdocumentation]NAKAMURA Takumi2016-06-231-3/+0
| | | | llvm-svn: 273624
* Re-commit r273548, reverted in r273589, with a fix to not produceRichard Smith2016-06-231-29/+15
| | | | | | | | | | | | | | | | -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
* Revert r273548, "Rearrange condition handling so that semantic checks on a ↵Peter Collingbourne2016-06-231-15/+29
| | | | | | | | condition variable" as it caused a regression in -Wfor-loop-analysis. llvm-svn: 273589
* Rearrange condition handling so that semantic checks on a condition variableRichard Smith2016-06-231-29/+15
| | | | | | | | | are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273548
* [Parser] Fix look ahead after EOF while parsing objc message and lambdasBruno Cardoso Lopes2016-05-311-1/+4
| | | | | | | | | | | | | If a closing ')' isn't found for a macro instantiation inside a '[', the next token is EOF, this leads to crashes if we try to look ahead of that. This could be triggered whenever trying to parse lambdas or objs message expressions. Differential Revision: http://reviews.llvm.org/D20451 rdar://problem/25662647 llvm-svn: 271314
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-0/+3
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-3/+0
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-0/+3
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
* [Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier ↵Faisal Vali2016-03-261-4/+61
| | | | | | | | | | | | | | | | | | | | | | (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
* [Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3)Faisal Vali2016-03-211-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement lambda capture of *this by copy. For e.g.: struct A { int d = 10; auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; } }; auto L = A{}.foo(); // A{}'s lifetime is gone. // Below is still ok, because *this was captured by value. assert(L(10) == 20); assert(L(100) == 120); If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined. Implementation Strategy: - amend the parser to accept *this in the lambda introducer - add a new king of capture LCK_StarThis - teach Sema::CheckCXXThisCapture to handle by copy captures of the enclosing object (i.e. *this) - when CheckCXXThisCapture does capture by copy, the corresponding initializer expression for the closure's data member direct-initializes it thus making a copy of '*this'. - in codegen, when assigning to CXXThisValue, if *this was captured by copy, make sure it points to the corresponding field member, and not, unlike when captured by reference, what the field member points to. - mark feature as implemented in svn Much gratitude to Richard Smith for his carefully illuminating reviews! llvm-svn: 263921
* Simplify EnterTokenStream API to make it more robust for memory managementDavid Blaikie2016-02-091-2/+1
| | | | | | | | | | | | | | | While this won't help fix things like the bug that r260219 addressed, it seems like good tidy up to have anyway. (it might be nice if "makeArrayRef" always produced a MutableArrayRef & let it decay to an ArrayRef when needed - then I'd use that for the MutableArrayRefs in this patch) If we had std::dynarray I'd use that instead of unique_ptr+size_t, ideally (but then it'd have to be threaded down through the Preprocessor all the way - no idea how painful that would be) llvm-svn: 260246
* PR23057: fix use-after-free due to local token buffer in ↵Alexey Bataev2016-02-041-1/+19
| | | | | | | | | | ParseCXXAmbiguousParenExpression, by Dmitry Polukhin Differential Revision: http://reviews.llvm.org/D16572 A test/Parser/cxx-ambig-paren-expr-asan.cpp M lib/Parse/ParseExprCXX.cpp llvm-svn: 259750
* OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedefDavid Blaikie2016-01-151-17/+14
| | | | llvm-svn: 257958
* [coroutines] Support braced-init-list as operand of co_yield expression.Richard Smith2015-11-201-1/+2
| | | | llvm-svn: 253726
* Fix a layering oddity by passing Sema to DeclSpec::Finish instead of ↵Craig Topper2015-11-151-5/+5
| | | | | | DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
* N3922: direct-list-initialization of an auto-typed variable no longer deduces aRichard Smith2015-11-111-11/+13
| | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | of await_* calls, and AST representation for same. llvm-svn: 251387
* [coroutines] Initial stub Sema functionality for handling coroutine await / ↵Richard Smith2015-10-221-2/+2
| | | | | | yield / return. llvm-svn: 250993
* [coroutines] Add parsing support for co_await expression, co_yield expression,Richard Smith2015-10-221-0/+14
| | | | | | co_await modifier on range-based for loop, co_return statement. llvm-svn: 250985
* When pretty-printing a C++11 literal operator, don't insert whitespace betweenRichard Smith2015-10-081-1/+1
| | | | | | | the "" and the suffix; that breaks names such as 'operator""if'. For symmetry, also remove the space between the 'operator' and the '""'. llvm-svn: 249641
* Modify DeclaratorChuck::getFunction to be passed an Exception Specification ↵Nathan Wilson2015-08-261-2/+2
| | | | | | | | | | | | | | | | | SourceRange Summary: - Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range. - Add diagnostic; function concept having an exception specification. Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11789 llvm-svn: 246005
* C++ support for Objective-C lightweight generics.Douglas Gregor2015-07-071-7/+0
| | | | | | | | | | | | | | | | | | | 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
* [Parse] Allow 'constexpr' in condition declarationsMeador Inge2015-06-251-1/+1
| | | | | | | | | | | | | | | | | This patch implements the functionality specified by DR948. The changes are two fold. First, the parser was modified to allow 'constexpr's to appear in condition declarations (which was a hard error before). Second, Sema was modified to cleanup maybe odr-used declarations by way of a call to 'ActOnFinishFullExpr'. As 'constexpr's were not allowed in condition declarations before the cleanup wasn't necessary (such declarations were always odr-used). This fixes PR22491. Differential Revision: http://reviews.llvm.org/D8978 llvm-svn: 240707
* [clang] Refactoring of conditions so they use isOneOf() instead of multiple ↵Daniel Marjamaki2015-06-181-5/+4
| | | | | | is(). llvm-svn: 240008
* Refactored some common functionality into MaybeParseMicrosoftDeclSpecs; NFC.Aaron Ballman2015-05-201-2/+1
| | | | llvm-svn: 237835
* [Parse] Don't crash on ~A::{Benjamin Kramer2015-03-291-1/+1
| | | | | | Found by clang-fuzz. llvm-svn: 233492
* Make Token a real POD type.Benjamin Kramer2015-03-081-0/+1
| | | | | | | We copy them around a lot and skip construction in favor of startToken, make the default construction trivial to reflect that. llvm-svn: 231603
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-8/+5
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* For variables with dependent type, don't crash on `var->::new` or `var->__super`Nico Weber2015-02-161-6/+8
| | | | | | | | | | | | | | | | | | | | | ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls ActOnStartCXXMemberReference() to inform sema that a member reference is about to start, and that function lets the parser know if sema thinks that the base expression's type could allow a pseudo destructor from a semantic point of view (for example, if the the base expression has a dependent type). ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and passes MayBePseudoDestructor on to that function, expecting the function to set it to false if a pseudo destructor is impossible from a syntactic point of view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier() had early-outs for ::new and __super, so MayBePseudoDestructor stayed true, so we tried to parse a pseudo dtor, and then became confused since we couldn't find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets MayBePseudoDestructor to false above the early exits. Parts of this found by SLi's bot. llvm-svn: 229449
* Wrap to 80 columns. No behavior change.Nico Weber2015-02-151-1/+2
| | | | llvm-svn: 229282
* Add a warning for direct-list-initialization of a variable with a deduced typeRichard Smith2015-02-111-3/+8
| | | | | | | | (or of a lambda init-capture, which is sort-of such a variable). The semantics of such constructs will change when we implement N3922, so we intend to warn on this in Clang 3.6 then change the semantics in Clang 3.7. llvm-svn: 228792
* Parse: Handle __declspec in a lambda definitionDavid Majnemer2015-02-041-0/+5
| | | | llvm-svn: 228121
* Follow-up to r217302: Don't crash on ~A::A in a postfix expr suffix followed ↵Nico Weber2015-02-021-0/+2
| | | | | | | | | | | | | | | | | by '<'. This used to crash, complaining "ObjectType and scope specifier cannot coexist": struct A { } b = b.~A::A <int>; The only other caller of ParseOptionalCXXScopeSpecifier() that passes in a non-empty ObjectType clears the ObjectType of the scope specifier comes back non-empty (see the tok::period case in Parser::ParsePostfixExpressionSuffix()), so do that here too. Found by SLi's bot. llvm-svn: 227781
* Remove a comment I accidentally added in r227581. No behavior change.Nico Weber2015-02-021-2/+1
| | | | llvm-svn: 227777
* Follow-up to r217302 and r227555: Don't crash on inline ~A::A() if A is an int.Nico Weber2015-01-301-1/+7
| | | | | | | | | | | | | | | | | | | Even with r227555, this still crashed: struct S { int A; ~A::A() {} }; That's because ParseOptionalCXXScopeSpecifier()'s call to ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema thought it's a good idea to fixit-correct "::" to ":". For the diagnostic improvement done in r217302, we never want :: to be interpreted as :, so fix this by setting ColonSacred to false temporarily. Found by SLi's bot. llvm-svn: 227581
* Follow-up to r217302: Don't crash on ~A::A() if A is undeclared.Nico Weber2015-01-301-1/+2
| | | | llvm-svn: 227555
* Initial support for C++ parameter completionFrancisco Lopes da Silva2015-01-211-2/+13
| | | | | | | | | | | | | | | | | | | | The improved completion in call context now works with: - Functions. - Member functions. - Constructors. - New expressions. - Function call expressions. - Template variants of the previous. There are still rough edges to be fixed: - Provide support for optional parameters. (fix known) - Provide support for member initializers. (fix known) - Provide support for variadic template functions. (fix unknown) - Others? llvm-svn: 226670
* Fix crash-on-invalid and name lookup when recovering from ~X::X() typo.Richard Smith2015-01-151-0/+5
| | | | llvm-svn: 226067
* Parse: It's cleaner to handle cxx_defaultarg_end in SkipUntil directlyDavid Majnemer2015-01-121-10/+3
| | | | llvm-svn: 225616
* Parse: Don't parse beyond the end of the synthetic default argument tokDavid Majnemer2015-01-121-3/+10
| | | | | | | | Recovery from malformed lambda introducers would find us consuming the synthetic default argument token, which is bad. Instead, stop right before that token. llvm-svn: 225613
* Parse: Don't crash when trailing return type is missingDavid Majnemer2015-01-091-5/+4
| | | | | | | | | Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo. Don't let the AST contain the malformed lambda. This fixes PR22122. llvm-svn: 225505
* Fix build breakageDavid Majnemer2014-12-291-1/+2
| | | | | | That's what I get for last second changes... llvm-svn: 224967
OpenPOWER on IntegriCloud