[flang-commits] [flang] [llvm] [flang] Enumeration Type: (PR 3/5) Intrinsics + I/O + Modules (PR #193235)

[via flang-commits]

================
@@ -1224,6 +1254,17 @@ parser::Message *IoChecker::CheckForBadIoType(const evaluate::DynamicType &type,
         where, "I/O list item may not be unlimited polymorphic"_err_en_US);
   } else if (type.category() == TypeCategory::Derived) {
     const auto &derived{type.GetDerivedTypeSpec()};
+    if (const auto *details{
+            derived.typeSymbol().detailsIf<DerivedTypeDetails>()}) {
+      if (details->isEnumerationType()) {
+        if (which == common::DefinedIo::ReadUnformatted ||
+            which == common::DefinedIo::WriteUnformatted) {
+          return &context_.Say(where,
+              "Enumeration type may not be used in unformatted I/O"_err_en_US);
+        }
+        return nullptr; // formatted I/O is allowed
----------------
MattPD wrote:

For a bare enumeration type this correctly allows formatted and rejects unformatted I/O. A derived type that merely contains an enumeration component is currently accepted in list-directed and unformatted I/O with no diagnostic:
```fortran
subroutine s
  enumeration type :: color
    enumerator :: red, green
  end enumeration type
  type :: has_color
    type(color) :: c
  end type
  type(has_color) :: d
  print *, d      ! list-directed
  write(10) d     ! unformatted
end subroutine
```
Both statements compile without error. The new namelist check does recurse into direct components for enums, so this looked like a possible inconsistency. Is the omission for list-directed and unformatted I/O intentional?

https://github.com/llvm/llvm-project/pull/193235