summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-121-1/+2
| | | | | | | | | | | | | | | | a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit 5c845c1c50ac89a6f12557d1571678f3d1432478)
* Revert "PR45083: Mark statement expressions as being dependent if they ↵Hans Wennborg2020-03-121-2/+1
| | | | | | | | | appear in" This turned out to cause problems, and was reverted on master together with its follow-up change in 66addf8e803618758457e4d578c5084e322ca448. This reverts commit 3a843031a5ad83a00d2603f623881cb2b2bf719d.
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-041-1/+2
| | | | | | | | | | dependent contexts. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit bdad0a1b79273733df9acc1be4e992fa5d70ec56)
* [Concepts] Make constraint expressions unevaluated until satisfaction checkingSaar Raz2020-01-241-2/+2
| | | | | | | | | As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic constraints only become constant evaluated during satisfaction checking. Change the evaluation context during parsing and instantiation of constraints to unevaluated. (cherry picked from commit 73eaf62463b4a29adf4194685af12d1a5d172987)
* [Concepts] Requires ExpressionsSaar Raz2020-01-241-0/+4
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith2020-01-241-2/+3
| | | | | | | | | | | | | | A TemplateIdAnnotation represents only a template-id, not a nested-name-specifier plus a template-id. Don't make a redundant copy of the CXXScopeSpec and store it on the template-id annotation. This slightly improves error recovery by more properly handling the case where we would form an invalid CXXScopeSpec while parsing a typename specifier, instead of accidentally putting the token stream into a broken "annot_template_id with a scope specifier, but with no preceding annot_cxxscope token" state. (cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2020-01-101-2/+0
|
* [Concepts] Function trailing requires clausesSaar Raz2020-01-091-46/+258
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-7/+5
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-151-5/+7
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-7/+5
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 llvm-svn: 374826
* Replace some custom C11 extension warnings with the generic warning.Aaron Ballman2019-08-271-3/+2
| | | | llvm-svn: 370066
* Diagnose use of _Thread_local as an extension when not in C11 mode.Aaron Ballman2019-08-261-1/+1
| | | | llvm-svn: 369954
* Stop abusing SuppressAllDiagnostics when speculatively determiningRichard Smith2019-08-161-3/+3
| | | | | | whether an expression would be valid during error recovery. llvm-svn: 369145
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-4/+4
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-0/+3
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
* [Lex] Allow to consume tokens while preprocessingIlya Biryukov2019-05-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: By adding a hook to consume all tokens produced by the preprocessor. The intention of this change is to make it possible to consume the expanded tokens without re-runnig the preprocessor with minimal changes to the preprocessor and minimal performance penalty when preprocessing without recording the tokens. The added hook is very low-level and reconstructing the expanded token stream requires more work in the client code, the actual algorithm to collect the tokens using this hook can be found in the follow-up change. Reviewers: rsmith Reviewed By: rsmith Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59885 llvm-svn: 361007
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-161-0/+39
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* [Parser] Avoid correcting delayed typos in array subscript multiple times.Volodymyr Sapsai2019-05-011-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | We correct some typos in `ActOnArraySubscriptExpr` and `ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can end up correcting delayed typos in the same expressions again. In general it is OK but when `NumTypos` is incorrect, we can hit the assertion > Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219. Fix by replacing some subscript `ExprResult` with typo-corrected expressions instead of keeping the original expressions. Thus if original expressions contained `TypoExpr`, we'll use corrected expressions instead of trying to correct them again. rdar://problem/47403222 Reviewers: rsmith, erik.pilkington, majnemer Reviewed By: erik.pilkington Subscribers: jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D60848 llvm-svn: 359713
* [Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci2019-03-251-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeComplete] Propagate preferred type for function arguments in more casesIlya Biryukov2019-02-261-27/+11
| | | | | | | | | | | | | | | | | | | | | Summary: See the added test for some new cases. This change also removes special code completion calls inside the ParseExpressionList function now that we properly propagate expected type to the function responsible for parsing elements of the expression list (ParseAssignmentExpression). Reviewers: kadircet Reviewed By: kadircet Subscribers: xbolva00, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58541 llvm-svn: 354864
* [CodeComplete] Propagate preferred types through parser in more casesIlya Biryukov2019-01-311-17/+36
| | | | | | | | | | | | | | Preferred types are used by code completion for ranking. This commit considerably increases the number of points in code where those types are propagated. In order to avoid complicating signatures of Parser's methods, a preferred type is kept as a member variable in the parser and updated during parsing. Differential revision: https://reviews.llvm.org/D56723 llvm-svn: 352788
* 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
OpenPOWER on IntegriCloud