Skip to content

Remove "assertion failed" from successful assertions#562

Closed
jaisnan wants to merge 8 commits intomainfrom
jai-test
Closed

Remove "assertion failed" from successful assertions#562
jaisnan wants to merge 8 commits intomainfrom
jai-test

Conversation

@jaisnan
Copy link
Contributor

@jaisnan jaisnan commented Oct 18, 2021

Description of changes:

This change fixes the confusing "assertion failed" output that appears in test cases, even in success. For example,
"[main.assertion.2] line 30 assertion failed: weird_string == "w": SUCCESS".

Resolved issues:

Resolves #189

Call-outs:

Testing:

  • How is this change tested?
  • Ran existing regression tests and added my own tests
  • 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.

@jaisnan jaisnan changed the title Fix for issue #189 Remove "assertion failed" from successful assertions #189 Oct 18, 2021
@jaisnan
Copy link
Contributor Author

jaisnan commented Oct 18, 2021

Submitted the PR to main branch by mistake, which is causing CI errors for push.

@jaisnan jaisnan changed the title Remove "assertion failed" from successful assertions #189 Remove "assertion failed" from successful assertions Oct 18, 2021
@jaisnan jaisnan requested a review from celinval October 18, 2021 22:06
Copy link
Contributor

@danielsn danielsn left a comment

Choose a reason for hiding this comment

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

General comment: how do we protect against rustc making small changes to the string which would break this?

Comment on lines +647 to +649
/// This function extracts the "assertion failed" string which is created by the rust stdl. It
/// causes confusing outputs like "assertion failed: 1 == 1" SUCCESS to be printed out. This function
/// can extract the "assertion failed" component out and change the string to "assertion"
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment needs to be more clearly written

/// can extract the "assertion failed" component out and change the string to "assertion"
fn extract_panic_string(e: &Expr) -> Option<String> {
// The MIR represents the StringConstant as `&"constant"[0]`. We are representing a rust str type as a struct.
let arg: &str = match e.struct_expr_values().unwrap()[0].value() {
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a clearer name than arg here?

/// causes confusing outputs like "assertion failed: 1 == 1" SUCCESS to be printed out. This function
/// can extract the "assertion failed" component out and change the string to "assertion"
fn extract_panic_string(e: &Expr) -> Option<String> {
// The MIR represents the StringConstant as `&"constant"[0]`. We are representing a rust str type as a struct.
Copy link
Contributor

Choose a reason for hiding this comment

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

This is goto, not MIR at this point.

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe the issue is that by the time we get the string, its been lowered from a string constant to a char*. Maybe have a utility function to reverse that lowering, and then just use that here would be more self documeting

_ => return None,
};

// "assertion failed: 1 == 1: SUCCESS" was confusing, so we removed the "failed"
Copy link
Contributor

Choose a reason for hiding this comment

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

So far, have we always seen that prefix? If so, maybe we should just assert that we find it so we're more stable against rustc changes

Copy link
Contributor

Choose a reason for hiding this comment

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

We're in codegen_panic so any panic! message might be here. It's just the assert! case we're trying to recognize and rewrite.

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.

I'm really sorry for the late comment, but I don't think this is the right approach to this problem. Panic messages tend to state an error. Assertion is just one way out of tens if not hundreds panic messages that are generated by rustc. We can't just rewrite them all.

Here are a few examples:

[dummy.assertion.1] line 7 internal error: entered unreachable code: SUCCESS
[main.pointer_dereference.1] line 17 dereference failure: pointer NULL in *var_7: SUCCESS
[__builtin_powif.assertion.1] assertion false: SUCCESS

I think we should be polishing the CBMC output instead.

@tedinski
Copy link
Contributor

The parts of this I was thinking of salvaging were incorporated into Celina's #687, so with Jai's #665 merged I'm closing this PR.

@tedinski tedinski closed this Dec 13, 2021
@zhassan-aws zhassan-aws deleted the jai-test branch March 1, 2022 18:57
@adpaco-aws adpaco-aws mentioned this pull request Apr 5, 2022
4 tasks
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.

Can we remove "assertion failed" from successful assertions?

4 participants