aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/SemaLambda.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-10-05Implement if consteval (P1938)Corentin Jabot1-1/+2
Modify the IfStmt node to suppoort constant evaluated expressions. Add a new ExpressionEvaluationContext::ImmediateFunctionContext to keep track of immediate function contexts. This proved easier/better/probably more efficient than walking the AST backward as it allows diagnosing nested if consteval statements.
2021-09-21[clang] don't mark as Elidable CXXConstruct expressions used in NRVOMatheus Izvekov1-2/+1
See PR51862. The consumers of the Elidable flag in CXXConstructExpr assume that an elidable construction just goes through a single copy/move construction, so that the source object is immediately passed as an argument and is the same type as the parameter itself. With the implementation of P2266 and after some adjustments to the implementation of P1825, we started (correctly, as per standard) allowing more cases where the copy initialization goes through user defined conversions. With this patch we stop using this flag in NRVO contexts, to preserve code that relies on that assumption. This causes no known functional changes, we just stop firing some asserts in a cople of included test cases. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D109800
2021-07-29[clang][patch][FPEnv] Make initialization of C++ globals strictfp awareMelanie Blower1-1/+4
@kpn pointed out that the global variable initialization functions didn't have the "strictfp" metadata set correctly, and @rjmccall said that there was buggy code in SetFPModel and StartFunction, this patch is to solve those problems. When Sema creates a FunctionDecl, it sets the FunctionDeclBits.UsesFPIntrin to "true" if the lexical FP settings (i.e. a combination of command line options and #pragma float_control settings) correspond to ConstrainedFP mode. That bit is used when CodeGen starts codegen for a llvm function, and it translates into the "strictfp" function attribute. See bugs.llvm.org/show_bug.cgi?id=44571 Reviewed By: Aaron Ballman Differential Revision: https://reviews.llvm.org/D102343
2021-06-09[clang] NFC: Rename rvalue to prvalueMatheus Izvekov1-1/+1
This renames the expression value categories from rvalue to prvalue, keeping nomenclature consistent with C++11 onwards. C++ has the most complicated taxonomy here, and every other language only uses a subset of it, so it's less confusing to use the C++ names consistently, and mentally remap to the C names when working on that context (prvalue -> rvalue, no xvalues, etc). Renames: * VK_RValue -> VK_PRValue * Expr::isRValue -> Expr::isPRValue * SK_QualificationConversionRValue -> SK_QualificationConversionPRValue * JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue" Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D103720
2021-05-27Reimplement __builtin_unique_stable_name-Erich Keane1-1/+5
The original version of this was reverted, and @rjmcall provided some advice to architect a new solution. This is that solution. This implements a builtin to provide a unique name that is stable across compilations of this TU for the purposes of implementing the library component of the unnamed kernel feature of SYCL. It does this by running the Itanium mangler with a few modifications. Because it is somewhat common to wrap non-kernel-related lambdas in macros that aren't present on the device (such as for logging), this uniquely generates an ID for all lambdas involved in the naming of a kernel. It uses the lambda-mangling number to do this, except replaces this with its own number (starting at 10000 for readabililty reasons) for lambdas used to name a kernel. Additionally, this implements itself as constexpr with a slight catch: if a name would be invalidated by the use of this lambda in a later kernel invocation, it is diagnosed as an error (see the Sema tests). Differential Revision: https://reviews.llvm.org/D103112
2021-02-05Recommit of a2fdf9d4d734732a6fa9288f1ffdf12bf8618123.Michael Liao1-4/+6
- The failures are all cc1-based tests due to the missing `-aux-triple` options, which is always prepared by the driver in CUDA/HIP compilation. - Add extra check on the missing aux-targetinfo to prevent crashing. [hip][cuda] Enable extended lambda support on Windows. - On Windows, extended lambda has extra issues due to the numbering schemes are different between the host compilation (Microsoft C++ ABI) and the device compilation (Itanium C++ ABI. Additional device side lambda number is required per lambda for the host compilation to correctly mangle the device-side lambda name. - A hybrid numbering context `MSHIPNumberingContext` is introduced to number a lambda for both host- and device-compilations. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D69322 This reverts commit 4874ff02417916cc9ff994b34abcb5e563056546.
2021-02-04Revert "[hip][cuda] Enable extended lambda support on Windows."Nico Weber1-6/+4
This reverts commit a2fdf9d4d734732a6fa9288f1ffdf12bf8618123. Slightly speculative, seeing several cuda tests fail on this Windows bot: http://45.33.8.238/win/32620/step_7.txt
2021-02-04[hip][cuda] Enable extended lambda support on Windows.Michael Liao1-4/+6
- On Windows, extended lambda has extra issues due to the numbering schemes are different between the host compilation (Microsoft C++ ABI) and the device compilation (Itanium C++ ABI. Additional device side lambda number is required per lambda for the host compilation to correctly mangle the device-side lambda name. - A hybrid numbering context `MSHIPNumberingContext` is introduced to number a lambda for both host- and device-compilations. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D69322
2021-01-27[clang][AST] Encapsulate DeclarationNameLoc, NFCIMikhail Maltsev1-9/+6
This change makes `DeclarationNameLoc` a proper class and refactors its users to use getter methods instead of accessing the members directly. The change also makes `DeclarationNameLoc` immutable (i.e., it cannot be modified once constructed). Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D94596
2021-01-04Revert "[NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped ↵Thorsten Schütt1-8/+8
enum (II)" This reverts commit efc82c4ad2bcb256a4f4c20238d08cd3afba4d2d.
2021-01-04[NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped enum (II)Thorsten Schütt1-8/+8
Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93765
2020-12-16[OpenMP] Add initial support for `omp [begin/end] assumes`Johannes Doerfert1-0/+4
The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-12-15Revert "[OpenMP] Add initial support for `omp [begin/end] assumes`"Johannes Doerfert1-4/+0
There is a build error with gcc-5 [0], investigating now. [0] https://reviews.llvm.org/D91980#2456526 This reverts commit a5a14cbe7f87e01882ecaa14df5d596cbf38823a.
2020-12-15[OpenMP] Add initial support for `omp [begin/end] assumes`Johannes Doerfert1-0/+4
The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-12-03P0857R0: Parse a requires-clause after an explicitRichard Smith1-2/+4
template-parameter-list in a lambda. This implements one of the missing parts of P0857R0. Mark it as not done on the cxx_status page given that it's still incomplete.
2020-11-16Convert ConstexprKind from Specifiers.h to a scoped enum; NFCThorsten1-5/+7
2020-11-05Implement Lambda Conversion Operators for All CCs for MSVC.Erich Keane1-3/+28
As described here: https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623 In order to allow Lambdas to be used with traditional Win32 APIs, they emit a conversion function for (what Raymond Chen claims is all) a number of the calling conventions. Through experimentation, we discovered that the list isn't quite 'all'. This patch implements this by taking the list of conversions that MSVC emits (across 'all' architectures, I don't see any CCs on ARM), then emits them if they are supported by the current target. However, we also add 3 other options (which may be duplicates): free-function, member-function, and operator() calling conventions. We do this because we have an extension where we generate both free and member for these cases so th at people specifying a calling convention on the lambda will have the expected behavior when specifying one of those two. MSVC doesn't seem to permit specifying calling-convention on lambdas, but we do, so we need to make sure those are emitted as well. We do this so that clang-only conventions are supported if the user specifies them. Differential Revision: https://reviews.llvm.org/D90634
2020-10-30PR47372: Fix Lambda invoker calling conventionsErich Keane1-15/+68
As mentioned in the defect, the lambda static invoker does not follow the calling convention of the lambda itself, which seems wrong. This patch ensures that the calling convention of operator() is passed onto the invoker and conversion-operator type. This is accomplished by extracting the calling-convention determination code out into a separate function in order to better reflect the 'thiscall' work, as well as somewhat better support the future implementation of https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623 For any target (basically just win32) that has a different free and static function calling convention, this generates BOTH alternatives. This required some work to get the Windows mangler to work correctly for this, as well as some tie-breaking for the unary operators. Differential Revision: https://reviews.llvm.org/D89559
2020-09-14[AST][FPEnv] Keep FP options in trailing storage of CastExprSerge Pavlov1-2/+3
This is recommit of 6c8041aa0f, reverted in de044f7562 because of some fails. Original commit message is below. This change allow a CastExpr to have optional FPOptionsOverride object, stored in trailing storage. Of all cast nodes only ImplicitCastExpr, CStyleCastExpr, CXXFunctionalCastExpr and CXXStaticCastExpr are allowed to have FPOptions. Differential Revision: https://reviews.llvm.org/D85960
2020-09-12Revert "[AST][FPEnv] Keep FP options in trailing storage of CastExpr"Serge Pavlov1-3/+2
This reverts commit 6c8041aa0ffed827636935e59c489b1e390c8542. It caused some fails on buildbots.
2020-09-12[AST][FPEnv] Keep FP options in trailing storage of CastExprSerge Pavlov1-2/+3
This change allow a CastExpr to have optional FPOptionsOverride object, stored in trailing storage. Of all cast nodes only ImplicitCastExpr, CStyleCastExpr, CXXFunctionalCastExpr and CXXStaticCastExpr are allowed to have FPOptions. Differential Revision: https://reviews.llvm.org/D85960
2020-07-29[clang][NFC] Pass the ASTContext to CXXRecordDecl::setCapturesBruno Ricci1-3/+4
In general Decl::getASTContext() is relatively expensive and here the changes are non-invasive. NFC.
2020-07-28PR46377: Fix dependence calculation for function types and typedefRichard Smith1-1/+2
types. We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate. We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type.
2020-07-08[CUDA][HIP] Let lambda be host device by defaultYaxun (Sam) Liu1-2/+4
This patch let lambda be host device by default and adds diagnostics for capturing host variable by reference in device lambda. Differential Revision: https://reviews.llvm.org/D78655
2020-06-05Set the captures on a CXXRecordDecl representing a lambda closure typeRichard Smith1-1/+2
before marking it complete. No functionality change intended. Previously committed as c13dd74e311d2ac70dd3ea663d800307d1aa5b6b.
2020-06-04Revert "Set the captures on a CXXRecordDecl representing a lambda closure type"Jonas Devlieghere1-2/+1
This reverts commit c13dd74e311d2ac70dd3ea663d800307d1aa5b6b.
2020-06-04Set the captures on a CXXRecordDecl representing a lambda closure typeRichard Smith1-1/+2
before marking it complete. No functionality change intended.
2020-04-22Rename warning identifiers from cxx2a to cxx20; NFC.Aaron Ballman1-1/+1
2020-04-21C++2a -> C++20 in some identifiers; NFC.Aaron Ballman1-3/+3
2020-03-13[Sema][SVE] Don't allow fields to have sizeless typeRichard Sandiford1-1/+2
The SVE ACLE doesn't allow fields to have sizeless type. At the moment clang accepts things like: struct s { __SVInt8_t x; } y; but trying to code-generate it leads to LLVM asserts like: llvm/include/llvm/Support/TypeSize.h:126: uint64_t llvm::TypeSize::getFixedSize() const: Assertion `!IsScalable && "Request for a fixed size on a scalable object"' failed. This patch adds an associated clang diagnostic. Differential Revision: https://reviews.llvm.org/D75737
2020-02-04[C++20] Add consteval-specific semantic for functionsTyker1-1/+3
Summary: Changes: - Calls to consteval function are now evaluated in constant context but IR is still generated for them. - Add diagnostic for taking address of a consteval function in non-constexpr context. - Add diagnostic for address of consteval function accessible at runtime. - Add tests Reviewers: rsmith, aaron.ballman Reviewed By: rsmith Subscribers: mgrang, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63960
2020-01-23[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-1/+2
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-2/+1
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-1/+2
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-2/+1
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-1/+2
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-09[Concepts] Function trailing requires clausesSaar Raz1-3/+5
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-12-09[c++20] Fix handling of unqualified lookups from a defaulted comparisonRichard Smith1-2/+2
function. We need to perform unqualified lookups from the context of a defaulted comparison, but not until we implicitly define the function, at which point we can't do those lookups any more. So perform the lookup from the end of the class containing the =default declaration and store the lookup results on the defaulted function until we synthesize the body.
2019-12-03[OpenCL] Use generic addr space for lambda call operatorAnastasia Stulova1-0/+4
Since lambdas are represented by callable objects, we add generic addr space for implicit object parameter in call operator. Any lambda variable declared in __constant addr space (which is not convertible to generic) fails to compile with a diagnostic. To support constant addr space we need to add a way to qualify the lambda call operators. Tags: #clang Differential Revision: https://reviews.llvm.org/D69938
2019-10-22Minor coding style fix. NFC.Michael Liao1-1/+2
llvm-svn: 375478
2019-10-19[hip][cuda] Fix the extended lambda name mangling issue.Michael Liao1-17/+56
Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
2019-10-10[sema] Revise `getCurrentMangleNumberContext` interface. NFC.Michael Liao1-17/+15
- Prefer returning mulitple values using a tuple instead of additional pointers/references. llvm-svn: 374274
2019-10-10Re-land [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner1-10/+2
This reverts r374268 (git commit c34385d07c7d59447bf836b740f032235391d121) I think I reverted this by mistake, so I'm relanding it. While my bisect found this revision, I think the crashes I'm seeing locally must be environmental. Maybe the version of clang I'm using miscompiles tot clang. llvm-svn: 374269
2019-10-10Revert [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner1-2/+10
This reverts r374200 (git commit fd18e94697c987d5f24e25aa4e27adaffff3cce4) Causes crashes just compiling `int main() {}` on my machine. llvm-svn: 374268
2019-10-09[mangle] Fix mangling where an extra mangle context is required.Michael Liao1-10/+2
Summary: - [Itanium C++ ABI][1], for certain contexts like default parameter and etc., mangling numbering will be local to the particular argument in which it appears. - However, for these cases, the mangle numbering context is allocated per expression evaluation stack entry. That causes, for example, two lambdas defined/used understand the same default parameter are numbered as the same value and, in turn, one of them is not generated at all. - In this patch, an extra mangle numbering context map is maintained in the AST context to map taht extra declaration context to its numbering context. So that, 2 different lambdas defined/used in the same default parameter are numbered differently. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: rsmith, eli.friedman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68715 llvm-svn: 374200
2019-09-05[c++20] Fix some ambiguities in our mangling of lambdas with explicitRichard Smith1-2/+6
template parameters. This finishes the implementation of the proposal described in https://github.com/itanium-cxx-abi/cxx-abi/issues/31. (We already implemented the <lambda-sig> extensions, but didn't take them into account when computing mangling numbers, and didn't deal properly with expanded parameter packs, and didn't disambiguate between different levels of template parameters in manglings.) llvm-svn: 371004
2019-08-29Fix variable ‘IsInitCapturePack’ set but not used warning. NFCI.Simon Pilgrim1-4/+1
llvm-svn: 370345
2019-08-26PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith1-5/+10
lambda from within the lambda-declarator. Instead of trying to reconstruct whether a parameter pack was declared inside a lambda (which we can't do correctly in general because we might not have attached parameters to their declaration contexts yet), track the set of parameter packs introduced in each live lambda scope, and require only those parameters to be immediately expanded when they appear inside that lambda. In passing, fix incorrect disambiguation of a lambda-expression starting with an init-capture pack in a braced-init-list. We previously incorrectly parsed that as a designated initializer. llvm-svn: 369985
2019-08-23Revert "PR42587: diagnose unexpanded uses of a pack parameter of a generic" ↵Richard Smith1-2/+2
due to buildbot breakage. This reverts commit r369722. llvm-svn: 369725
2019-08-23PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith1-2/+2
lambda from within the lambda-declarator. llvm-svn: 369722
generated by cgit v1.1 at 2025-10-12 11:32:14 +0000