Skip to content

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

Open
HT154 wants to merge 2 commits intoapple:mainfrom
HT154:power-assertions-unions
Open

Do not activate power assertions when a single union member containing a type constraint fails#1462
HT154 wants to merge 2 commits intoapple:mainfrom
HT154:power-assertions-unions

Conversation

@HT154
Copy link
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
@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
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 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
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
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
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.

3 participants