summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Rename cxx1z -> cxx17 across all diagnostic IDs.Richard Smith2017-08-131-1/+1
| | | | llvm-svn: 310805
* Place implictly declared functions at block scopeMomchil Velikov2017-08-101-1/+2
| | | | | | | | | | | | Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
* [NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjectsFaisal Vali2017-05-231-22/+9
| | | | | | | | | | A refactoring of TemplateIdAnnotation that uses TrailingObjects to create a variably-sized object on the heap. https://reviews.llvm.org/D31414 Thanks to Aaron B for the review! llvm-svn: 303594
* Fix the location of "missing ';'" suggestions after annotation tokens.Richard Smith2017-05-181-13/+10
| | | | | | | | | | We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
* Changes missed from r302732.Richard Smith2017-05-101-5/+2
| | | | llvm-svn: 302737
* [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped EnumFaisal Vali2017-04-011-5/+7
| | | | | | | | - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
* Publish RAIIObjectsForParser.h for external usage.Vassil Vassilev2017-03-231-2/+2
| | | | | | | | | Some clients (eg the cling interpreter) need to recover their parser from errors. Patch by Axel Naumann (D31190)! llvm-svn: 298606
* Implement DR 373 "Lookup on namespace qualified name in using-directive"Matthias Gehre2017-03-171-4/+7
| | | | | | | | | | | | | | Summary: 3.4.6 [basic.lookup.udir] paragraph 1: In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered. Reviewers: rsmith, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30848 llvm-svn: 298126
* More fixes for places where 'decltype(auto)' is permitted in the C++ grammar ↵Richard Smith2017-02-081-1/+2
| | | | | | but makes no sense. llvm-svn: 294509
* Don't crash on 'decltype(auto)::'. Rather than treating it as a meaninglessRichard Smith2017-02-081-1/+4
| | | | | | | | nested-name-specifier (as the standard appears to require), treat it as the type specifier 'decltype(auto)' followed by a nested-name-specifier starting with '::'. llvm-svn: 294506
* P0091R3: Implement basic parsing support for C++17 deduction-guides.Richard Smith2017-02-071-0/+11
| | | | | | | | | | | We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-1/+2
| | | | | | | | | | | | | | | 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
* Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-201-22/+18
| | | | | | | Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove redundant passing around of a "ContainsAutoType" flag.Richard Smith2017-01-121-2/+1
| | | | | | | | | | | | This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
* Remove repeated word in comment (NFC)Malcolm Parsons2017-01-111-1/+1
| | | | llvm-svn: 291667
* [Parser] Correct typo after lambda capture initializer is parsed.Akira Hatanaka2016-12-201-0/+2
| | | | | | | | | | | | | | | | This patch fixes an assertion that is triggered when RecordLayoutBuilder tries to compute the size of a field (for capture "name" in the test case) whose type hasn't been deduced. The patch fixes the bug by correcting the typo of the capture initializer after the initializer is parsed and before setting the expression for the annotation token. Fixes PR30566. rdar://problem/23380132 Differential Revision: https://reviews.llvm.org/D25206 llvm-svn: 290156
* Remove special error recovery for ::(id)Reid Kleckner2016-12-091-46/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The code pattern used to implement the token rewriting hack doesn't interact well with token caching in the pre-processor. As a result, clang would crash on 'int f(::(id));' while doing a tenative parse of the contents of the outer parentheses. The original code from PR11852 still doesn't crash the compiler. This error recovery also often does the wrong thing with member function pointers. The test case from the original PR doesn't recover the right way either: void S::(*pf)() = S::f; // should be 'void (S::*pf)()' Instead we were recovering as 'void S::*pf()', which is still wrong. If we still think that users mistakenly parenthesize identifiers in nested name specifiers, we should change clang to intentionally parse that form with an error, rather than doing a token rewrite. Fixes PR26623, but I think there will be many more bugs like this around token rewriting in the parser. Reviewers: rsmith, rtrieu Differential Revision: https://reviews.llvm.org/D25882 llvm-svn: 289273
* 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
OpenPOWER on IntegriCloud