Skip to content

Improve time complexity of handling large WIT types #2167

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
Apr 29, 2025

Conversation

alexcrichton
Copy link
Member

Update a few places in tooling which iterate over the structure of a WIT type to contain early-returns or similar to ensure that processing these large types doesn't take an exponential amount of time.

Closes #2164

Update a few places in tooling which iterate over the structure of a WIT
type to contain early-returns or similar to ensure that processing these
large types doesn't take an exponential amount of time.

Closes bytecodealliance#2164
@alexcrichton
Copy link
Member Author

cc @cpetig

Comment on lines +3 to +6
// TODO: this should use "FAIL" and should actually be a test, but this
// currently takes too long to run and the long runtime is in and of itself a
// bug.
// fail[abi]: component embed --dummy % | component new
Copy link
Member Author

Choose a reason for hiding this comment

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

This is an interesting test where the test below actually fits in the flat representation, unlike all of the above tests which don't fit flat. This test takes quite a long time to produce the flat representation.

This isn't a problem for validation since this type is "too large and complex" and fails validation before we get to the flat representation, but is still an issue for tooling which I'm not sure how best to handle.

@alexcrichton alexcrichton added this pull request to the merge queue Apr 29, 2025
Merged via the queue into bytecodealliance:main with commit 725ae03 Apr 29, 2025
32 checks passed
@alexcrichton alexcrichton deleted the fix-deep-types branch April 29, 2025 17:36
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.

Nested tuples and fixed size lists use a lot of memory
2 participants