[lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field#126215
Conversation
…StrictPackMatch field This addresses the MSAN failure reported in llvm#125791 (comment): ``` ==5633==WARNING: MemorySanitizer: use-of-uninitialized-value #0 in clang::ASTNodeImporter::CallOverloadedCreateFun<clang::ClassTemplateSpecializationDecl>::operator() llvm#1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...> ... ``` The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is a decl that LLDB created from debug-info, it would've been created using `ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize the `StrictPackMatch` field. This patch just initializes the field to a fixed value of `false`, to preserve previous behaviour and avoid the use-of-uninitialized-value. An alternative would be to always initialize it in the `ClassTemplateSpecializationDecl` constructor, but there were reservations about providing a default value for it because it might lead to hard-to-diagnose problems down the line.
|
@llvm/pr-subscribers-lldb @llvm/pr-subscribers-clang Author: Michael Buch (Michael137) ChangesThis addresses the MSAN failure reported The ASTImporter reads This patch just initializes the field to a fixed value of An alternative would be to always initialize it in the Full diff: https://github.com/llvm/llvm-project/pull/126215.diff 2 Files Affected:
diff --git a/clang/include/clang/AST/DeclTemplate.h b/clang/include/clang/AST/DeclTemplate.h
index a30ae798a99bc69..b82f75dd63fa508 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -1960,6 +1960,8 @@ class ClassTemplateSpecializationDecl : public CXXRecordDecl,
bool hasStrictPackMatch() const { return StrictPackMatch; }
+ void setStrictPackMatch(bool Val) { StrictPackMatch = Val; }
+
/// Get the point of instantiation (if any), or null if none.
SourceLocation getPointOfInstantiation() const {
return PointOfInstantiation;
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 1da8fbe0bcd6dda..ecb571b1161bbc6 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -1666,6 +1666,12 @@ TypeSystemClang::CreateClassTemplateSpecializationDecl(
ast.getTypeDeclType(class_template_specialization_decl, nullptr);
class_template_specialization_decl->setDeclName(
class_template_decl->getDeclName());
+
+ // FIXME: set to fixed value for now so it's not uninitialized.
+ // One way to determine StrictPackMatch would be
+ // Sema::CheckTemplateTemplateArgument.
+ class_template_specialization_decl->setStrictPackMatch(false);
+
SetOwningModule(class_template_specialization_decl, owning_module);
decl_ctx->addDecl(class_template_specialization_decl);
|
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/190/builds/14274 Here is the relevant piece of the build log for the reference |
|
@mizvekov Do you want this backported to the release branch? |
Yes, there might be other patches missing though. I am in the c++ committee meeting, so hadn't the time to sort it out yet. |
…StrictPackMatch field (llvm#126215) This addresses the MSAN failure reported in llvm#125791 (comment): ``` ==5633==WARNING: MemorySanitizer: use-of-uninitialized-value #0 in clang::ASTNodeImporter::CallOverloadedCreateFun<clang::ClassTemplateSpecializationDecl>::operator() llvm#1 in bool clang::ASTNodeImporter::GetImportedOrCreateSpecialDecl<...> ... ``` The ASTImporter reads `D->hasStrictPackMatch()` and forwards it to the constructor of the destination `ClassTemplateSpecializationDecl`. But if `D` is a decl that LLDB created from debug-info, it would've been created using `ClassTemplateSpecializationDecl::CreateDeserialized`, which doesn't initialize the `StrictPackMatch` field. This patch just initializes the field to a fixed value of `false`, to preserve previous behaviour and avoid the use-of-uninitialized-value. An alternative would be to always initialize it in the `ClassTemplateSpecializationDecl` constructor, but there were reservations about providing a default value for it because it might lead to hard-to-diagnose problems down the line.
|
Cherry picking this onto the 20.x release branch requires #125791 to be cherry-picked first. |
But this is just a bugfix for that PR, right? (IOW, if there's no reason to cherry-pick that PR, then there's also no reason cherry-pick this fix) |
|
But there is reason to cherry-pick #125791, as it fixes a regression which would otherwise be introduced in 20.x. |
|
Okay, nevermind me then. :) Thanks for the explanation. |
This addresses the MSAN failure reported
in #125791 (comment):
The ASTImporter reads
D->hasStrictPackMatch()and forwards it to the constructor of the destinationClassTemplateSpecializationDecl. But ifDis a decl that LLDB created from debug-info, it would've been created usingClassTemplateSpecializationDecl::CreateDeserialized, which doesn't initialize theStrictPackMatchfield.This patch just initializes the field to a fixed value of
false, to preserve previous behaviour and avoid the use-of-uninitialized-value.An alternative would be to always initialize it in the
ClassTemplateSpecializationDeclconstructor, but there were reservations about providing a default value for it because it might lead to hard-to-diagnose problems down the line.