[clang] [clang][AST] Value-initialize deserialized concept specialization args (PR #222148)

[Ian Petersen via cfe-commits]

================
@@ -1130,7 +1132,19 @@ ImplicitConceptSpecializationDecl::ImplicitConceptSpecializationDecl(
 ImplicitConceptSpecializationDecl::ImplicitConceptSpecializationDecl(
     EmptyShell Empty, unsigned NumTemplateArgs)
     : Decl(ImplicitConceptSpecialization, Empty),
-      NumTemplateArgs(NumTemplateArgs) {}
+      NumTemplateArgs(NumTemplateArgs) {
+  // ASTReader registers a decl before ASTDeclReader visits it, so re-entrant
+  // deserialization can reach this one through a ConceptSpecializationExpr and
+  // call getTemplateArguments() before setTemplateArguments() has run. Give
+  // that read a well-defined result rather than raw allocator memory.
+  //
+  // FIXME: well-defined is not the same as correct. Profiling the decl in this
+  // window hashes these value-initialized arguments rather than the real ones,
+  // so a FunctionProtoType uniqued from that profile is filed under a hash it
+  // will never profile to again. A later lookup cannot find that type, and the
+  // next derivation of the same type creates a duplicate. See #191361.
+  std::uninitialized_value_construct_n(getTrailingObjects(), NumTemplateArgs);
----------------
ispeters wrote:

It's difficult for me to say, but I'd be willing to do some legwork to find out.

For what it's worth, this particular pattern is the only one that causes ICEs (even non-deterministically) when compiling stdexec's modular build. The first thought I have for how to find other problems is to audit the AST deserialization code for objects that have trailing arrays like this, and find a way to assert on reads of uninitialized values; if there are any hits, then the current absence of ICEs would be explained by allocation luck.

If there's a place that comes to mind that would be the first place you'd look, I'm all ears; otherwise, I'll just try a broad sample.

https://github.com/llvm/llvm-project/pull/222148