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

Go: Fix missing promoted fields due to name clash #18001

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

owen-mc
Copy link
Contributor

@owen-mc owen-mc commented Nov 17, 2024

When two embedded fields at different depths have the same name (but are not the same type - they are in different packages and happen to have the same name) then we don't treat the second one correctly and we don't promote any of its fields or methods. This turns out to be because of a condition that was added to avoid non-termination on cyclic structs in github/codeql-go#184 which only checked the name of the embedded field. The fix is to also check the type.

While looking into this I noticed that we have two different predicates for calculating field candidates. This PR includes a refactoring to remove the redundancy and make the code easier to understand.

@owen-mc
Copy link
Contributor Author

owen-mc commented Nov 18, 2024

Hmm, the tests pass locally for me. I'll have to look into that more.

@owen-mc owen-mc force-pushed the go/fix/missing-promoted-fields branch from 7c51705 to 85a19e8 Compare November 22, 2024 00:01
NCField should be promoted to EmbedsNameClash. Currently it isn't
because its embedded parent pkg2.NameClash is not a promoted field in
EmbedsNameClash (because of a name clash with pkg1.NameClash), but this
should not make a difference.
@owen-mc owen-mc force-pushed the go/fix/missing-promoted-fields branch from 2547c83 to 4a05c3d Compare November 22, 2024 00:17
@owen-mc
Copy link
Contributor Author

owen-mc commented Nov 22, 2024

I figured it out. I was using the released CLI, but #17941 changes the extractor and hence the test results, so I needed to build and use the go extractor locally.

This is ready to review now.

Copy link
Contributor

@smowton smowton left a comment

Choose a reason for hiding this comment

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

Haven't reviewed the tests in detail, but I'm 99% convinced the elimination of getFieldCand vs hasFieldCand is sound. One difference jumps out: getFieldCand uses hasEmbeddedField which doesn't look through a NamedType before using .(PointerType).getBaseType(), getFieldOfEmbedded does. This might make a difference if X is embedded where X is defined type X *Y, in a positive direction. I note hasMethodCand uses this embedded-field predicate as well.

Definitely needs DCA.

@owen-mc
Copy link
Contributor Author

owen-mc commented Nov 25, 2024

Note that getFieldCand uses hasEmbeddedField, which is defined using hasFieldCand. So it seems independent, but actually it isn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants