summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseTentative.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration. Changes: - add the consteval keyword. - add parsing of consteval specifier for normal declarations and lambdas expressions. - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval. - adapt diagnostic about constexpr to print constexpr or consteval depending on the case. - add tests for basic semantic. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: eraman, efriedma, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61790 llvm-svn: 363362
* [OpenCL] Support pipe keyword in C++ modeSven van Haastregt2019-05-221-0/+2
| | | | | | | | | | | | Support the OpenCL C pipe feature in C++ for OpenCL mode, to preserve backwards compatibility with OpenCL C. Various changes had to be made in Parse and Sema to enable pipe-specific diagnostics, so enable a SemaOpenCL test for C++. Differential Revision: https://reviews.llvm.org/D62181 llvm-svn: 361382
* Rearrange and clean up how we disambiguate lambda-introducers from ObjCRichard Smith2019-05-201-14/+38
| | | | | | | | | | | | | | | | message sends, designators, and attributes. Instead of having the tentative parsing phase sometimes return an indicator to say what diagnostic to produce if parsing fails and sometimes ask the caller to run it again, consistently ask the caller to try parsing again if tentative parsing would fail or is otherwise unable to completely parse the lambda-introducer without producing an irreversible semantic effect. Mostly NFC, but we should recover marginally better in some error cases (avoiding duplicate diagnostics). llvm-svn: 361182
* Make tentative parsing to detect template-argument-lists less aggressiveRichard Smith2019-05-151-26/+24
| | | | | | | | | | | | | | | | | | (and less wrong). It's not correct to assume that X<something, Type> is always a template-id; there are a few cases where the comma takes us into a non-expression syntactic context in which 'Type' might be permissible. Stop doing that. This slightly regresses our error recovery on the cases where the construct is intended to be a template-id. We typically do still manage to diagnose a missing 'template' keyword, but we realize this too late to properly recover from the error. This fixes a regression introduced by r360308. llvm-svn: 360827
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-19/+85
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* [hip] Fix ambiguity from `>>>` of CUDA.Michael Liao2019-05-081-1/+3
| | | | | | | | | | | | | | | | | Summary: - For template arguments ending with `>>>`, we should cease lookahead and treat it as type-id firstly, so that deduction could work properly. Reviewers: tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61396 llvm-svn: 360214
* Improve function / variable disambiguation.Richard Smith2019-05-071-22/+22
| | | | | | | | Keep looking for decl-specifiers after an unknown identifier. Don't issue diagnostics about an error type specifier conflicting with later type specifiers. llvm-svn: 360117
* [PR41247] Fixed parsing of private keyword in C++.Anastasia Stulova2019-03-281-0/+5
| | | | | | | | | Fixed bug in C++ to prevent parsing 'private' as a valid address space qualifier. Differential Revision: https://reviews.llvm.org/D59874 llvm-svn: 357162
* [Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci2019-03-251-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CorrectionCandidateCallback unless we are going to do some typo correction The various CorrectionCandidateCallbacks are currently heap-allocated unconditionally. This was needed because of delayed typo correction. However these allocations represent currently 15.4% of all allocations (number of allocations) when parsing all of Boost (!), mostly because of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes and isCXXDeclarationSpecifier. Note that all of these callback objects are small. Let's not do this. Instead initially allocate the callback on the stack, and only do a heap allocation if we are going to do some typo correction. Do this by: 1. Adding a clone function to each callback, which will do a polymorphic clone of the callback. This clone function is required to be implemented by every callback (of which there is a fair amount). Make sure this is the case by making it pure virtual. 2. Use this clone function when we are going to try to correct a typo. This additionally cut the time of -fsyntax-only on all of Boost by 0.5% (not that much, but still something). No functional changes intended. Differential Revision: https://reviews.llvm.org/D58827 Reviewed By: rnk llvm-svn: 356925
* [OpenCL] Allow addr space spelling without __ prefix in C++.Anastasia Stulova2019-03-251-0/+1
| | | | | | | | | | | | | | For backwards compatibility we allow alternative spelling of address spaces - 'private', 'local', 'global', 'constant', 'generic'. In order to accept 'private' correctly, parsing has been changed to understand different use cases - access specifier vs address space. Fixes PR40707 and PR41011! Differential Revision: https://reviews.llvm.org/D59603 llvm-svn: 356888
* [MS] Fix for Bug 8446, template instantiation without a 'typename' keywordReid Kleckner2019-02-261-0/+11
| | | | | | | | Patch by Zahira Ammarguellat! Differential Revision: https://reviews.llvm.org/D41950 llvm-svn: 354838
* [OpenCL][PR40707] Allow OpenCL C types in C++ mode.Anastasia Stulova2019-02-151-0/+9
| | | | | | Allow all OpenCL types to be parsed in C++ mode. llvm-svn: 354121
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-5/+5
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFCFangrui Song2018-10-201-2/+2
| | | | llvm-svn: 344859
* [cxx2a] P0614R1: Support init-statements in range-based for loops.Richard Smith2018-09-281-16/+69
| | | | | | | We don't yet support this for the case where a range-based for loop is implicitly rewritten to an ObjC for..in statement. llvm-svn: 343350
* Remove trailing spaceFangrui Song2018-07-301-19/+19
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [MS] Add L__FUNCSIG__ for compatibilityReid Kleckner2018-07-261-0/+1
| | | | | | | | | | Clang already has L__FUNCTION__ as a workaround for dealing with pre-processor code that expects to be able to do L##__FUNCTION__ in a macro. This patch implements the same logic for __FUNCSIG__. Fixes PR38295. llvm-svn: 338083
* [OpenCL] Fixed parsing of address spaces for C++.Anastasia Stulova2018-06-221-0/+5
| | | | | | | Added address space tokens to C++ parsing code to be able to parse declarations that start from an address space keyword. llvm-svn: 335362
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-3/+3
| | | | | | | | | | | | | | | | | | | 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
* Revert rC330794 and some dependent tiny bug fixes Faisal Vali2018-04-261-1/+0
| | | | | | | | | | | | | | See Richard's humbling feedback here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226482.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226486.html Wish I'd had the patience to solicit the feedback prior to committing :) Sorry for the noise guys. Thank you Richard for being the steward that clang deserves! llvm-svn: 330888
* [c++2a] [concepts] Add rudimentary parsing support for template concept ↵Faisal Vali2018-04-251-0/+1
| | | | | | | | | | | | | | declarations This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly. See the test file to get a sense of the basic parsing that this patch supports. There is much more work to be done before concepts are usable... Thanks Changyu! llvm-svn: 330794
* [MS] Accept __unaligned as a qualifier on member function pointersReid Kleckner2018-03-071-1/+2
| | | | | | | | | | We need to treat __unaligned like the other 'cvr' qualifiers when it appears at the end of a function prototype. We weren't doing that in some tentative parsing. Fixes PR36638. llvm-svn: 326962
* Fix a couple of cases where we would fail to correctly parse deduced class ↵Richard Smith2018-02-281-8/+31
| | | | | | | | | | | | | | | | template specialization types. Specifically, we would not properly parse these types within template arguments (for non-type template parameters), and in tentative parses. Fixing both of these essentially requires that we parse deduced template specialization types as types in all contexts, even in template argument lists -- in particular, tentative parsing may look ahead and annotate a deduced template specialization type before we figure out that we're actually supposed to treat the tokens as a template-name. We deal with this by simply permitting deduced template specialization types when parsing template arguments, and converting them to template template arguments. llvm-svn: 326299
* Add missing direct-init / parameter-declaration-clause disambiguation whenRichard Smith2018-02-021-1/+5
| | | | | | parsing a trailing-return-type of a (function pointer) variable declaration. llvm-svn: 324151
* Remove old concepts parsing codeHubert Tong2017-12-071-2/+0
| | | | | | | | | | | | | | | | | | Summary: This is so we can implement concepts per P0734R0. Relevant failing test cases are disabled. Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson Reviewed By: saar.raz Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40380 Patch by Changyu Li! llvm-svn: 319992
* 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
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-0/+2
| | | | llvm-svn: 304481
* Fix valid-for-expr ellipses eaten as invalid declHubert Tong2017-05-201-12/+13
| | | | | | | | | | | | | | | | | | | | | | Summary: The trial parse for declarative syntax accepts an invalid pack declaration syntax, which is ambiguous with valid pack expansions of expressions. This commit removes the invalid pack declaration syntax to avoid mistaking valid pack expansions as invalid declarator components. Additionally, the trial parse of a //template-argument-list// then needs to handle the optional ellipsis that is part of that grammar, as opposed to relying on the trial parse for declarators accepting stray ellipses. Reviewers: rsmith, rcraik, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33339 llvm-svn: 303472
* Fix the location of "missing ';'" suggestions after annotation tokens.Richard Smith2017-05-181-8/+11
| | | | | | | | | | 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
* regcall: Implement regcall Calling Conv in clangErich Keane2016-11-021-1/+3
| | | | | | | | | | This patch implements the register call calling convention, which ensures as many values as possible are passed in registers. CodeGen changes were committed in https://reviews.llvm.org/rL284108. Differential Revision: https://reviews.llvm.org/D25204 llvm-svn: 285849
* P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith2016-07-221-1/+8
| | | | | | | | | | | 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-32/+113
| | | | | | | | | | | | | | | | | | 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
* Convert another case over to RevertingTentativeParsingAction.Richard Smith2016-06-291-4/+1
| | | | llvm-svn: 274167
* Switch to an RAII object to revert tentative parsing automatically.Richard Smith2016-06-291-27/+13
| | | | llvm-svn: 274165
* [MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko2016-05-111-1/+1
| | | | | | | | | | | This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367 and PR27666. Differential Revision: http://reviews.llvm.org/D20103 llvm-svn: 269220
* 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 r268727, it caused PR27666.Nico Weber2016-05-061-1/+1
| | | | llvm-svn: 268736
* [MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko2016-05-061-1/+1
| | | | | | | | | | | This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367. Differential Revision: http://reviews.llvm.org/D19654 llvm-svn: 268727
* 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
* Revert r266415, it broke parsing SDK headers (PR27367).Nico Weber2016-04-151-1/+1
| | | | llvm-svn: 266431
* [MSVC Compat] Implementation of __unaligned (MS extension) as a type qualifierAndrey Bokhanko2016-04-151-1/+1
| | | | | | | | | | | This patch implements __unaligned as a type qualifier; before that, it was modeled as an attribute. Proper mangling of __unaligned is implemented as well. Some OpenCL code/tests are tangenially affected, as they relied on existing number and sizes of type qualifiers. Differential Revision: http://reviews.llvm.org/D18596 llvm-svn: 266415
* 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
* [OpenCL] Move OpenCLImageTypes.def from clangAST to clangBasic library.Alexey Bader2016-04-131-1/+1
| | | | | | | | | | Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header". This fixes the modules build. Differential revision: http://reviews.llvm.org/D18954 Reviewers: Richard Smith, Vassil Vassilev. llvm-svn: 266180
* [OpenCL] Complete image types support.Alexey Bader2016-04-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I. Current implementation of images is not conformant to spec in the following points: 1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine: void write_image(write_only image2d_t img); kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code which is disallowed according to s6.13.14. 2. It discards access qualifier on generated code, which leads to generated code for the above example: call void @write_image(%opencl.image2d_t* %img); In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images. Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently. 3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names. 4. Default access qualifier read_only is to be added if not provided explicitly. II. This patch corrects the above points as follows: 1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type. 2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers). 3. Improves testing of images in Clang. Author: Anastasia Stulova Reviewers: bader, mgrang. Subscribers: pxli168, pekka.jaaskelainen, yaxunl. Differential Revision: http://reviews.llvm.org/D17821 llvm-svn: 265783
* Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith2015-11-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud