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

Add more test cases for calling no-return functions #252

Merged
merged 4 commits into from
Jun 6, 2024

Conversation

yuxincs
Copy link
Contributor

@yuxincs yuxincs commented May 30, 2024

This PR adds more test cases to test NilAway's ability to handle no-return functions (such as os.Exit, runtime.Goexit, testing.T.SkipNow etc.).

Copy link

codecov bot commented May 30, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.55%. Comparing base (885be9d) to head (422fc25).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #252   +/-   ##
=======================================
  Coverage   87.55%   87.55%           
=======================================
  Files          63       63           
  Lines        7828     7828           
=======================================
  Hits         6854     6854           
  Misses        796      796           
  Partials      178      178           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link

github-actions bot commented May 30, 2024

Golden Test

Note

✅ NilAway errors reported on standard libraries are identical.

3296 errors on base branch (main, 885be9d)
3296 errors on test branch (995a6d8)

Copy link
Contributor

@sonalmahajan15 sonalmahajan15 left a comment

Choose a reason for hiding this comment

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

By and large looks good to me. Just a small question about whether we should set successors to nil or point to the return block.

}
print(*ptr)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Appreciate the detailed tests! 👍

continue
}
if trustedfunc.TrimSuccsOn(p.pass, call) {
block.Succs = nil
Copy link
Contributor

Choose a reason for hiding this comment

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

I was just wondering if we should set successors to nil or point to the return block... What is the behavior of the drivers where this behavior is handled correctly? Perhaps we can simulate that behavior here.

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 compared the correct behaviors and it seems that block.Succs == nil is the behavior, so we're following that practice.

This is also documented: https://pkg.go.dev/golang.org/x/tools/go/cfg

A block may have 0-2 successors: zero for a return block or a block that calls a function such as panic that never returns; one for a normal (jump) block; and two for a conditional (if) block.

Anyway, I think this comment is no longer applicable since we decided to just fix the upstream ctrlflow analyzer instead of doing hacky postfixes in NilAway.

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it. Makes sense. Thanks for clarifying :)

@yuxincs
Copy link
Contributor Author

yuxincs commented Jun 5, 2024

Actually, instead of doing hacky postfixes in NilAway, we should just fix ctrlflow analyzer: golang/tools#497

Will repurpose this PR to just introduce those valuable test cases instead :)

@yuxincs yuxincs changed the title Fix CFG Succs for no-return functions from stdlib Add more test cases for calling no-return functions Jun 5, 2024
Copy link
Contributor

@sonalmahajan15 sonalmahajan15 left a comment

Choose a reason for hiding this comment

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

Actually, instead of doing hacky postfixes in NilAway, we should just fix ctrlflow analyzer: golang/tools#497

Will repurpose this PR to just introduce those valuable test cases instead :)

Oh yeah, makes complete sense! :)

@yuxincs yuxincs merged commit e902884 into main Jun 6, 2024
8 checks passed
@yuxincs yuxincs deleted the yuxincs/handle-abnormal-control-flow branch June 6, 2024 13:02
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.

2 participants