Skip to content

Dyno: Iterate over param enum ranges#27586

Merged
DanilaFe merged 6 commits intochapel-lang:mainfrom
DanilaFe:iterate-param-enums
Aug 5, 2025
Merged

Dyno: Iterate over param enum ranges#27586
DanilaFe merged 6 commits intochapel-lang:mainfrom
DanilaFe:iterate-param-enums

Conversation

@DanilaFe
Copy link
Contributor

@DanilaFe DanilaFe commented Aug 1, 2025

Closes https://github.com/Cray/chapel-private/issues/7404.

This PR enables param iteration over ranges of enums. For instance, the following program produces one warning for every element in letters:

enum letters {a, b, c, d, e, f}

for param c in letters.a..letters.f {
  compilerWarning(c:string);
}

Curiously the original reproducer in https://github.com/Cray/chapel-private/issues/7404 does not work as expected, because warnings are not emitted from inside main. Not sure why that's the case, but it seems to be independent of param iteration.

While there, this PR resolves signedness concerns (preventing overflow etc.).

The high-level outline of the change is to think of iteration over enums as iteration over the indices of their elements. This is similar to, but not the same as, the enum's int values (not the same because users can change the values of enums by assigning them different integers, like red = 42).

Testing

  • dyno tests
  • motivator passes
  • paratest
  • paratest --dyno-resolve-only

Reviewed by @benharsh -- thanks!

Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
@DanilaFe DanilaFe force-pushed the iterate-param-enums branch from fe73c46 to 4daf0af Compare August 1, 2025 16:36
@benharsh benharsh self-requested a review August 1, 2025 17:32
};

template <typename R>
static bool populateParamRangeInfoFromBound(R& scratch, optional<typename R::Iter> low, optional<typename R::Iter> hi, Range::OpKind opKind, int step, int numElts) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could/should these two "populate" functions be part of a factory method on one of these structs?

auto enumType = yieldType->toEnumType();
auto enumDecl = parsing::idToAst(context, enumType->id())->toEnum();
CHPL_ASSERT(enumDecl);
auto info = toOwned(new EnumParamRangeInfo(enumDecl->enumElements()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the logic in this branch be better placed in a factory method?

Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
Signed-off-by: Danila Fedorin <daniel.fedorin@hpe.com>
@DanilaFe DanilaFe merged commit 9bee457 into chapel-lang:main Aug 5, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants