[flang-commits] [flang] [llvm] [flang] Enumeration Type: (PR 3/5) Intrinsics + I/O + Modules (PR #193235)
via flang-commits
flang-commits at lists.llvm.org
Mon Aug 3 10:50:46 PDT 2026
================
@@ -1224,7 +1338,32 @@ 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);
----------------
kwyatt-ext wrote:
You got me on this one. I thought I had a justification for not allowing unformatted I/O. I've been digging through my notes for a while and can't find the reason for this limitation. After scouring the spec it doesn't seem like a valid limitation. On the other hand, allowing it means assuming that it present itself as the underlying integer ordinal. This is not specifically spelled out by the standard. I can go the ordinal route which is justifiable or enter a new issue for a decision and correction later. What do you prefer?
https://github.com/llvm/llvm-project/pull/193235
More information about the flang-commits
mailing list