distinct lambdas incorrectly merged across modules

[zygoloid]

If a lambda appears within a variable template, then instantiations of that lambda have the lexical context of the variable as their lexical context. This causes Clang's serialization layer to be unable to distinguish them across modules, because its approach is to number unnamed declarations within their lexical context, and two distinct lambdas from different instantiations of the variable template can end up with the same number.

Example, ready to be dropped into test/Modules/:

// RUN: rm -rf %t
// RUN: mkdir -p %t
// RUN: split-file %s %t
//
// RUN: %clang_cc1 -std=c++20 -fmodules -fmodules-cache-path=%t -fmodule-map-file=%t/module.modulemap %t/use.cpp -emit-llvm -o - -triple x86_64-linux-gnu | FileCheck %s

//--- module.modulemap
module a { header "a.h" export * }
module b { header "b.h" export * }
module c { header "c.h" export * }


//--- a.h

void not_constant();
template<typename T> struct A {
  template<T M> static inline T N = [] { not_constant(); return M; } ();
};

//--- b.h
#include "a.h"

int b() { return A<int>::N<1>; }

//--- c.h
#include "a.h"

int c() { return A<int>::N<2>; }

//--- use.cpp
#include "b.h"
#include "c.h"

int bv = b();
int cv = c();

// We should not merge the two lambdas together, even though they will both
// have anonymous declaration number #1 within A<int>.

// CHECK: define {{.*}}global_var_init{{.*}} comdat($_ZN1AIiE1NILi1EEE) {
// CHECK: load i8, ptr @_ZGVN1AIiE1NILi1EEE, align 8
// CHECK: call {{.*} i32 @_ZNK1AIiE1NILi1EEMUlvE_clEv(
// CHECK: store i32 %call, ptr @_ZN1AIiE1NILi1EEE

// CHECK: define {{.*}}global_var_init{{.*}} comdat($_ZN1AIiE1NILi2EEE) {
// CHECK: load i8, ptr @_ZGVN1AIiE1NILi2EEE, align 8
// CHECK: call {{.*} i32 @_ZNK1AIiE1NILi2EEMUlvE_clEv(
// CHECK: store i32 %call, ptr @_ZN1AIiE1NILi2EEE

This test currently fails, because we generate calls to the A<int>::N<1> lambda to initialize both A<int>::N<1> and A<int>::N<2>. That happens because those two different lambdas get merged, because they're both numbered #1 within A<int> in the b and c module respectively.

We could perhaps fix the immediate issue by taking the context decl and mangling number into account when computing whether two lambdas should be merged, instead of numbering them inside their lexical context, at least when the context decl is a variable template specialization.

The same thing presumably happens when the variable template is at global scope instead of in a class template. That case seems especially hard to deal with, as there might be a local definition of the variable template in addition to ones from modules, and we don't have a good way to even find the lambdas that might have been instantiated locally. And the same thing presumably also happens for inline variables:

// header module 1
inline auto a = [] { return 1; };

// header module 2
inline auto b = [] { return 2; }
inline auto a = [] { return 1; }

... probably doesn't merge together the two a lambdas currently, and might merge the a from module 1 with the b from module 2 if we end up using lexical numbering here.

Perhaps we should address this by creating a lexical DeclContext corresponding to a variable, at least if we find that it's the context of a lambda. We would need this for instantiated variable template specializations and for inline variables, but having it in general seems useful.

[llvmbot]

@llvm/issue-subscribers-c-20

[llvmbot]

@llvm/issue-subscribers-c-1

[llvmbot]

@llvm/issue-subscribers-bug

[llvmbot]

@llvm/issue-subscribers-clang-modules

[llvmbot]

@llvm/issue-subscribers-c-11

[llvmbot]

@llvm/issue-subscribers-c-20

[zygoloid]

https://reviews.llvm.org/D145737