Here after stream-in of the non-exported constexpr global 'A a' we call
maybe_register_incomplete_var, which we'd expect to be a no-op here but
it manages to take its second branch and pushes {a, NULL_TREE} onto
incomplete_vars. Later after defining B we ICE from complete_vars due
to this pushed NULL_TREE class context.
Judging by the two commits that introduced/modified this part of
maybe_register_incomplete_var, r196852 and r214333, it seems this second
branch is only concerned with constexpr static data members (whose
initializer may contain a pointer-to-member for a not-yet-complete class)
So this patch restricts this branch accordingly so it's not inadvertently
taken during stream-in.
gcc/cp/ChangeLog:
* decl.cc (maybe_register_incomplete_var): Restrict second
branch to static data members from a not-yet-complete class.
gcc/testsuite/ChangeLog:
* g++.dg/modules/cexpr-4_a.C: New test.
* g++.dg/modules/cexpr-4_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
vec_safe_push (incomplete_vars, iv);
}
else if (!(DECL_LANG_SPECIFIC (var) && DECL_TEMPLATE_INFO (var))
+ && DECL_CLASS_SCOPE_P (var)
+ && TYPE_BEING_DEFINED (DECL_CONTEXT (var))
&& decl_constant_var_p (var)
&& (TYPE_PTRMEM_P (inner_type) || CLASS_TYPE_P (inner_type)))
{
--- /dev/null
+// { dg-additional-options "-fmodules-ts" }
+export module Cexpr4;
+// { dg-module-cmi "Cexpr4" }
+
+struct A { int m = 42; };
+
+constexpr A a;
+
+export
+inline int f() { return a.m; }
--- /dev/null
+// { dg-additional-options "-fmodules-ts" }
+import Cexpr4;
+
+int v = f();
+
+struct B { };