[flang-commits] [flang] [flang] Enumeration Type: (PR 2/5) Name Resolution + Expression + Relational + SELECT CASE (PR #193028)

[via flang-commits]

kwyatt-ext wrote:

> The constant/literal paths look correct and well-structured. However, every non-constant enum path (variables, dynamic constructors) produces semantic IR that will crash at lowering. Few issues:
> 
> 1. Non-constant constructor accepted but unlowerable
>    `flang/lib/Semantics/expression.cpp`: `AnalyzeEnumerationConstructor`
> 
> `color(i)` with variable `i` passes semantic checks (range validated only when `ToInt64(folded)` succeeds), producing a `StructureConstructor` with non-constant `__ordinal`. PR 4/5 lowering uses `ToInt64()` exclusively: non-constant hits fatal. Either reject non-constant arguments here (with a TODO for future support) or ensure the lowering PR handles them.
> 
> 2. Constructor bypasses scalar/kind validation
>    `flang/lib/Semantics/expression.cpp`: `AnalyzeEnumerationConstructor`
> 
> The custom path bypasses `CheckStructureConstructor()`. Only `argType->category() == Integer` is verified. No rank check (allows `color([1,2])`) and no kind conversion (allows `color(1_8)` storing INTEGER(8) into an INTEGER(4) component). Suggest: enforce rank-0 and convert to the component's declared kind.
> 
> Both are exercised by the standard use case of enum variables (not just constants). The test suite only uses literal enumerators, masking these paths.

Regarding #1, you are correct.  My intention was to handle it in lowering.  I had missed it.  The correction has been made and merged into PR4 under https://github.com/llvm/llvm-project/pull/193571/commits/d49c90c88fea2ce78a5e77e272d1f77c935d2c11

For #2, it has been addressed and a test case added.

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