c++/modules: complete_vars ICE with non-exported constexpr var

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

-- >8 --

Here during stream-in of the non-exported constexpr var 'a' we call
maybe_register_incomplete_var, which ends up taking the second branch
and pushing {a, NULL_TREE} onto incomplete_vars.  We later ICE from
complete_vars due to this NULL_TREE class context.

Judging by the two commits that introduced/modified this part of
maybe_register_incomplete_var, r196852 and r214333, ISTM this branch
is really only concerned with constexpr static data members (whose
initializer may contain a pointer-to-member for a currently open 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 currently open class.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/cexpr-4_a.C: New test.
	* g++.dg/modules/cexpr-4_b.C: New test.

gcc/cp/decl.cc

@@ -18477,6 +18477,8 @@ maybe_register_incomplete_var (tree var)
 	  vec_safe_push (incomplete_vars, iv);
 	}
       else if (!(DECL_LANG_SPECIFIC (var) && DECL_TEMPLATE_INFO (var))
+	       && DECL_CLASS_SCOPE_P (var)
+	       && currently_open_class (DECL_CONTEXT (var))
 	       && decl_constant_var_p (var)
 	       && (TYPE_PTRMEM_P (inner_type) || CLASS_TYPE_P (inner_type)))
 	{

gcc/testsuite/g++.dg/modules/cexpr-4_a.C

@@ -0,0 +1,12 @@
+// { dg-additional-options "-fmodules-ts" }
+export module Cexpr4;
+// { dg-module-cmi "Cexpr4" }
+
+struct A { int v = 42; };
+
+constexpr A a;
+
+export
+inline int f() {
+  return a.v;
+}

gcc/testsuite/g++.dg/modules/cexpr-4_b.C

@@ -0,0 +1,6 @@
+// { dg-additional-options "-fmodules-ts" }
+import Cexpr4;
+
+int w = f();
+
+struct A { };