Re: Ping: [PATCH] testsuite/C++: suppress filename canonicalization in module tests

[Jan Beulich via Gcc-patches]

On 28.04.2023 00:24, Nathan Sidwell wrote:
> On 4/25/23 11:04, Jan Beulich wrote:
>> On 28.06.2022 16:06, Jan Beulich wrote:
>>> The pathname underneath gcm.cache/ is determined from the effective name
>>> used for the main input file of a particular module. When modules are
>>> built, no canonicalization occurs for the main input file. Hence the
>>> module file wouldn't be found if a different (the canonicalized) file
>>> name was used when importing that same module. (This is an effect of
>>> importing happening in the preprocessor, just like #include handling.)
>>>
>>> Since it doesn't look easy to make module generation use libcpp's
>>> maybe_shorter_path() (in fact I'd consider this a layering violation,
>>> while cloning the logic would - at least in principle - be prone to both
>>> going out of sync), simply suppress system header path canonicalization
>>> for the respective tests.
>>
>> Ping: This still looks to apply as is.
> 
> ok -- I was unaware of this.  might be sensible to file a defect about this?

Sure: 109660.

Jan

Re: Ping: [PATCH] testsuite/C++: suppress filename canonicalization in module tests

[Nathan Sidwell via Gcc-patches]

On 4/25/23 11:04, Jan Beulich wrote:

On 28.06.2022 16:06, Jan Beulich wrote:

The pathname underneath gcm.cache/ is determined from the effective name
used for the main input file of a particular module. When modules are
built, no canonicalization occurs for the main input file. Hence the
module file wouldn't be found if a different (the canonicalized) file
name was used when importing that same module. (This is an effect of
importing happening in the preprocessor, just like #include handling.)

Since it doesn't look easy to make module generation use libcpp's
maybe_shorter_path() (in fact I'd consider this a layering violation,
while cloning the logic would - at least in principle - be prone to both
going out of sync), simply suppress system header path canonicalization
for the respective tests.


Ping: This still looks to apply as is.


ok -- I was unaware of this.  might be sensible to file a defect about this?



Thanks, Jan


---
Strictly speaking it could be necessary to also suppress
canonicalization when generating the modules, but for now they're self-
contained, i.e. don't include any "real" system headers. IOW at the
moment the tests aren't susceptible to the issue at generation time.

--- a/gcc/testsuite/g++.dg/modules/alias-1_b.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_b.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir]" 
}
+// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir] 
-fno-canonical-system-headers" }
  
  // Alias at the header file.  We have one CMI file

  import "alias-1_a.H";
--- a/gcc/testsuite/g++.dg/modules/alias-1_d.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_d.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
-fno-canonical-system-headers" }
  // { dg-module-cmi kevin }
  
  export module kevin;

--- a/gcc/testsuite/g++.dg/modules/alias-1_e.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_e.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
-fno-canonical-system-headers" }
  
  import bob;

  import kevin;
--- a/gcc/testsuite/g++.dg/modules/alias-1_f.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_f.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir]" 
}
+// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir] 
-fno-canonical-system-headers" }
  
  import kevin;

  import bob;
--- a/gcc/testsuite/g++.dg/modules/cpp-6_c.C
+++ b/gcc/testsuite/g++.dg/modules/cpp-6_c.C
@@ -1,5 +1,5 @@
  // { dg-do preprocess }
-// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
-fno-canonical-system-headers" }
  
  #define empty

  #define nop(X) X
--- a/gcc/testsuite/g++.dg/modules/dir-only-2_b.C
+++ b/gcc/testsuite/g++.dg/modules/dir-only-2_b.C
@@ -1,5 +1,5 @@
  // { dg-do preprocess }
-// { dg-additional-options "-fmodules-ts -fdirectives-only -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -fdirectives-only -isystem [srcdir] 
-fno-canonical-system-headers" }
  // a comment
  module; // line
  frob




--
Nathan Sidwell

Ping: [PATCH] testsuite/C++: suppress filename canonicalization in module tests

[Jan Beulich via Gcc-patches]

On 28.06.2022 16:06, Jan Beulich wrote:
> The pathname underneath gcm.cache/ is determined from the effective name
> used for the main input file of a particular module. When modules are
> built, no canonicalization occurs for the main input file. Hence the
> module file wouldn't be found if a different (the canonicalized) file
> name was used when importing that same module. (This is an effect of
> importing happening in the preprocessor, just like #include handling.)
> 
> Since it doesn't look easy to make module generation use libcpp's
> maybe_shorter_path() (in fact I'd consider this a layering violation,
> while cloning the logic would - at least in principle - be prone to both
> going out of sync), simply suppress system header path canonicalization
> for the respective tests.

Ping: This still looks to apply as is.

Thanks, Jan

> ---
> Strictly speaking it could be necessary to also suppress
> canonicalization when generating the modules, but for now they're self-
> contained, i.e. don't include any "real" system headers. IOW at the
> moment the tests aren't susceptible to the issue at generation time.
> 
> --- a/gcc/testsuite/g++.dg/modules/alias-1_b.C
> +++ b/gcc/testsuite/g++.dg/modules/alias-1_b.C
> @@ -1,4 +1,4 @@
> -// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem 
> [srcdir]" }
> +// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem 
> [srcdir] -fno-canonical-system-headers" }
>  
>  // Alias at the header file.  We have one CMI file
>  import "alias-1_a.H";
> --- a/gcc/testsuite/g++.dg/modules/alias-1_d.C
> +++ b/gcc/testsuite/g++.dg/modules/alias-1_d.C
> @@ -1,4 +1,4 @@
> -// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
> +// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
> -fno-canonical-system-headers" }
>  // { dg-module-cmi kevin }
>  
>  export module kevin;
> --- a/gcc/testsuite/g++.dg/modules/alias-1_e.C
> +++ b/gcc/testsuite/g++.dg/modules/alias-1_e.C
> @@ -1,4 +1,4 @@
> -// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
> +// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
> -fno-canonical-system-headers" }
>  
>  import bob;
>  import kevin;
> --- a/gcc/testsuite/g++.dg/modules/alias-1_f.C
> +++ b/gcc/testsuite/g++.dg/modules/alias-1_f.C
> @@ -1,4 +1,4 @@
> -// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem 
> [srcdir]" }
> +// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem 
> [srcdir] -fno-canonical-system-headers" }
>  
>  import kevin;
>  import bob;
> --- a/gcc/testsuite/g++.dg/modules/cpp-6_c.C
> +++ b/gcc/testsuite/g++.dg/modules/cpp-6_c.C
> @@ -1,5 +1,5 @@
>  // { dg-do preprocess }
> -// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
> +// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
> -fno-canonical-system-headers" }
>  
>  #define empty
>  #define nop(X) X
> --- a/gcc/testsuite/g++.dg/modules/dir-only-2_b.C
> +++ b/gcc/testsuite/g++.dg/modules/dir-only-2_b.C
> @@ -1,5 +1,5 @@
>  // { dg-do preprocess }
> -// { dg-additional-options "-fmodules-ts -fdirectives-only -isystem 
> [srcdir]" }
> +// { dg-additional-options "-fmodules-ts -fdirectives-only -isystem [srcdir] 
> -fno-canonical-system-headers" }
>  // a comment
>  module; // line
>  frob