summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove trailing spaceFangrui Song2018-07-301-95/+95
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [Sema] Add fixit for unused lambda capturesAlexander Shaposhnikov2018-07-161-1/+5
| | | | | | | | | | | | | This diff adds a fixit to suggest removing unused lambda captures in the appropriate diagnostic. Patch by Andrew Comminos! Test plan: make check-all Differential revision: https://reviews.llvm.org/D48845 llvm-svn: 337148
* [NFC] Rename clang::AttributeList to clang::ParsedAttrErich Keane2018-07-131-4/+4
| | | | | | | Since The type no longer contains the 'next' item anymore, it isn't a list, so rename it to ParsedAttr to be more accurate. llvm-svn: 337005
* AttributeList de-listifying:Erich Keane2018-07-121-57/+48
| | | | | | | | | | | Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is switched to use a TinyPtrVector (and a ParsedAttributesView is created to have a non-allocating attributes list). DeclaratorChunk gets the later kind, Declarator/DeclSpec keep ParsedAttributes. Iterators are added to the ParsedAttribute types so that for-loops work. llvm-svn: 336945
* Diagnose missing 'template' keywords in contexts where a comma is not aRichard Smith2018-06-271-4/+7
| | | | | | | | | | binary operator. Factor out the checking for a comma within potential angle brackets and also call it from contexts where we parse a comma-separated list of arguments or initializers. llvm-svn: 335699
* Diagnose missing 'template' keywords in more cases.Richard Smith2018-06-261-0/+2
| | | | | | | | | | | | | | | | | | | | We track when we see a name-shaped expression followed by a '<' token and parse the '<' as a comparison. Then: * if we see a token sequence that cannot possibly be an expression but can be a template argument (in particular, a type-id) that follows either a ',' or the '<', diagnose that the '<' was supposed to start a template argument list, and * if we see '>()', diagnose that the '<' was supposed to start a template argument list. This only changes the diagnostic for error cases, and in practice appears to catch the most common cases where a missing 'template' keyword leads to parse errors within a template. Differential Revision: https://reviews.llvm.org/D48571 llvm-svn: 335687
* Restore pre-r335182 behavior for naming inherited constructors asRichard Smith2018-06-221-2/+4
| | | | | | | | | | | | | | members of dependent contexts. This permits cases where the names before and after the '::' in a dependent inherited constructor using-declaration do not match, but where we can nonetheless tell when parsing the template that a constructor is being named. Under (open) core language DR 2070, such cases will probably be ill-formed, but r335182 does not quite give that result and didn't intend to change this, so restore the old behavior for now. llvm-svn: 335381
* Related to PR37768: improve diagnostics for class name shadowing.Richard Smith2018-06-201-9/+7
| | | | | | | | | | | | Diagnose the name of the class being shadowed by using declarations, and improve the diagnostics for the case where the name of the class is shadowed by a non-static data member in a class with constructors. In the latter case, we now always give the "member with the same name as its class" diagnostic regardless of the relative order of the member and the constructor, rather than giving an inscrutible diagnostic if the constructor appears second. llvm-svn: 335182
* Improve diagnostics and error recovery for template name lookup.Richard Smith2018-05-111-1/+1
| | | | | | | | | | | | | For 'x::template y', consistently give a "no member named 'y' in 'x'" diagnostic if there is no such member, and give a 'template keyword not followed by a template' name error if there is such a member but it's not a template. In the latter case, add a note pointing at the non-template. Don't suggest inserting a 'template' keyword in 'X::Y<' if X is dependent if the lookup of X::Y was actually not a dependent lookup and found only non-templates. llvm-svn: 332076
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-8/+8
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Implement P0482R2, support for char8_t type.Richard Smith2018-05-011-0/+3
| | | | | | | | | | | | This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
* Parse A::template B as an identifier rather than as a template-id with noRichard Smith2018-04-271-28/+54
| | | | | | | | | | template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
* [C++17] Allow an empty expression in an if init statementZhihao Yuan2018-03-171-4/+18
| | | | | | | | | | | | | | | | | | | Summary: This fixes [PR35381](https://llvm.org/pr35381) and an additional bug where clang didn't warn about the C++17 extension when having an expression in the init statement. Thanks Nicolas Lesser for contributing the patch. Reviewers: rsmith Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D40445 llvm-svn: 327782
* Add missing direct-init / parameter-declaration-clause disambiguation whenRichard Smith2018-02-021-2/+4
| | | | | | parsing a trailing-return-type of a (function pointer) variable declaration. llvm-svn: 324151
* [Parse] Forward brace locations to TypeConstructExprVedant Kumar2018-01-171-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | When parsing C++ type construction expressions with list initialization, forward the locations of the braces to Sema. Without these locations, the code coverage pass crashes on the given test case, because the pass relies on getLocEnd() returning a valid location. Here is what this patch does in more detail: - Forwards init-list brace locations to Sema (ParseExprCXX), - Builds an InitializationKind with these locations (SemaExprCXX), and - Uses these locations for constructor initialization (SemaInit). The remaining changes fall out of introducing a new overload for creating direct-list InitializationKinds. Testing: check-clang, and a stage2 coverage-enabled build of clang with asserts enabled. Differential Revision: https://reviews.llvm.org/D41921 llvm-svn: 322729
* Again reverting an attempt to convert the DeclSpec enums into scoped enums.Faisal Vali2018-01-011-1/+1
| | | | | | | | | | | | - reverts r321622, r321625, and r321626. - the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen. - to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change. So in short - I give up (for now at least). Sorry about the noise. llvm-svn: 321628
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-1/+1
| | | | | | | | | | | | TypeSpecifierType into scoped enums with underlying types. - Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned. Previous failed attempt - wherein I did not specify an underlying type - was the sum of: https://reviews.llvm.org/rC321614 https://reviews.llvm.org/rC321615 llvm-svn: 321622
* Revert r321614 and r321615Faisal Vali2018-01-011-1/+1
| | | | | | | | - the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration. Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;) llvm-svn: 321616
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-1/+1
| | | | | | | | TypeSpecifierType into scoped enums. llvm-svn: 321614
* [NFC] Modernize enum DeclSpecContext into a scoped enum.Faisal Vali2017-12-311-2/+2
| | | | llvm-svn: 321590
* [NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum ↵Faisal Vali2017-12-301-19/+21
| | | | | | UnqualifiedIdKind. llvm-svn: 321574
* [NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum.Faisal Vali2017-12-291-9/+10
| | | | | | Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
* Allow conditions to be decomposed with structured bindingsZhihao Yuan2017-12-071-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This feature was discussed but not yet proposed. It allows a structured binding to appear as a //condition// if (auto [ok, val] = f(...)) So the user can save an extra //condition// if the statement can test the value to-be-decomposed instead. Formally, it makes the value of the underlying object of the structured binding declaration also the value of a //condition// that is an initialized declaration. Considering its logicality which is entirely evident from its trivial implementation, I think it might be acceptable to land it as an extension for now before I write the paper. Reviewers: rsmith, faisalv, aaron.ballman Reviewed By: rsmith Subscribers: aaron.ballman, cfe-commits Differential Revision: https://reviews.llvm.org/D39284 llvm-svn: 320011
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-3/+3
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* [c++2a] P0515R3: Support for overloaded operator<=>.Richard Smith2017-12-011-1/+1
| | | | | | No CodeGen support for MSABI yet, we don't know how to mangle this there. llvm-svn: 319513
* [Parser] Fix TryParseLambdaIntroducer() error handlingJan Korous2017-11-061-14/+21
| | | | | | | | rdar://35066196 Differential Revision: https://reviews.llvm.org/D39419 llvm-svn: 317493
* Fix comment typoJan Korous2017-11-021-1/+1
| | | | llvm-svn: 317216
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-081-1/+0
| | | | llvm-svn: 315196
* Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-0/+3
| | | | | | | | This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
* Revert "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-3/+0
| | | | | | | The clang-with-lto-ubuntu bot didn't like the new regression test, revert while I investigate the issue. llvm-svn: 312784
* Add _Float16 as a C/C++ source language typeSjoerd Meijer2017-09-081-0/+3
| | | | | | | | | | | This adds _Float16 as a source language type, which is a 16-bit floating point type defined in C11 extension ISO/IEC TS 18661-3. In follow up patches documentation and more tests will be added. Differential Revision: https://reviews.llvm.org/D33719 llvm-svn: 312781
* [Parser] Correct initalizer typos before lambda capture type is deduced.Volodymyr Sapsai2017-08-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | This is the same assertion as in https://reviews.llvm.org/D25206 that is triggered when RecordLayoutBuilder tries to compute the size of a field (for capture "typo_boo" in the test case) whose type hasn't been deduced. The fix is to add CorrectDelayedTyposInExpr call to the cases when we aren't disambiguating between an Obj-C message send and a lambda expression. rdar://problem/31760839 Reviewers: rsmith, ahatanak Reviewed By: arphaman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D36853 llvm-svn: 311480
* 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
OpenPOWER on IntegriCloud