-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[cxx-interop] Fix spurious ambiguous member lookup #78132
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
Conversation
Another reason I'm opening this PR separate from #77726 is because I want to test it independently in CI. This change seems to cause a cascade of other issues, apparently because the existing tests have come to depend on nested calls to As such, @swift-ci please test |
@swift-ci please test |
Also include a little more of the mangled symbol, for more precise testing + better readability of the `// CHECK: ` directives (though they are still pretty unreadable)
@swift-ci Please smoke test |
@swift-ci Please test |
@swift-ci Please test |
@swift-ci Please test |
@swift-ci Please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
…ed members (#78673) Follow-up from #78132, which did not fix issues related to eagerly imported members like subscripts. This patch restructures recursive ClangRecordMemberLookup requests to importBaseMemberDecl() in the recursive calls, rather than propagating base member decls up to the initial lookup request and doing the import. Doing so seems to fix lingering resolution issues (which I've added to the regression tests). rdar://141069984
Nested calls to
importBaseMemberDecl()
subvert its cache and compromise its idempotence, causing the semantic checker to spuriously report ambiguous member lookups when multipleClangRecordMemberLookup
requests are made (e.g., because of an unrelated missing member lookup).One such scenario is documented in the test case I checked into the test suite in f818a5d, which fails without this fix (in particular,
inherited-lookup-typechecker.swift
fails because of the expected error from themissing
member;inherited-lookup-executable.swift
works because it does not attempt to access amissing
member).I noticed this bug in #77726 when I found that my
expected-error
s seemed to be triggering this unrelated error. I'm breaking out a small piece of that PR because (1) it is getting quite large, (2) it is getting stale, and (3) I am trying to separate this bug fix from that feature work.rdar://141069984