aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Parse/ParseTentative.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-05-16[clang] Fix ternary operator in the second for loop statementDanila Kutenin1-1/+1
Fix ternary operator in for loop argument, it was by mistake not set as CanBeForRangeDecl and led to incorrect codegen. It fixes https://bugs.llvm.org/show_bug.cgi?id=50038. I don't have commit rights. Danila Kutenin. kutdanila@yandex.ru Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D102502
2020-12-07[clang] Add a new nullability annotation for swift async: _Nullable_resultErik Pilkington1-1/+3
_Nullable_result generally like _Nullable, except when being imported into a swift async method. rdar://70106409 Differential revision: https://reviews.llvm.org/D92495
2020-07-27Don't form a 'context-independent expr' reference to a member duringRichard Smith1-9/+0
name annotation. Instead, defer forming the member access expression or DeclRefExpr until we build the use of ClassifyName's result. Just build an UnresolvedLookupExpr to track the LookupResult until we're ready to consume it. This also reverts commit 2f7269b6773de2750f9cd1417ef5f21cd6cf7a91 (other than its testcase). That change was an attempted workaround for the same problem.
2020-07-13[clang] Include type specifiers in typo correction when checking ↵Haojian Wu1-2/+3
isCXXDeclarationSpecifiers. - add more tests (the test added in https://github.com/llvm/llvm-project/commit/2f448467e4254ddc3191136c968e6054bc009b88 is weak); - improve the `MyTemplate<type_typo, int>();` case, with this patch, typo correction suggests the type decl, and no regressions found. Differential Revision: https://reviews.llvm.org/D83025
2020-06-05[ARM] Add __bf16 as new Bfloat16 C TypeTies Stuij1-0/+2
Summary: This patch upstreams support for a new storage only bfloat16 C type. This type is used to implement primitive support for bfloat16 data, in line with the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile In detail this patch: - introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type. This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. The following people contributed to this patch: - Luke Cheeseman - Momchil Velikov - Alexandros Lamprineas - Luke Geeson - Simon Tatham - Ties Stuij Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli Reviewed By: SjoerdMeijer Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76077
2020-06-02Fix compiler crash when an expression parsed in the tentative parsing and ↵Alexey Bataev1-0/+9
must be claimed in the another evaluation context. Summary: Clang crashes when trying to finish function body. MaybeODRUseExprs is not empty because of const static data member parsed in outer evaluation context, upon call for isTypeIdInParens() function. It builds annot_primary_expr, later parsed in ParseConstantExpression() in inner constant expression evaluation context. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80925
2020-05-10Fix typo in enum-base disambiguation.Richard Smith1-1/+1
2020-05-10Properly implement 'enum class' parsing.Richard Smith1-2/+5
The 'class' or 'struct' keyword is only permitted as part of either an enum definition or a standalone opaque-enum-declaration, not as part of an elaborated type specifier. We previously failed to diagnose this, and generally didn't properly implement the restrictions on elaborated type specifiers for enumeration types. In passing, also fixed incorrect parsing for enum-bases, which we previously parsed as a type-name, but are actually a type-specifier-seq. This matters for cases like 'enum E : int *p;', which is valid as a Microsoft extension. Plus some minor parse diagnostic improvements. Bumped the recently-added ExtWarn for 'enum E : int x;' to be DefaultError; this is not an intentional extension, so producing an error by default seems appropriate, but the warning flag to disable it may still be useful for code written against old Clang. The same treatment is given here to the diagnostic for 'enum class E x;', which we similarly have incorrectly accepted for many years. These diagnostics continue to be suppressed under -fms-extensions and when compiling Objective-C code. We will need to decide separately whether Objective-C should follow the C++ rules or the (older) MSVC rules.
2020-05-08Fix parsing of enum-base to follow C++11 rules.Richard Smith1-126/+29
Previously we implemented non-standard disambiguation rules to distinguish an enum-base from a bit-field but otherwise treated a : after an elaborated-enum-specifier as introducing an enum-base. That misparses various examples (anywhere an elaborated-type-specifier can appear followed by a colon, such as within a ternary operator or _Generic). We now implement the C++11 rules, with the old cases accepted as extensions where that seemed reasonable. These amount to: * an enum-base must always be accompanied by an enum definition (except in a standalone declaration of the form 'enum E : T;') * in a member-declaration, 'enum E :' always introduces an enum-base, never a bit-field * in a type-specifier (or similar context), 'enum E :' is not permitted; the colon means whatever else it would mean in that context. Fixed underlying types for enums are also permitted in Objective-C and under MS extensions, plus as a language extension in all other modes. The behavior in ObjC and MS extensions modes is unchanged (but the bit-field disambiguation is a bit better); remaining language modes follow the C++11 rules. Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++ core issues 1514 and 1966.
2020-04-17Reland Implement _ExtInt as an extended int type specifier.Erich Keane1-0/+20
I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17Revert "Implement _ExtInt as an extended int type specifier."Sterling Augustine1-20/+0
This reverts commit 61ba1481e200b5b35baa81ffcff81acb678e8508. I'm reverting this because it breaks the lldb build with incomplete switch coverage warnings. I would fix it forward, but am not familiar enough with lldb to determine the correct fix. lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) {
2020-04-17Implement _ExtInt as an extended int type specifier.Erich Keane1-0/+20
Introduction/Motivation: LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax. Integers of non-power-of-two aren't particularly interesting or useful on most hardware, so much so that no language in Clang has been motivated to expose it before. However, in the case of FPGA hardware normal integer types where the full bitwidth isn't used, is extremely wasteful and has severe performance/space concerns. Because of this, Intel has introduced this functionality in the High Level Synthesis compiler[0] under the name "Arbitrary Precision Integer" (ap_int for short). This has been extremely useful and effective for our users, permitting them to optimize their storage and operation space on an architecture where both can be extremely expensive. We are proposing upstreaming a more palatable version of this to the community, in the form of this proposal and accompanying patch. We are proposing the syntax _ExtInt(N). We intend to propose this to the WG14 committee[1], and the underscore-capital seems like the active direction for a WG14 paper's acceptance. An alternative that Richard Smith suggested on the initial review was __int(N), however we believe that is much less acceptable by WG14. We considered _Int, however _Int is used as an identifier in libstdc++ and there is no good way to fall back to an identifier (since _Int(5) is indistinguishable from an unnamed initializer of a template type named _Int). [0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html) [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf Differential Revision: https://reviews.llvm.org/D73967
2020-03-27Form invalid template-id annotations when parsing a construct that isRichard Smith1-2/+9
required to be a template-id but names an undeclared identifier.
2020-03-27Improve recovery from invalid template-ids.Richard Smith1-8/+15
Instead of bailing out of parsing when we encounter an invalid template-name or template arguments in a template-id, produce an annotation token describing the invalid construct. This avoids duplicate errors and generally allows us to recover better. In principle we should be able to extend this to store some kinds of invalid template-id in the AST for tooling use, but that isn't handled as part of this change.
2020-03-25[SYCL] Implement __builtin_unique_stable_name.Erich Keane1-0/+1
In order to support non-user-named kernels, SYCL needs some way in the integration headers to name the kernel object themselves. Initially, the design considered just RTTI naming of the lambdas, this results in a quite unstable situation in light of some device/host macros. Additionally, this ends up needing to use RTTI, which is a burden on the implementation and typically unsupported. Instead, we've introduced a builtin, __builtin_unique_stable_name, which takes a type or expression, and results in a constexpr constant character array that uniquely represents the type (or type of the expression) being passed to it. The implementation accomplishes that simply by using a slightly modified version of the Itanium Mangling. The one exception is when mangling lambdas, instead of appending the index of the lambda in the function, it appends the macro-expansion back-trace of the lambda itself in the form LINE->COL[~LINE->COL...]. Differential Revision: https://reviews.llvm.org/D76620
2020-02-24Fix TryParsePtrOperatorSeq.Michele Scandale1-16/+34
The syntax rules for ptr-operator allow attributes after *, &, &&, therefore we should be able to parse the following: void fn() { void (*[[attr]] x)() = &fn; void (&[[attr]] y)() = fn; void (&&[[attr]] z)() = fn; } However the current logic in TryParsePtrOperatorSeq does not consider the presence of attributes leading to unexpected parsing errors. Moreover we should also consider _Atomic a possible qualifier that can appear after the sequence of attribute specifiers.
2020-01-23[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-0/+21
This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042
2020-01-23Revert "[Concepts] Placeholder constraints and abbreviated templates"Sam McCall1-21/+0
This reverts commit e57a9abc4b01fa69fe81ace8df70517983b6cbac. Parser/cxx2a-placeholder-type-constraint.cpp has MSan failures. Present at 7b81c3f8793d30a4285095a9b67dcfca2117916c: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17133/steps/check-clang%20msan/logs/stdio not present at eaa594f4ec54eba52b03fd9f1c789b214c66a753: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17132/steps/check-clang%20msan/logs/stdio Stack trace: ``` ==57032==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xccfe016 in clang::AutoTypeLoc::getLocalSourceRange() const /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/AST/TypeLoc.h:2036:19 #1 0xcc56758 in CheckDeducedPlaceholderConstraints(clang::Sema&, clang::AutoType const&, clang::AutoTypeLoc, clang::QualType) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4505:56 #2 0xcc550ce in clang::Sema::DeduceAutoType(clang::TypeLoc, clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4707:11 #3 0xcc52407 in clang::Sema::DeduceAutoType(clang::TypeSourceInfo*, clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4457:10 #4 0xba38332 in clang::Sema::deduceVarTypeFromInitializer(clang::VarDecl*, clang::DeclarationName, clang::QualType, clang::TypeSourceInfo*, clang::SourceRange, bool, clang::Expr*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11351:7 #5 0xba3a8a9 in clang::Sema::DeduceVariableDeclarationType(clang::VarDecl*, bool, clang::Expr*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11385:26 #6 0xba3c520 in clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11725:9 #7 0xb39c498 in clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2399:17 #8 0xb394d80 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2128:21 #9 0xb383bbf in clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1848:10 #10 0xb383129 in clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/ADT/PointerUnion.h #11 0xb53a388 in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:221:13 #12 0xb539309 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20 #13 0xb55610e in clang::Parser::ParseCompoundStatementBody(bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1079:11 #14 0xb559529 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2204:21 #15 0xb33c13e in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1339:10 #16 0xb394703 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2068:11 #17 0xb338e52 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1099:10 #18 0xb337674 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1115:12 #19 0xb334a96 in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:935:12 #20 0xb32f12a in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:686:12 #21 0xb31e193 in clang::ParseAST(clang::Sema&, bool, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20 #22 0x80263f0 in clang::FrontendAction::Execute() /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:936:8 #23 0x7f2a257 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:965:33 #24 0x8288bef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:290:25 #25 0xad44c2 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/cc1_main.cpp:239:15 #26 0xacd76a in ExecuteCC1Tool(llvm::ArrayRef<char const*>) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:325:12 #27 0xacc9fd in main /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:398:12 #28 0x7f7d82cdb2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #29 0xa4dde9 in _start (/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang-11+0xa4dde9) ```
2020-01-22[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-0/+21
This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after incorrect check in NonTypeTemplateParmDecl broke lldb. Differential Revision: https://reviews.llvm.org/D65042
2020-01-21Revert "[Concepts] Placeholder constraints and abbreviated templates"Jonas Devlieghere1-21/+0
This temporarily reverts commit e03ead6771fc97b11cb0c94b7f023142184ad25f because it breaks LLDB. http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/3356 http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12872 http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/6407/
2020-01-22[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-0/+21
This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Differential Revision: https://reviews.llvm.org/D65042
2020-01-17Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith1-1/+1
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.
2020-01-15PR42694 Support explicit(bool) in older language modes as an extension.Richard Smith1-6/+58
This needs somewhat careful disambiguation, as C++2a explicit(bool) is a breaking change. We only enable it in cases where the source construct could not possibly be anything else.
2020-01-09[Concepts] Function trailing requires clausesSaar Raz1-1/+4
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
2019-11-27Properly disambiguate between array declarators and array subscript expressions.Richard Smith1-1/+13
2019-10-14PR43080: Do not build context-sensitive expressions during name classification.Richard Smith1-2/+2
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
2019-09-04[c++20] P1143R2: Add support for the C++20 'constinit' keyword.Richard Smith1-0/+1
This is mostly the same as the [[clang::require_constant_initialization]] attribute, but has a couple of additional syntactic and semantic restrictions. In passing, I added a warning for the attribute form being added after we have already seen the initialization of the variable (but before we see the definition); that case previously slipped between the cracks and the attribute was silently ignored. llvm-svn: 370972
2019-08-14[Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-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
2019-06-14[C++20] add Basic consteval specifierGauthier Harnisch1-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
2019-05-22[OpenCL] Support pipe keyword in C++ modeSven van Haastregt1-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
2019-05-20Rearrange and clean up how we disambiguate lambda-introducers from ObjCRichard Smith1-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
2019-05-15Make tentative parsing to detect template-argument-lists less aggressiveRichard Smith1-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
2019-05-09[c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith1-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
2019-05-08[hip] Fix ambiguity from `>>>` of CUDA.Michael Liao1-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
2019-05-07Improve function / variable disambiguation.Richard Smith1-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
2019-03-28[PR41247] Fixed parsing of private keyword in C++.Anastasia Stulova1-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
2019-03-25[Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci1-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
2019-03-25[OpenCL] Allow addr space spelling without __ prefix in C++.Anastasia Stulova1-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
2019-02-26[MS] Fix for Bug 8446, template instantiation without a 'typename' keywordReid Kleckner1-0/+11
Patch by Zahira Ammarguellat! Differential Revision: https://reviews.llvm.org/D41950 llvm-svn: 354838
2019-02-15[OpenCL][PR40707] Allow OpenCL C types in C++ mode.Anastasia Stulova1-0/+9
Allow all OpenCL types to be parsed in C++ mode. llvm-svn: 354121
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-11-01Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner1-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
2018-10-30NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington1-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
2018-10-20Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFCFangrui Song1-2/+2
llvm-svn: 344859
2018-09-28[cxx2a] P0614R1: Support init-statements in range-based for loops.Richard Smith1-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
2018-07-30Remove trailing spaceFangrui Song1-19/+19
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-26[MS] Add L__FUNCSIG__ for compatibilityReid Kleckner1-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
2018-06-22[OpenCL] Fixed parsing of address spaces for C++.Anastasia Stulova1-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
2018-05-09Remove \brief commands from doxygen comments.Adrian Prantl1-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
2018-05-01Implement P0482R2, support for char8_t type.Richard Smith1-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
generated by cgit v1.1 at 2025-10-13 09:03:31 +0000