Marginally improve v0 error granularity and testing. #54
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
|
Seems reasonable to me, thanks! |
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.
Most of this PR is for the
v0: move the (long) fuzzer-generated testcases into a separate file.commit, which uses a separate text file for the large symbols #49 added directly tosrc/v0.rs.This may be a minor inconvenience, but having the huge strings mixed in with more feature-oriented tests didn't sit right with me (it doesn't help that VSCode fails to collapse anything containing multi-line strings like that, apparently, but that's just a VSCode bug at the end of the day).
Only the
v0: replace control characters with . in fuzzer-generated testcases.commit changes the actual content of any of the fuzzer-generated symbols, and in an insignificant way (the recursion limit is still hit regardless).The last commit (
Rework size limiting to not "leak" fmt::Errors to the user.) didn't end up being needed for any of the fuzzer-generated testcases, so I would be fine with splitting it into a separate PR (I don't think it even depends on any other commit in this PR, it was just something I wanted to fix).Overall I'm not too attached to specifics of this PR, and it may be a waste of time, but I wanted to try anyway.