[pushed] c++: module std and exception_ptr

[pushed] c++: module std and exception_ptr

[Jason Merrill]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

exception_ptr.h contains

  namespace __exception_ptr
  {
    class exception_ptr;
  }
  using __exception_ptr::exception_ptr;

so when module std tries to 'export using std::exception_ptr', it names
another using-directive rather than the class directly, so __exception_ptr
is never explicitly opened in module purview.

gcc/cp/ChangeLog:

	* module.cc (depset::hash::add_binding_entity): Set
	DECL_MODULE_PURVIEW_P instead of asserting.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/using-20_a.C: New test.
---
 gcc/cp/module.cc                          |  7 +++++--
 gcc/testsuite/g++.dg/modules/using-20_a.C | 14 ++++++++++++++
 2 files changed, 19 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/using-20_a.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 21fc85150c9..72e876cec18 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13253,8 +13253,11 @@ depset::hash::add_binding_entity (tree decl, WMB_Flags flags, void *data_)
       data->met_namespace = true;
       if (data->hash->add_namespace_entities (decl, data->partitions))
 	{
-	  /* It contains an exported thing, so it is exported.  */
-	  gcc_checking_assert (DECL_MODULE_PURVIEW_P (decl));
+	  /* It contains an exported thing, so it is exported.
+	     We used to assert DECL_MODULE_PURVIEW_P, but that fails for a
+	     namespace like std::__exception_ptr which is never opened in
+	     module purview; the exporting using finds another using.  */
+	  DECL_MODULE_PURVIEW_P (decl) = true;
 	  DECL_MODULE_EXPORT_P (decl) = true;
 	}
 
diff --git a/gcc/testsuite/g++.dg/modules/using-20_a.C b/gcc/testsuite/g++.dg/modules/using-20_a.C
new file mode 100644
index 00000000000..bb3bb6160f8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-20_a.C
@@ -0,0 +1,14 @@
+// { dg-additional-options "-fmodules-ts -fdump-lang-module -Wno-global-module" }
+// { dg-final { scan-lang-dump {Writing definition '::foo::bar::baz'} module } }
+
+module;
+namespace foo {
+  namespace bar {
+    struct baz { };
+  }
+  using bar::baz;
+}
+export module foo;
+namespace foo {
+  export using foo::baz;
+}

base-commit: 7bf072e87a03c9eaff9b7a1ac182537b70f0ba8e
-- 
2.44.0

Re: [pushed] c++: module std and exception_ptr

[Patrick Palka]

On Wed, 12 Jun 2024, Jason Merrill wrote:

> Tested x86_64-pc-linux-gnu, applying to trunk.
> 
> -- 8< --
> 
> exception_ptr.h contains
> 
>   namespace __exception_ptr
>   {
>     class exception_ptr;
>   }
>   using __exception_ptr::exception_ptr;
> 
> so when module std tries to 'export using std::exception_ptr', it names
> another using-directive rather than the class directly, so __exception_ptr
> is never explicitly opened in module purview.

FWIW PR100134 ICEd in the same way, and r13-3236-g9736a42e1fb8df
narrowly fixed this by setting DECL_MODULE_PURVIEW_P on the enclosing
namespace around the time we set the flag on the namespace-scope entity in
question.  I wonder if it'd be preferable to do something similar here,
e.g. set DECL_MODULE_PURVIEW_P on the enclosing namespace in
do_nonmember_using_decl?

> 
> gcc/cp/ChangeLog:
> 
> 	* module.cc (depset::hash::add_binding_entity): Set
> 	DECL_MODULE_PURVIEW_P instead of asserting.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/modules/using-20_a.C: New test.
> ---
>  gcc/cp/module.cc                          |  7 +++++--
>  gcc/testsuite/g++.dg/modules/using-20_a.C | 14 ++++++++++++++
>  2 files changed, 19 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/modules/using-20_a.C
> 
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 21fc85150c9..72e876cec18 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -13253,8 +13253,11 @@ depset::hash::add_binding_entity (tree decl, WMB_Flags flags, void *data_)
>        data->met_namespace = true;
>        if (data->hash->add_namespace_entities (decl, data->partitions))
>  	{
> -	  /* It contains an exported thing, so it is exported.  */
> -	  gcc_checking_assert (DECL_MODULE_PURVIEW_P (decl));
> +	  /* It contains an exported thing, so it is exported.
> +	     We used to assert DECL_MODULE_PURVIEW_P, but that fails for a
> +	     namespace like std::__exception_ptr which is never opened in
> +	     module purview; the exporting using finds another using.  */
> +	  DECL_MODULE_PURVIEW_P (decl) = true;
>  	  DECL_MODULE_EXPORT_P (decl) = true;
>  	}
>  
> diff --git a/gcc/testsuite/g++.dg/modules/using-20_a.C b/gcc/testsuite/g++.dg/modules/using-20_a.C
> new file mode 100644
> index 00000000000..bb3bb6160f8
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/using-20_a.C
> @@ -0,0 +1,14 @@
> +// { dg-additional-options "-fmodules-ts -fdump-lang-module -Wno-global-module" }
> +// { dg-final { scan-lang-dump {Writing definition '::foo::bar::baz'} module } }
> +
> +module;
> +namespace foo {
> +  namespace bar {
> +    struct baz { };
> +  }
> +  using bar::baz;
> +}
> +export module foo;
> +namespace foo {
> +  export using foo::baz;
> +}
> 
> base-commit: 7bf072e87a03c9eaff9b7a1ac182537b70f0ba8e
> -- 
> 2.44.0
> 
> 

Re: [pushed] c++: module std and exception_ptr

[Jason Merrill]

On 6/13/24 11:16, Patrick Palka wrote:
> On Wed, 12 Jun 2024, Jason Merrill wrote:
> 
>> exception_ptr.h contains
>>
>>    namespace __exception_ptr
>>    {
>>      class exception_ptr;
>>    }
>>    using __exception_ptr::exception_ptr;
>>
>> so when module std tries to 'export using std::exception_ptr', it names
>> another using-directive rather than the class directly, so __exception_ptr
>> is never explicitly opened in module purview.
> 
> FWIW PR100134 ICEd in the same way, and r13-3236-g9736a42e1fb8df
> narrowly fixed this by setting DECL_MODULE_PURVIEW_P on the enclosing
> namespace around the time we set the flag on the namespace-scope entity in
> question.  I wonder if it'd be preferable to do something similar here,
> e.g. set DECL_MODULE_PURVIEW_P on the enclosing namespace in
> do_nonmember_using_decl?

Interesting thought, but I don't think so, as this is a workaround for 
the broader 114683 problem; we shouldn't actually be setting 
DECL_MODULE_PURVIEW_P on the class, either, only the using-declaration.
The problem is that we don't currently represent the using in a way that 
we can set flags on specifically.

Jason