Skip to content

[flang][NFC] Document an intentional violation of the standard #99073

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 18, 2024

Conversation

klausler
Copy link
Contributor

@klausler klausler commented Jul 16, 2024

The Fortran standard committees passed an "interp" request at their June 2024 meetings that is distinct from nearly every other Fortran compiler that I tried (6) in an an ambiguous case (parent component naming when the base type has been renamed via USE association). Document this case in flang/docs/Extensions.md as an intentional instance of non-conformance chosen for portability and better usability.

@llvmbot llvmbot added the flang Flang issues not falling into any other category label Jul 16, 2024
@llvmbot
Copy link
Member

llvmbot commented Jul 16, 2024

@llvm/pr-subscribers-flang-semantics

Author: Peter Klausler (klausler)

Changes

The Fortran standard committees passed an "interp" request at their June 2024 meetings that is contrary to what every other Fortran compiler that I tried (6) does with an ambiguous case (parent component naming when the base type has been renamed via USE association). Document this case in flang/docs/Extensions.md as an intentional instance of non-conformance chosen for portability and better usability.


Full diff: https://github.com/llvm/llvm-project/pull/99073.diff

2 Files Affected:

  • (modified) flang/docs/Extensions.md (+7)
  • (added) flang/test/Semantics/parent-comp-name.f90 (+70)
diff --git a/flang/docs/Extensions.md b/flang/docs/Extensions.md
index 82f9a021c14ee..093596c9dc8eb 100644
--- a/flang/docs/Extensions.md
+++ b/flang/docs/Extensions.md
@@ -134,6 +134,13 @@ end
   implicitly simply appearing in an asynchronous data transfer statement,
   without the attribute being visible in the procedure's explicit
   interface.
+* When the name of an extended derived type's base type is the
+  result of `USE` association with renaming, the name of the extended
+  derived type's parent component is the new name by which the base
+  is known in the scope of the extended derived type, not the original.
+  This interpretation has usability advantages and is what six other
+  Fortran compilers do, but is not conforming now that J3 approved an
+  "interp" in June 2024 to the contrary.
 
 ## Extensions, deletions, and legacy features supported by default
 
diff --git a/flang/test/Semantics/parent-comp-name.f90 b/flang/test/Semantics/parent-comp-name.f90
new file mode 100644
index 0000000000000..d7878430a5849
--- /dev/null
+++ b/flang/test/Semantics/parent-comp-name.f90
@@ -0,0 +1,70 @@
+! RUN: %python %S/test_errors.py %s %flang_fc1
+! Every other Fortran compiler (but one) interprets the names of parent
+! components like this when the names of their types are the product of
+! USE association with renaming.
+
+module m1
+  type originalName
+    integer m
+  end type
+end
+
+module m2
+  use m1, newName => originalName
+  type, extends(newName) :: extended
+    integer n
+  end type
+  type, extends(newName) :: extended2
+    integer originalName ! ok
+  end type
+ contains
+  subroutine s1
+    type(extended) x
+    type(extended2) x2
+    print *, x%newName%m ! ok
+    !ERROR: Component 'originalname' not found in derived type 'extended'
+    print *, x%originalName
+    print *, extended(newName=newName(m=1),n=2) ! ok
+    !ERROR: Structure constructor lacks a value for component 'm'
+    !ERROR: Keyword 'originalname=' does not name a component of derived type 'extended'
+    !ERROR: Keyword 'm=' may not appear in a reference to a procedure with an implicit interface
+    print *, extended(originalName=originalName(m=1),n=2)
+    !ERROR: Value in structure constructor of type 'REAL(4)' is incompatible with component 'newname' of type 'newname'
+    !ERROR: Keyword 'm=' may not appear in a reference to a procedure with an implicit interface
+    print *, extended(newName=originalName(m=1),n=2)
+    !ERROR: Structure constructor lacks a value for component 'm'
+    !ERROR: Keyword 'originalname=' does not name a component of derived type 'extended'
+    print *, extended(originalName=newName(m=1),n=2)
+    print *, x2%newName%m ! ok
+    print *, x2%originalName ! ok
+    print *, extended2(newName=newName(m=1),originalName=2) ! ok
+  end
+end
+
+module m3
+  use m2
+ contains
+  ! Same as above, but not in the same module as the derived
+  ! types' definitions.
+  subroutine s2
+    type(extended) x
+    type(extended2) x2
+    print *, x%newName%m ! ok
+    !ERROR: Component 'originalname' not found in derived type 'extended'
+    print *, x%originalName
+    print *, extended(newName=newName(m=1),n=2) ! ok
+    !ERROR: Structure constructor lacks a value for component 'm'
+    !ERROR: Keyword 'originalname=' does not name a component of derived type 'extended'
+    !ERROR: Keyword 'm=' may not appear in a reference to a procedure with an implicit interface
+    print *, extended(originalName=originalName(m=1),n=2)
+    !ERROR: Value in structure constructor of type 'REAL(4)' is incompatible with component 'newname' of type 'newname'
+    !ERROR: Keyword 'm=' may not appear in a reference to a procedure with an implicit interface
+    print *, extended(newName=originalName(m=1),n=2)
+    !ERROR: Structure constructor lacks a value for component 'm'
+    !ERROR: Keyword 'originalname=' does not name a component of derived type 'extended'
+    print *, extended(originalName=newName(m=1),n=2)
+    print *, x2%newName%m ! ok
+    print *, x2%originalName ! ok
+    print *, extended2(newName=newName(m=1),originalName=2) ! ok
+  end
+end

The Fortran standard committees passed an "interp" request at their
June 2024 meetings that is distinct from nearly every other Fortran
compiler that I tried (6) in an ambiguous case (parent component
naming when the base type has been renamed via USE association).
Document this case in flang/docs/Extensions.md as an intentional
instance of non-conformance chosen for portability and better
usability.
@klausler klausler merged commit 40ed6ba into llvm:main Jul 18, 2024
8 checks passed
@klausler klausler deleted the bad-interp branch July 18, 2024 22:59
yuxuanchen1997 pushed a commit that referenced this pull request Jul 25, 2024
The Fortran standard committees passed an "interp" request at their June
2024 meetings that is distinct from nearly every other Fortran compiler
that I tried (6) in an an ambiguous case (parent component naming when
the base type has been renamed via USE association). Document this case
in flang/docs/Extensions.md as an intentional instance of
non-conformance chosen for portability and better usability.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flang:semantics flang Flang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants