Skip to content

[CodeCompletion] Improve accuracy of unresolved member completion #19584

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

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Sep 27, 2018

Follow up to #19567 (comment)

  • Handle generic base types
  • Suggests .some and .none for optional types
  • Don't look through too many parameter lists for function types
  • Include members with "convertible" type result. Previously it was "equals"

rdar://problem/44803439

@rintaro rintaro requested a review from benlangmuir September 27, 2018 10:50
@rintaro
Copy link
Member Author

rintaro commented Sep 27, 2018

@swift-ci Please smoke test

@rintaro
Copy link
Member Author

rintaro commented Sep 27, 2018

I'm not sure these are officially supported:

// Implicit member expression via member type construction.
class Base {
  class Derived : Base {}
}
let _: Base = .Derived()

// Implicit member expression via calling closure type static property.
struct Foo {
  static var factory: () -> Foo = { fatalError() }
}
let _: Foo = .factory()

I included them because the current compiler allows them.

@rintaro rintaro force-pushed the ide-completion-unresolvedmember-accurate branch from 2e05863 to 028fd6c Compare September 27, 2018 15:56
@rintaro
Copy link
Member Author

rintaro commented Sep 27, 2018

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor

@rintaro If they're allowed they're "supported". We don't have a formal spec :) At least the nested type case is something I've seen in real code before. Can you make sure they're tested somewhere in test/expr/dot as well?

* Handle generic base types
* Suggest '.some' and '.none' for optional types
* Don't look through too many parameter lists for function types
* Include members with convertible type result

rdar://problem/44803439
// UNRESOLVED_3_OPTOPTOPT-DAG: Decl[EnumElement]/ExprSpecific: North[#SomeEnum1#];
// UNRESOLVED_3_OPTOPTOPT-DAG: Decl[EnumElement]/ExprSpecific: South[#SomeEnum1#];
// UNRESOLVED_3_OPTOPTOPT-DAG: Decl[EnumElement]/ExprSpecific: none[#Optional<Wrapped>#]; name=none
// UNRESOLVED_3_OPTOPTOPT-DAG: Decl[EnumElement]/ExprSpecific: some({#Wrapped#})[#(Wrapped) -> Optional<Wrapped>#];
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we know why the generic Wrapped isn't resolved here?

Copy link
Member Author

@rintaro rintaro Sep 29, 2018

Choose a reason for hiding this comment

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

Yeah, that is what I'm wondering too. I'll look into it in followups.

Some uncommon cases including:
* Closure static properties
* Nested types
@rintaro rintaro force-pushed the ide-completion-unresolvedmember-accurate branch from 028fd6c to 07545b9 Compare September 29, 2018 08:23
@rintaro
Copy link
Member Author

rintaro commented Sep 29, 2018

Added test/expr test cases.
@swift-ci Please smoke test

@rintaro rintaro merged commit 0077149 into swiftlang:master Sep 29, 2018
@rintaro rintaro deleted the ide-completion-unresolvedmember-accurate branch September 29, 2018 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants