[all-commits] [llvm/llvm-project] c26918: [lldb][TypeSystemClang] Initialize ClassTemplateSp...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c269182b13abddc459820e57a4d2065f364b23dc
      https://github.com/llvm/llvm-project/commit/c269182b13abddc459820e57a4d2065f364b23dc
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2025-02-07 (Fri, 07 Feb 2025)

  Changed paths:
    M clang/include/clang/AST/DeclTemplate.h
    M lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

  Log Message:
  -----------
  [lldb][TypeSystemClang] Initialize ClassTemplateSpecializationDecl's StrictPackMatch field (#126215)

This addresses the MSAN failure reported
in
https://github.com/llvm/llvm-project/pull/125791#issuecomment-2639183154:
```
==5633==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 in clang::ASTNodeImporter::CallOverloadedCreateFun<clang::ClassTemplateSpecializationDecl>::operator()
    #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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications