summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Use DeclSpec for quals in DeclaratorChunk::FunctionTypeInfo.Anastasia Stulova2019-01-091-4/+0
| | | | | | | | | | Rather than duplicating data fields, use DeclSpec directly to store the qualifiers for the functions/methods. This change doesn't handle attributes yet and has to be extended further. Differential revision: https://reviews.llvm.org/D55948 llvm-svn: 350703
* [CodeComplete] Fill preferred type on binary expressionsIlya Biryukov2018-12-131-4/+5
| | | | | | | | | | | | Reviewers: kadircet Reviewed By: kadircet Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D55648 llvm-svn: 349053
* 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-12/+12
| | | | | | | | | | 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
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-261-1/+3
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* [ms] Prevent explicit constructor name lookup if scope is missingWill Wilson2018-10-251-1/+2
| | | | | | | | | | | MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope. This avoids a compile-time crash due to confusing a member access for a constructor name. Test case included. All tests pass. Differential Revision: https://reviews.llvm.org/D53441 llvm-svn: 345258
* [CodeComplete] Generate completion fix-its for C code as wellIvan Donchevskii2018-09-211-0/+2
| | | | | | | | | Current completion fix-its approach does not provide OtherOpBase for C code. But we can easily proceed in this case taking the original Base type. Differential Revision: https://reviews.llvm.org/D52261 llvm-svn: 342721
* [clang] Make sure codecompletion is called for calls even when inside a token.Kadir Cetinkaya2018-09-101-0/+11
| | | | | | | | | | | | | | | | | Summary: Currently CodeCompleteCall only gets called after a comma or parantheses. This patch makes sure it is called even at the cases like: ```foo(1^);``` Reviewers: ilya-biryukov, ioeric, hokein Reviewed By: ilya-biryukov Subscribers: MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D51038 llvm-svn: 341824
* [CodeComplete] Clearly distinguish signature help and code completion.Ilya Biryukov2018-09-071-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Code completion in clang is actually a mix of two features: - Code completion is a familiar feature. Results are exposed via the CodeCompleteConsumer::ProcessCodeCompleteResults callback. - Signature help figures out if the current expression is an argument of some function call and shows corresponding signatures if so. Results are exposed via CodeCompleteConsumer::ProcessOverloadCandidates. This patch refactors the implementation to untangle those two from each other and makes some naming tweaks to avoid confusion when reading the code. The refactoring is required for signature help fixes, see D51038. The only intended behavior change is the order of callbacks. ProcessOverloadCandidates is now called before ProcessCodeCompleteResults. Reviewers: sammccall, kadircet Reviewed By: sammccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51782 llvm-svn: 341660
* [CodeComplete] Report location of opening parens for signature helpIlya Biryukov2018-08-301-3/+5
| | | | | | | | | | | | | | Summary: Used in clangd. Reviewers: sammccall Reviewed By: sammccall Subscribers: ioeric, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D51436 llvm-svn: 341063
* [Parser] Support alternative operator token keyword args in Objective-C++Erik Pilkington2018-08-211-0/+13
| | | | | | | | rdar://30741878 Differential revision: https://reviews.llvm.org/D50527 llvm-svn: 340301
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* 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
OpenPOWER on IntegriCloud