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

Rust: More tests for rust/deadcode #17923

Merged
merged 6 commits into from
Nov 11, 2024
Merged

Conversation

geoffw0
Copy link
Contributor

@geoffw0 geoffw0 commented Nov 6, 2024

Add more tests for rust/deadcode (inspired by real world code), identifying more spurious and missing results.

@geoffw0 geoffw0 added the Rust Pull requests that update Rust code label Nov 6, 2024
}

const _: () = {
_ = 1; // $ SPURIOUS: Alert[rust/dead-code]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a child of a Const (Const > BlockExpr > StmtList > ExprStmt > AssignmentExpr); I'm not sure if we want to exclude these from the query, or add them to the CFG so that they're considered reachable.

Copy link
Contributor

Choose a reason for hiding this comment

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

One argument for including them in the CFG is that const code could contain unreachable code. If we exclude constant things, then we will not be able to detect this and other things (unused variables, etc.). An argument in the other direction is that code evaluated at compile time is unlikely to contain security issues. Or maybe it can?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It feels like const code is less likely to contain security issues, but still could. Certainly for data flow - for example the value of a security relevant constant (e.g. enabling or disabling a feature) could be computed in const code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you know what steps we need to take to include them in the CFG? Is it just a case of adding the entry points somewhere???

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've created an issue to track this, but I could do with some pointers (or someone else to take on the issue, if that is easier).

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks! I'll be looking at that together as well as the async problem 👍

if cond() {
do_something();
bail_1!(); // $ SPURIOUS: Alert[rust/dead-code]
do_something(); // $ MISSING: Alert[rust/dead-code]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is an issue with the workarounds for PostOrderTree and macro nodes. I'll figure out a way to fix it.

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've created an issue to track this, I know what to do but I have other priorities.

paldepind
paldepind previously approved these changes Nov 6, 2024
Copy link
Contributor

@paldepind paldepind left a comment

Choose a reason for hiding this comment

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

Examples look good to me 👍

Do you know why the variables used with await are spuriously marked unused? If not I can look into that.

@geoffw0
Copy link
Contributor Author

geoffw0 commented Nov 7, 2024

Do you know why the variables used with await are spuriously marked unused? If not I can look into that.

I've no idea, if you want to look into it that would be great. Maybe create an issue tracking this as well as it seems like it could be fairly important.

@paldepind
Copy link
Contributor

I've no idea, if you want to look into it that would be great. Maybe create an issue tracking this as well as it seems like it could be fairly important.

It turns out that it's because the control flow doesn't handle async blocks correctly. At this line the control flow goes directly into the block (which is not correct), the control flow graph then ends in a loop inside the loop, and everything after the loop becomes unreachable. This causes the later use of for_ten to not be considered.

I've created and internal issue for this

@geoffw0
Copy link
Contributor Author

geoffw0 commented Nov 8, 2024

I'm seeing consistency check failures outside of the tests that are affected by this PR. I think that means something's broken on the particular version of main we're based on here...

@paldepind
Copy link
Contributor

I'm seeing consistency check failures outside of the tests that are affected by this PR. I think that means something's broken on the particular version of main we're based on here...

I think you're right. I've tried to fix that in #17944.

@paldepind paldepind merged commit e3662fa into github:main Nov 11, 2024
13 checks passed
@paldepind
Copy link
Contributor

I hope it's ok that I merged. The CI is passing now and I'm looking at the async problem so it would be great to have these test cases on main 😄

@geoffw0
Copy link
Contributor Author

geoffw0 commented Nov 11, 2024

No problem at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Rust Pull requests that update Rust code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants