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

Increase width's width for trace values #2172

Merged
merged 7 commits into from
Feb 1, 2023

Conversation

adpaco-aws
Copy link
Contributor

Description of changes:

Resolved issues:

Resolves #2169

Call-outs:

Testing:

  • How is this change tested? CI + manually tested on example from Unhandled variant in ParserItem JSON #2169 (the example takes a few minutes to run, which is why I'm not including it in the regression).

  • Is this a refactor change? No.

Checklist

  • Each commit message has a non-empty body, explaining why the change was made
  • Methods or procedures are documented
  • Regression or unit tests are included, or existing tests cover the modified code
  • My PR is restricted to a single feature or bugfix

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

@adpaco-aws adpaco-aws requested a review from a team as a code owner January 31, 2023 21:09
@adpaco-aws adpaco-aws changed the title Increase width's width for trace values Increase width's width for trace values Jan 31, 2023
Copy link
Contributor

@celinval celinval left a comment

Choose a reason for hiding this comment

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

A few notes.

@@ -35,6 +35,8 @@ use std::os::unix::process::ExitStatusExt;
use std::path::PathBuf;
use std::process::{Child, ChildStdout};

const RESULT_ITEM_PREFIX: &str = " {\n \"result\":";
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we use regex instead or will this run all the time? I'm worried this is very fragile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There were a few things I considered here, for example trimming the string without delimiters (so we can check against "{\"result\":"). The problem is that trimming that string could impact performance: the one that caused the crash in #2169 is 921K lines (33MB). So I went for the most performant check (this one), which should run all the time.

// shouldn't be hard to debug with that information. The same strategy
// can be used for other `ParserItem` variants, but they're normally
// easier to debug.
if string_without_delimiter.starts_with(RESULT_ITEM_PREFIX) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Have you considered changing the signature of this function to Result and in the case of failure you can add the context that we failed on (i.e., what was the item that we were trying to parse).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't know which item we're trying to parse, that's why we use the ParserItem enum. I can change the signature to use Result<ParserItem> but I don't know what to with the result other than unwrap().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made the change but then dropped it because the new case would return a ResultStruct. I'm open to suggestions here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could you use expect() and add to the error message the string that we failed to parse.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for explaining the issue offline. I'll resolve this comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I cannot get rid of #[allow(unused)] even if use ResultStruct.result in the test.

Copy link
Contributor

@celinval celinval left a comment

Choose a reason for hiding this comment

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

Thanks

/// Checks that a valid CBMC "result" item can be deserialized into a
/// `ParserItem` or `ResultStruct`.
#[test]
fn check_result_deserialization_works() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!

@adpaco-aws adpaco-aws merged commit 5d265c7 into model-checking:main Feb 1, 2023
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.

Unhandled variant in ParserItem JSON
3 participants