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

Added upper bounds for sequences #149

Merged
merged 4 commits into from
Dec 16, 2024
Merged

Conversation

EliasC
Copy link
Contributor

@EliasC EliasC commented Nov 26, 2024

This PR adds support for giving upper bounds for sequences in the well-formedness specifications:

inline const auto some_wf =
  (File <<= Group++) // Zero or more groups
| (Foo <<= Group++[1]) // One or more groups
| (Bar <<= Group++[1][3] // Between one and three groups

One motivating use case is having a top-level optional shape (which is shorthand for ++[0][1]):

inline const auto foo_wf =
  some_wf
  | (Paren <<= ~(Foo | Bar)) // Optionally contains a single Foo or a single Bar

Before this, the closest you could get was using ++, which would mess with fuzz testing. Just as sequences, optional shapes can only be used at the top level of a shape; you still cannot write e.g. Paren <<= Foo * ~Bar or Paren <<= Foo * Bar++.

The JSON parser had File <<= Group++ even though the initial parse pass can produce at most one group, but I did not find any more interesting usages of this pattern in any other sample or parser. Manual toying around with this seems to suggest that both checking and generation handles the new shape correctly.

@EliasC EliasC changed the title Added top-level option shape to well-formedness specifications Added upper bounds for sequences Dec 4, 2024
@EliasC
Copy link
Contributor Author

EliasC commented Dec 4, 2024

I have updated this PR to generalise the Sequence shape instead of special casing an Option shape.

Comment on lines 267 to 278
Sequence& operator[](size_t new_len)
{
minlen = new_minlen;
if (!has_minlen)
{
minlen = new_len;
has_minlen = true;
}
else
{
maxlen = new_len;
}
return *this;
Copy link
Member

@mjp41 mjp41 Dec 4, 2024

Choose a reason for hiding this comment

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

Should we detect

Foo++[1][2][3]

as an error? Should we error for maxlen < minlen?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Neither of the errors give a strange behavior, but I guess it would be a slightly nicer user experience to check for it. I will add it...

Copy link
Member

Choose a reason for hiding this comment

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

I agree failing silently is in keeping with the codebase. ;)

@EliasC
Copy link
Contributor Author

EliasC commented Dec 4, 2024

Added bounds checking (min_len <= max_len and no more than two bounds) now!

@sylvanc sylvanc merged commit 5858239 into microsoft:main Dec 16, 2024
22 checks passed
matteB10 pushed a commit to matteB10/Trieste that referenced this pull request Dec 20, 2024
* Added top-level option shape to well-formedness specifications

* Replaced Option class by extended Sequence class

* Bounds checking for sequences

---------

Co-authored-by: Sylvan Clebsch <[email protected]>
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