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

[SR-13195] Global func is not resolved because of the class method with the same name #55635

Closed
swift-ci opened this issue Jul 10, 2020 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-13195
Radar None
Original Reporter ysoftware (JIRA User)
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53).

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee ysoftware (JIRA)
Priority Medium

md5: 29a72d15212444c69ff4be88473098f4

Issue Description:

The following code doesn't build:

func bar(second: String) { fatalError() }

class Foo {    
  func bar(first: String) { fatalError() }

  func main() {  
    bar(second: "") 
  }
}

// incorrect argument label in call (have 'second:', expected 'first:') 

The parser gets confused by the class method and doesn't even try to resolve the global function.

If I remove the method, the function it's resolved correctly.

If I move the function inside the class, it's resolved correctly.

@LucianoPAlmeida
Copy link
Collaborator

The problem seems that you have to qualify bar(second: ) call with the module name(given is a global)

Diagnostics are improved on 5.3

![](Screen Shot 2020-07-10 at 16.19.50.png)

@xedin this means it is fixed or this should compile?

@xedin
Copy link
Member

xedin commented Jul 10, 2020

I think the diagnostic is now current and compiler does expect module name to be use to disambiguate references like this because as a rule name lookup stops as soon as it finds inner most member, everything else should be qualified to be used. ysoftware (JIRA User) please use the latest snapshot of trunk to verify and close.

@swift-ci
Copy link
Collaborator Author

Comment by Ярослав Игоревич Ерохин (JIRA)

This works indeed! Thank you,

@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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants