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

Jump to bottom

[SR-10597] KeyPath dynamic member lookup: Name lookup failure diagnostics only talk about the wrapped type #52997

Closed
xedin opened this issue May 1, 2019 · 6 comments
Closed

[SR-10597] KeyPath dynamic member lookup: Name lookup failure diagnostics only talk about the wrapped type #52997

xedin opened this issue May 1, 2019 · 6 comments
Assignees
@LucianoPAlmeida
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers type checker Area → compiler: Semantic analysis

Comments

@xedin
Copy link
Member

xedin commented May 1, 2019

Previous ID SR-10597
Radar rdar://problem/50375204
Original Reporter @xedin
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, StarterBug, TypeChecker
Assignee @LucianoPAlmeida
Priority Medium

md5: a3f69bcea4566910b008fea878b68cd0

Issue Description:

Name lookup failure diagnostics on `@dynamicMemberLookup` types only talk about the wrapped type.

In the example below, the diagnostic talks about `Target`, and doesn't mention `S<Target>`. Similarly, typo correction will find members of `Target`, but not `S<Target>`. It should probably mention both types and include typo corrections on S<Target>.

struct Target {
  // var wooo: Target { Target() }
}

@dynamicMemberLookup
struct S<T> {
  var obj: T
  init(_ obj: T) { self.obj = obj }
  subscript<U>(dynamicMember member: KeyPath<T, U>) -> U {
    return obj[keyPath: member]
  }
  var wooo: Target { Target() }
}

_ = S<Target>(Target()).wooooo // error: value of type 'Target' has no member 'wooooo'
@LucianoPAlmeida
Copy link
Collaborator

@xedin Is anyone assigned to this one? Looking for starter bugs that I could work on. So if there no one yet I could start the work here 🙂

@xedin
Copy link
Member Author

xedin commented Aug 2, 2019

@LucianoPAlmeida I'm not aware of anybody currently working on this one, so it's yours to take 🙂

@LucianoPAlmeida
Copy link
Collaborator

Oh right, so starting then. Thank's for the answer @xedin

@LucianoPAlmeida
Copy link
Collaborator

Hey @xedin,

After investigating for a while, found that this message is already being implemented here. The message is right when S<T> doesn't have a dynamicMemberLookup attribute because the baseType is correct and it can perform the typo correction on the right type. But when it has a dynamicMemberLookup attribute the baseType that arrives in the diagnostics here is a type variable that resolves to a `Target` type, so it ends up not able to find any typo correction, which is right because it is looking to the wrong type and it ends up emitting the basic diagnostic. We could simply solve this by getting the type of the baseExpr there if `getLocator()->isForKeyPathDynamicMemberLookup()` but it seems not right to me and looks like the right way would be to find why a type variable that resolves to the wrong Target type is being handed here.

I've tried to look where the fix is being created here to find out some more info the type that is being passed there, but no success yet.

This is the progress until now, but I'm just getting familiar with the constraint system, so this is more asking to know if that's the right path to follow and if you have any tips of where to look from this point 🙂

@xedin
Copy link
Member Author

xedin commented Aug 9, 2019

@LucianoPAlmeida Thanks for working on this! I think the "fix" behavior is correct and we just need to add a tailored diagnostic to `MissingMemberFailure` so when locator is `isForKeyPathDynamicMemberLookup()` it would talk about member missing from both wrapper and its underlying type.

@LucianoPAlmeida
Copy link
Collaborator

Thank's for the answer @xedin, working on it
Edit: Here's the PR #26576

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@LucianoPAlmeida LucianoPAlmeida

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@xedin @LucianoPAlmeida