Skip to content
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

Resolve dupe apply to mixed members #2030

Conversation

milesziemer
Copy link
Contributor

Fixes #2004.

When an apply statement targets a mixed in member, the trait application is stored until the mixed in member has been synthesized. However, if you load the same model file multiple times in the same loader, the trait application is only stored once, and removed when it is claimed, so when de-conflicting the duplicate mixed-in member definitions, only one of them will have the trait applied, resulting in a conflict.

This commit updates the loader to keep track of when these unclaimed traits have been claimed, rather than just removing them when claimed. As long as the traits have been claimed once, we know they aren't being applied to a non-existent shape. This allows the traits to be claimed multiple times if necessary.

Test cases were added for two different situations:

  1. If the exact same model is loaded multiple times, so there are multiple instances where the traits need to be claimed. In this case there shouldn't be conflicts like in the issue.
  2. If the apply statement is loaded multiple times, but the member it targets is only loaded once. In this case there shouldn't be any unclaimed traits, even though there are technically multiple of the same apply
    statements.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Fixes smithy-lang#2004.

When an apply statement targets a mixed in member, the trait
application is stored until the mixed in member has been
synthesized. However, if you load the same model file multiple
times in the same loader, the trait application is only stored
once, and removed when it is claimed, so when de-conflicting
the duplicate mixed-in member definitions, only one of them
will have the trait applied, resulting in a conflict.

This commit updates the loader to keep track of when these
unclaimed traits have been claimed, rather than just removing
them when claimed. As long as the traits have been claimed
once, we know they aren't being applied to a non-existent
shape. This allows the traits to be claimed multiple times
if necessary.

Test cases were added for two different situations:
1. If the exact same model is loaded multiple times, so
there are multiple instances where the traits need to be
claimed. In this case there shouldn't be conflicts like
in the issue.
2. If the apply statement is loaded multiple times, but
the member it targets is only loaded once. In this case
there shouldn't be any unclaimed traits, even though
there are technically multiple of the same apply
statements.
@milesziemer milesziemer requested a review from a team as a code owner November 6, 2023 21:22
@milesziemer milesziemer merged commit 4678712 into smithy-lang:main Nov 8, 2023
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.

Model assembler claims conflicting members - false positive
3 participants