summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove trailing spaceFangrui Song2018-07-301-64/+64
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Parse a possible trailing postfix expression suffix after a fold expressionNicolas Lesser2018-07-271-5/+15
| | | | | | | | | | | | | | | | | Summary: This patch allows the parsing of a postfix expression involving a fold expression, which is legal as a fold-expression is a primary-expression. See also https://llvm.org/pr38282 Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49848 llvm-svn: 338170
* [MS] Add L__FUNCSIG__ for compatibilityReid Kleckner2018-07-261-0/+3
| | | | | | | | | | 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
* Refactor checking of switch conditions and case values.Richard Smith2018-07-261-0/+8
| | | | | | | | | | | | | | | | | | | Check each case value in turn while parsing it, performing the conversion to the switch type within the context of the expression itself. This will become necessary in order to properly handle cleanups for temporaries created as part of the case label (in an upcoming patch). For now it's just good hygiene. This necessitates moving the checking for the switch condition itself to earlier, so that the destination type is available when checking the case labels. As a nice side-effect, we get slightly improved diagnostic quality and error recovery by separating the case expression checking from the case statement checking and from tracking whether there are discarded case labels. llvm-svn: 338056
* AttributeList de-listifying:Erich Keane2018-07-121-26/+24
| | | | | | | | | | | 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-74/+17
| | | | | | | | | | 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-10/+53
| | | | | | | | | | | | | | | | | | | | 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
* Optionally add code completion results for arrow instead of dotIvan Donchevskii2018-05-251-5/+21
| | | | | | | | | | | | | Currently getting such completions requires source correction, reparsing and calling completion again. And if it shows no results and rollback is required then it costs one more reparse. With this change it's possible to get all results which can be later filtered to split changes which require correction. Differential Revision: https://reviews.llvm.org/D41537 llvm-svn: 333272
* Improve diagonstic for braced-init-list as operand to ?: expression.Richard Smith2018-05-241-6/+22
| | | | llvm-svn: 333234
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-11/+11
| | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | 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-1/+1
| | | | | | | | | | 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
* Again reverting an attempt to convert the DeclSpec enums into scoped enums.Faisal Vali2018-01-011-5/+4
| | | | | | | | | | | | - 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-4/+5
| | | | | | | | | | | | 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-5/+4
| | | | | | | | - 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-4/+5
| | | | | | | | TypeSpecifierType into scoped enums. llvm-svn: 321614
* [NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum.Faisal Vali2017-12-291-6/+6
| | | | | | Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
* [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith2017-12-141-6/+11
| | | | | | | | | | | | | | | Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* Fix usage of right shift operator in fold expressionsRichard Smith2017-10-311-3/+4
| | | | | | | | The right shift operator was not seen as a valid operator in a fold expression, which is PR32563. Patch by Nicolas Lesser ("Blitz Rakete")! llvm-svn: 317032
* mplement __has_unique_object_representationsErich Keane2017-10-241-0/+1
| | | | | | | | | | | | A helper builtin to facilitate implementing the std::has_unique_object_representations type trait. Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942 Also already exists in GCC and MSVC. Differential Revision: https://reviews.llvm.org/D39064 llvm-svn: 316518
* Properly parse a postfix expression following a Boolean literal. Fixes PR34273.Aaron Ballman2017-09-281-1/+2
| | | | | | Patch by Nicolas Lesser. llvm-svn: 314463
* Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-0/+1
| | | | | | | | 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-1/+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/+1
| | | | | | | | | | | 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
* std::function -> llvm::function_ref. NFC.Benjamin Kramer2017-09-011-1/+1
| | | | llvm-svn: 312336
* Place implictly declared functions at block scopeMomchil Velikov2017-08-101-1/+1
| | | | | | | | | | | | 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
* fix trivial typos in comments; NFCHiroshi Inoue2017-07-021-2/+2
| | | | llvm-svn: 306969
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-2/+3
| | | | llvm-svn: 304475
* Fix PR25627: constant expressions being odr-used in template arguments.Faisal Vali2017-05-201-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext) Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node. For e.g: template<int> struct X { }; void f() { const int N = 10; X<N> x; // should be OK. [] { return X<N>{}; }; // Should be OK - no capture - but clang errors! } See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627 In summary (and reiteration), the fix is as follows: - Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right) - Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext. See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed. Thanks Richard! llvm-svn: 303492
* Fix the location of "missing ';'" suggestions after annotation tokens.Richard Smith2017-05-181-2/+2
| | | | | | | | | | 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
* When we see a '<' operator, check whether it's a probable typo for a ↵Richard Smith2017-05-101-0/+34
| | | | | | | | | | | | | | | | | | | template-id. The heuristic that we use here is: * the left-hand side must be a simple identifier or a class member access * the right-hand side must be '<' followed by either a '>' or by a type-id that cannot be an expression (in particular, not followed by '(' or '{') * there is a '>' token matching the '<' token The second condition guarantees the expression would otherwise be ill-formed. If we're confident that the user intended the name before the '<' to be interpreted as a template, diagnose the fact that we didn't interpret it that way, rather than diagnosing that the template arguments are not valid expressions. llvm-svn: 302615
* [CodeCompletion] Complete platform names in @available expressionsAlex Lorenz2017-05-091-0/+5
| | | | | | rdar://32074504 llvm-svn: 302545
* Add support for pretty platform names to `@available`/Alex Lorenz2017-05-091-2/+4
| | | | | | | | | | | | | `__builtin_available` This commit allows us to use the macOS/iOS/tvOS/watchOS platform names in `@available`/`__builtin_available`. rdar://32067795 Differential Revision: https://reviews.llvm.org/D33000 llvm-svn: 302540
* Parse: cleanup some bleeding whitespaceSaleem Abdulrasool2017-04-201-2/+3
| | | | | | Clean up some bleeding whitespace that I noticed. NFC llvm-svn: 300908
* [Sema] Add __is_aggregate type-traitEric Fiselier2017-04-121-0/+2
| | | | | | | | | | | | | | | | Summary: [LWG 2911](http://cplusplus.github.io/LWG/lwg-defects.html#2911) adds `std::is_aggregate` to the library, which requires a new builtin trait. This patch implements `__is_aggregate`. Reviewers: rsmith, majnemer, aaron.ballman Reviewed By: aaron.ballman Subscribers: STL_MSFT, cfe-commits Differential Revision: https://reviews.llvm.org/D31513 llvm-svn: 300116
* [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped EnumFaisal Vali2017-04-011-9/+13
| | | | | | | | - 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
* Reapplied r298976 [OpenCL] Added parsing for OpenCL vector types.Egor Churaev2017-03-291-3/+51
| | | | llvm-svn: 298992
* Reverted r298976 [OpenCL] Added parsing for OpenCL vector types.Egor Churaev2017-03-291-55/+4
| | | | llvm-svn: 298978
* [OpenCL] Added parsing for OpenCL vector types.Egor Churaev2017-03-291-4/+55
| | | | | | | | | | | | Reviewers: cfe-commits, Anastasia Reviewed By: Anastasia Subscribers: yaxunl, bader Differential Revision: https://reviews.llvm.org/D31183 llvm-svn: 298976
* 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
* PR24440: Do not silently discard a fold-expression appearing as the operand ↵Richard Smith2017-02-151-1/+1
| | | | | | of a cast-expression. llvm-svn: 295224
* P0091R3: Implement basic parsing support for C++17 deduction-guides.Richard Smith2017-02-071-0/+1
| | | | | | | | | | | 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
* [code-completion] Fix crash when trying to do postfix completion of instance ↵Argyrios Kyrtzidis2017-01-151-3/+4
| | | | | | member inside a static function. llvm-svn: 292052
* [NFC] Rename RAII ExpressionEvaluationContext variable from Unevaluated to ↵Faisal Vali2017-01-101-1/+1
| | | | | | | | ConstantEvaluated when parsing a constant expression. This renaming makes it consistent with the context it actually sets: Sema::ConstantEvaluated. llvm-svn: 291525
* [ObjC] The declarator for a block literal should be a definitionAlex Lorenz2017-01-061-0/+2
| | | | | | | | | | | This change avoids the -Wstrict-prototypes warning for block literals with an empty argument list or without argument lists. rdar://15060615 Differential Revision: https://reviews.llvm.org/D28296 llvm-svn: 291231
* Store decls in prototypes on the declarator instead of in the ASTReid Kleckner2016-12-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeCompletion] Provide Objective-C class property completion resultsAlex Lorenz2016-12-081-1/+7
| | | | | | | | | | | | This commit provides class property code completion results. It supports explicit and implicit class properties, but the special block completion is done only for explicit properties right now. rdar://25636195 Differential Revision: https://reviews.llvm.org/D27053 llvm-svn: 289058
* [CodeCompletion] Add a block property setter completion resultAlex Lorenz2016-10-181-3/+4
| | | | | | | | | | | | | | | | | | This commit changes code completion results for Objective-C block properties: clang now suggests an additional completion result that displays the block property together with '=' and the block literal placeholder for the appropriate readwrite block properties. This commit uses a simple heuristic to determine when it's appropriate to suggest a setter completion for block properties: the additional block setter completion is provided iff the member access that's being completed is a standalone statement. rdar://28481726 Differential Revision: https://reviews.llvm.org/D25520 llvm-svn: 284472
* [Parser] Fix bug where delayed typo in conditional expression was corrected ↵Erik Pilkington2016-07-291-3/+4
| | | | | | | | | | twice Patch by David Tarditi! Differential revision: https://reviews.llvm.org/D22930 llvm-svn: 277095
OpenPOWER on IntegriCloud