fix(patterns)!: Account for the compactOrdered "~" prefix when computing coverage #3053
+790
−191
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… computing coverage
… ..., nonKey, ...])`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #3046
Fixes #3051
Fixes #3052
Description
getRankCoverimplementations and output, particularly for non-Key CopyArrays that have an all-Keys prefix.getRankCover.Security Considerations
None known; the bugs do not seem to be exploitable in the hardened environment relied upon by
@endo/patterns.Scaling Considerations
n/a
Documentation Considerations
Functions that assume the absence of an encoding prefix have been marked as deprecated in both JSDoc comments and in NEWS.md.
Testing Considerations
New and improved.
Compatibility Considerations
The included fix for #3052 results in the range corresponding with an unknown kind matcher covering all (and only) tagged values, effectively precluding the addition of any new pass style in the future. That could instead be changed to e.g. cover all values (à la
M.any()), or to maintain the existing behavior of throwing an exception.Upgrade Considerations
These improvements should be harmless to include, and AFAICT will have only minor effects on agoric-sdk because that system does not even use compactOrdered, let alone support composite collection keys in durable storage.