[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
Thu Aug 6 22:46:35 PDT 2026
================
@@ -1216,6 +1276,88 @@ static const Symbol *FindInaccessibleComponent(common::DefinedIo which,
return FindInaccessibleComponent(which, derived, scope, visited);
}
+// Finds a direct (effective) component whose type is an enumeration type,
+// expanding a derived-type list item into its components per F2023 12.6.3. A
+// component that is itself processed by defined I/O is treated as a single
+// value and is not expanded, so its subtree is skipped (based off of
+// FindInaccessibleComponent).
+//
+// The walk is memoized on the *instantiated scope* (derived.scope()), which is
+// the key that distinguishes two parameterized-derived-type instantiations
+// sharing one type symbol -- their defined-I/O shielding is decided per
+// instantiation (HasDefinedIo). This is a two-color DFS:
+// - 'onPath' holds the scopes currently on the recursion stack; a repeat
+// entry is an F2023 C749 recursive-type cycle and is pruned without being
+// cached, since that partial result is only valid under the ancestor.
+// - 'cache' holds the result of each fully-walked subtree, giving linear
+// cost instead of the fanout^depth of an unmemoized path-scoped walk.
+// The cache is sound because a subtree's result depends only on 'which', the
+// (fixed) outer 'scope', and the instantiated scope's contents; for the
+// acyclic type graphs that legal unformatted I/O permits, no cycle prune
----------------
MattPD wrote:
The cycle case is accurate now. One point left, and it is not wording. The argument also depends on the cache not outliving one top-level query. A subtree walked while an ancestor was pruned can be cached with a result that is wrong for that subtree alone. That stays harmless only because the cache is discarded with the query. The comment should name that assumption, because reusing the cache across queries is the natural next optimization.
https://github.com/llvm/llvm-project/pull/193235
More information about the flang-commits
mailing list