Skip to content

Rust: Crate graph extraction workarounds #19362

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

Merged
merged 2 commits into from
Apr 30, 2025

Conversation

hvitved
Copy link
Contributor

@hvitved hvitved commented Apr 24, 2025

This PR works around two issues in the crate graph extractor:

  1. We currently don't know when a trait function has a default implementation, so we assume that it always does.
  2. The crate graph extractor sometimes generates paths that are not valid, in terms of visibility. For example, instead of generating the path core::iter::Iterator (because that's how it is publicly visible), it generates core::iter::traits::iterator::Iterator, which mentions the private traits module.

DCA looks great; the Missing call targets metric goes down for all projects, without significant analysis slowdown.

DCA is somewhat mixed, we both gain and lose call edges; the reason why we lose call edges is that functions extracted from the crate graph don't include constraints, so the isFullyParametric incorrectly always hold for those.

CC: @aibaars

@github-actions github-actions bot added the Rust Pull requests that update Rust code label Apr 24, 2025
@hvitved hvitved force-pushed the rust/crate-extraction-workarounds branch from 6919095 to 3ce7728 Compare April 24, 2025 09:48
@hvitved hvitved marked this pull request as ready for review April 25, 2025 06:26
@Copilot Copilot AI review requested due to automatic review settings April 25, 2025 06:26
@hvitved hvitved requested a review from a team as a code owner April 25, 2025 06:26
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot wasn't able to review any files in this pull request.

Files not reviewed (2)
  • rust/ql/lib/codeql/rust/internal/PathResolution.qll: Language not supported
  • rust/ql/lib/codeql/rust/internal/Type.qll: Language not supported

@hvitved hvitved requested review from paldepind and Copilot April 25, 2025 06:27
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot wasn't able to review any files in this pull request.

Files not reviewed (2)
  • rust/ql/lib/codeql/rust/internal/PathResolution.qll: Language not supported
  • rust/ql/lib/codeql/rust/internal/Type.qll: Language not supported

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.

Really great to get this fixed!

Comment on lines 376 to 379
exists(TraitItemNode t |
this = t.getAnAssocItem() and
not this.fromSource()
)
Copy link
Contributor

Choose a reason for hiding this comment

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

What about this?

Suggested change
exists(TraitItemNode t |
this = t.getAnAssocItem() and
not this.fromSource()
)
not this.fromSource() and
this = any(TraitItemNode t).getAnAssocItem()

(
// when a method exists in both source code and in library code, it is because
// we also extracted the source code as library code, and hence we only want
// the method from source code
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this not affect path resolution as well? Could the workaround be done in path resolution? Or is there a benefit to having getASuccessor give the duplicated methods?

super.hasBody()
or
// for trait items from library code, we do not currently know if they
// have default implementations or not, so we assume they do
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we assume that they have implementations and not the other way around (assume that they don't)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is what we did before, and that meant we were unable to resolve such calls

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I see. I would've thought that they'd just be prioritized lower in getStaticTarget.

Comment on lines 331 to 334
exists(TraitItemNode t |
this = t.getAnAssocItem() and
not this.fromSource()
)
Copy link
Contributor

Choose a reason for hiding this comment

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

What about this?

Suggested change
exists(TraitItemNode t |
this = t.getAnAssocItem() and
not this.fromSource()
)
not this.fromSource() and
this = any(TraitItemNode t).getAnAssocItem()

@hvitved hvitved force-pushed the rust/crate-extraction-workarounds branch from 3ce7728 to da68329 Compare April 30, 2025 09:03
@hvitved hvitved force-pushed the rust/crate-extraction-workarounds branch from da68329 to 52bd99b Compare April 30, 2025 09:04
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.

Great! Thanks for fixing this and to me it seems nice how it's contained inside path resolution now :)

@hvitved hvitved merged commit 389f15e into github:main Apr 30, 2025
16 checks passed
@hvitved hvitved deleted the rust/crate-extraction-workarounds branch April 30, 2025 13:11
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