aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Parse/ParseTentative.cpp
AgeCommit message (Collapse)AuthorFilesLines
2018-04-26Revert rC330794 and some dependent tiny bug fixes Faisal Vali1-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
2018-04-25[c++2a] [concepts] Add rudimentary parsing support for template concept ↵Faisal Vali1-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
2018-03-07[MS] Accept __unaligned as a qualifier on member function pointersReid Kleckner1-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
2018-02-28Fix a couple of cases where we would fail to correctly parse deduced class ↵Richard Smith1-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
2018-02-02Add missing direct-init / parameter-declaration-clause disambiguation whenRichard Smith1-1/+5
parsing a trailing-return-type of a (function pointer) variable declaration. llvm-svn: 324151
2017-12-07Remove old concepts parsing codeHubert Tong1-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
2017-09-08Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer1-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
2017-09-08Revert "Add _Float16 as a C/C++ source language type"Sjoerd Meijer1-3/+0
The clang-with-lto-ubuntu bot didn't like the new regression test, revert while I investigate the issue. llvm-svn: 312784
2017-09-08Add _Float16 as a C/C++ source language typeSjoerd Meijer1-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
2017-06-01Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova1-0/+2
llvm-svn: 304481
2017-05-20Fix valid-for-expr ellipses eaten as invalid declHubert Tong1-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
2017-05-18Fix the location of "missing ';'" suggestions after annotation tokens.Richard Smith1-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
2016-11-02regcall: Implement regcall Calling Conv in clangErich Keane1-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
2016-07-22P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith1-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
2016-06-29P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.Richard Smith1-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
2016-06-29Convert another case over to RevertingTentativeParsingAction.Richard Smith1-4/+1
llvm-svn: 274167
2016-06-29Switch to an RAII object to revert tentative parsing automatically.Richard Smith1-27/+13
llvm-svn: 274165
2016-05-11[MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko1-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
2016-05-09Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic1-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
2016-05-06Revert r268727, it caused PR27666.Nico Weber1-1/+1
llvm-svn: 268736
2016-05-06[MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko1-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
2016-04-15Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic1-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
2016-04-15Revert r266415, it broke parsing SDK headers (PR27367).Nico Weber1-1/+1
llvm-svn: 266431
2016-04-15[MSVC Compat] Implementation of __unaligned (MS extension) as a type qualifierAndrey Bokhanko1-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
2016-04-13Enable support for __float128 in ClangNemanja Ivanovic1-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
2016-04-13[OpenCL] Move OpenCLImageTypes.def from clangAST to clangBasic library.Alexey Bader1-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
2016-04-08[OpenCL] Complete image types support.Alexey Bader1-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
2015-11-11Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith1-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
2015-07-07Implement the Objective-C __kindof type qualifier.Douglas Gregor1-0/+1
The __kindof type qualifier can be applied to Objective-C object (pointer) types to indicate id-like behavior, which includes implicit "downcasting" of __kindof types to subclasses and id-like message-send behavior. __kindof types provide better type bounds for substitutions into unspecified generic types, which preserves more type information. llvm-svn: 241548
2015-07-07Handle Objective-C type arguments.Douglas Gregor1-1/+1
Objective-C type arguments can be provided in angle brackets following an Objective-C interface type. Syntactically, this is the same position as one would provide protocol qualifiers (e.g., id<NSCopying>), so parse both together and let Sema sort out the ambiguous cases. This applies both when parsing types and when parsing the superclass of an Objective-C class, which can now be a specialized type (e.g., NSMutableArray<T> inherits from NSArray<T>). Check Objective-C type arguments against the type parameters of the corresponding class. Verify the length of the type argument list and that each type argument satisfies the corresponding bound. Specializations of parameterized Objective-C classes are represented in the type system as distinct types. Both specialized types (e.g., NSArray<NSString *> *) and unspecialized types (NSArray *) are represented, separately. llvm-svn: 241542
2015-06-30[CONCEPTS] Parsing of concept keywordHubert Tong1-0/+2
Summary: This change adds parsing for the concept keyword in a declaration and tracks the location. Diagnostic testing added for invalid use of concept keyword. Reviewers: faisalv, fraggamuffin, rsmith, hubert.reinterpretcast Reviewed By: rsmith, hubert.reinterpretcast Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10528 Patch by Nathan Wilson! llvm-svn: 241060
2015-06-24Replace __double_underscored type nullability qualifiers with ↵Douglas Gregor1-5/+5
_Uppercase_underscored Addresses a conflict with glibc's __nonnull macro by renaming the type nullability qualifiers as follows: __nonnull -> _Nonnull __nullable -> _Nullable __null_unspecified -> _Null_unspecified This is the major part of rdar://problem/21530726, but does not yet provide the Darwin-specific behavior for the old names. llvm-svn: 240596
2015-06-22Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko1-1/+1
llvm-svn: 240353
2015-06-22Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko1-1/+1
The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
2015-06-19Introduce type nullability specifiers for C/C++.Douglas Gregor1-1/+6
Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
2015-06-18[clang] Refactoring of conditions so they use isOneOf() instead of multiple ↵Daniel Marjamaki1-40/+26
is(). llvm-svn: 240008
2015-02-23Revert "Improve declaration / expression disambiguation around ↵Justin Bogner1-44/+22
ptr-operators, and use" This seems to break mixing function-style and c-style casts, and is breaking bootstrapping llvm. This reverts r230261. llvm-svn: 230274
2015-02-23Improve declaration / expression disambiguation around ptr-operators, and useRichard Smith1-22/+44
the presence of an abstract declarator with a ptr-operator as proof that a construct cannot parse as an expression to improve diagnostics along error recovery paths. llvm-svn: 230261
2015-01-12[PowerPC]To provide better compatibility with gcc I added the __bool keyword ↵Bill Seurer1-0/+1
to the Alitivec support in clang. __bool is functionally identical to using bool when declaring vector types. For example: vector bool char v_bc; vector __bool char v___bc; clang already supported vector/__vector and pixel/__pixel but was missing __bool. http://llvm.org/bugs/show_bug.cgi?id=19220 For reference: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html http://reviews.llvm.org/D6882 llvm-svn: 225664
2014-12-28Don't crash on surprising tokens in default parameter template lists.Nico Weber1-1/+3
Fixes this snippet from SLi's afl fuzzer output: class { i (x = <, enum This parsed i as a function, x as a paramter, and the stuff after < as a template list. This then called TryConsumeDeclarationSpecifier() which called TryAnnotateCXXScopeToken() without checking the preconditions of this function. Check them before calling, like all other callers of TryAnnotateCXXScopeToken() do. A more readable reproducer that causes the same crash is class { void i(int x = MyTemplateClass<int, union int>::foo()); }; The reduced version used an eof token as surprising token, but kw_int works just as well to repro and is easier to insert into a test file. llvm-svn: 224906
2014-11-08[c++1z] Support for u8 character literals.Richard Smith1-0/+1
llvm-svn: 221576
2014-11-05Filter out non-static class members when correcting non-member-references.Kaelyn Takata1-7/+23
llvm-svn: 221319
2014-10-27Pass around CorrectionCandidateCallbacks as unique_ptrs soKaelyn Takata1-4/+4
TypoCorrectionConsumer can keep the callback around as long as needed. llvm-svn: 220693
2014-10-24Add frontend support for __vectorcallReid Kleckner1-0/+3
Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
2014-10-14Be smarter when parsing variable declarations with unknown types.Kaelyn Takata1-1/+4
Specifically, avoid typo-correcting the variable name into a type before typo-correcting the actual type name in the declaration. Doing so results in a very unpleasant cascade of errors, with the typo correction of the actual type name being buried in the middle. llvm-svn: 219732
2014-09-26-ms-extensions: Implement __super scope specifier (PR13236).Nikola Smiljanic1-0/+1
We build a NestedNameSpecifier that records the CXXRecordDecl in which __super appeared. Name lookup is performed in all base classes of the recorded CXXRecordDecl. Use of __super is allowed only inside class and member function scope. llvm-svn: 218484
2014-05-16Replace a fake enum class with the real thing.Richard Smith1-174/+174
llvm-svn: 208943
2014-04-08Add support for MSVC's __FUNCSIG__Reid Kleckner1-0/+1
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the calling convention. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D3311 llvm-svn: 205780
2014-01-10TryConsume parser cleanupsAlp Toker1-9/+4
Also move some comments into the block they were meant to describe. llvm-svn: 198935
2013-12-18Remove OpenCL-specific type keywords and specifiersAlp Toker1-8/+0
This commit kills off custom type specifier and keyword handling of OpenCL C data types. Although the OpenCL spec describes them as keywords, we can handle them more elegantly as predefined types. This should provide better error correction and code completion as well as simplifying the implementation. The primary intention is however to simplify the C/C++ parser and save some packed bits on AST structures that had been extended in r170432 just for OpenCL. llvm-svn: 197578