Skip to content

Fix incorrect bitmask exposed by DeferredMemberSchema #842

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 11, 2025

Conversation

rationull
Copy link
Contributor

Issue #, if available:
I did not file an issue.

Description of changes:

The bitmask applies to the member, not its target schema -- delegating to the target schema exposes the wrong bitmask.

Also fix an incidental similar issue in
requiredStructureMemberBitField(), though I haven't seen any negative effects from the previous implementation of that one.

This is a pretty esoteric issue, reproduction with Validator requires a DeferredMemberSchema to exist with the right characteristics, and not be replaced with a concretely built MemberSchema prior to being operated on. I identified this case when debugging a member schema incorrectly marked as recursive due to #841. Esoteric or not, the existing behavior seems wrong to me; happy to be corrected if I'm missing something.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Comment on lines 58 to 63
var target = memberTarget();
return SchemaBuilder.computeRequiredBitField(
type(),
target.requiredMemberCount(),
target.members(),
Schema::requiredByValidationBitmask);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure this change is really needed .. I haven't been able to reproduce any bad behavior without it. This new code matches MemberSchema's behavior (but lazy/deferred). On the other hand, it seems like MemberSchema could just delegate to target.requiredStructureMemberBitfield() like this used to, and still be correct as long as the requireStructureMemberBitfield value cannot change for a given schema once build. Maybe that's a better change, simpler overall?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I am inclined for the latter. I don't think the requireStructureMemberBitfield changes once built.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks Adwait -- this makes the most sense to me too. Updated.

@@ -26,7 +26,7 @@ final class MemberSchema extends Schema {
this.requiredStructureMemberBitfield = SchemaBuilder.computeRequiredBitField(
type(),
target.requiredMemberCount(),
builder.target.members(),
target.members(),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Incidental change for consistency with line 28 -- target and builder.target are the same at this point.

The bitmask applies to the member, not its target schema -- delegating
to the target schema exposes the wrong bitmask.

Also change MemberSchema.requiredStructureMemberBitfield() to delegate
to its target, because the bitfield *is* derived from the target type
(not the specific member usage of the target type).
@rationull rationull force-pushed the deferred-member-schema-bitmask branch from d75f15f to 1d509ab Compare August 9, 2025 04:41
@adwsingh adwsingh merged commit 761be79 into smithy-lang:main Aug 11, 2025
2 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