Skip to content

Do not activate power assertions when a single union member containing a type constraint fails#1462

Merged
HT154 merged 3 commits intoapple:mainfrom
HT154:power-assertions-unions
Mar 25, 2026
Merged

Do not activate power assertions when a single union member containing a type constraint fails#1462
HT154 merged 3 commits intoapple:mainfrom
HT154:power-assertions-unions

Conversation

@HT154
Copy link
Copy Markdown
Contributor

@HT154 HT154 commented Mar 5, 2026

Prior to this change, this code would activate powers assertions / instrumentation permanently:

foo: String(contains("a")) | String(contains("b")) = "boo"

This is because the contains("a") constraint would fail, triggering power assertions, but the subsequent check of the union's contains("b") branch would succeed.
As observed in #1419, once instrumentation is enabled, all subsequent evaluation slows significantly.
As with #1419, the fix here is to disable power assertions via VmLocalContext until we know that all union members failed type checking; then, each member is re-executed with power assertions allowed to provide the improved user-facing error.

@HT154 HT154 force-pushed the power-assertions-unions branch from 6bfa733 to 48617a1 Compare March 5, 2026 02:25
Comment thread pkl-core/src/main/java/org/pkl/core/EvaluatorImpl.java Outdated
@HT154 HT154 marked this pull request as ready for review March 5, 2026 19:13
nowimlost
nowimlost approved these changes Mar 10, 2026
@apple apple deleted a comment from nowimlost Mar 10, 2026
@apple apple deleted a comment from nowimlost Mar 10, 2026
Copy link
Copy Markdown
Collaborator

@holzensp holzensp left a comment

Choose a reason for hiding this comment

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

Not the prettiest, but I can't think of something prettier. No blockers.

Comment thread pkl-core/src/main/java/org/pkl/core/EvaluatorImpl.java Outdated
Comment on lines +1058 to +1068
localContext.setInTypeTest(wasInTypeTest);
if (VmContext.get(this).getPowerAssertionsEnabled()
&& (!wasInTypeTest || localContext.hasActiveTracker())) {
for (var i = 0; i < elementTypeNodes.length; i++) {
try {
elementTypeNodes[i].executeEagerly(frame, value);
} catch (VmTypeMismatchException e) {
typeMismatches[i] = e;
}
}
}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

My spidey senses tingle at the lack of DRYness. I don't want to insist on DRYness per se, but would like to ask the question out loud; worth a private static helper or similar.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is certainly possible, but I'm hesitant to do it without more context here, i.e. why does executeLazily use @ExplodeLoop but executeEagerly does not? Was this not already DRY'd up because of some optimization?

@HT154 HT154 force-pushed the power-assertions-unions branch from 4604dc2 to 80f733a Compare March 10, 2026 19:11
@HT154 HT154 requested a review from holzensp March 10, 2026 19:11
Copy link
Copy Markdown
Contributor

@stackoverflow stackoverflow left a comment

Choose a reason for hiding this comment

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

Looks good. Some nits.

Comment thread pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java Outdated
Comment thread pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java
Comment thread pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java Outdated
Comment thread pkl-core/src/main/java/org/pkl/core/runtime/VmLocalContext.java Outdated
@HT154 HT154 force-pushed the power-assertions-unions branch from dd1ed2d to 3cca13f Compare March 25, 2026 18:44
@HT154 HT154 merged commit a9c890e into apple:main Mar 25, 2026
16 checks passed
@HT154 HT154 deleted the power-assertions-unions branch March 25, 2026 18:52
HT154 added a commit that referenced this pull request Mar 25, 2026
…g a type constraint fails (#1462)

Prior to this change, this code would activate powers assertions /
instrumentation permanently:
```pkl
foo: String(contains("a")) | String(contains("b")) = "boo"
```

This is because the `contains("a")` constraint would fail, triggering
power assertions, but the subsequent check of the union's
`contains("b")` branch would succeed.
As observed in #1419, once instrumentation is enabled, all subsequent
evaluation slows significantly.
As with #1419, the fix here is to disable power assertions via
`VmLocalContext` until we know that all union members failed type
checking; then, each member is re-executed with power assertions allowed
to provide the improved user-facing error.
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.

4 participants