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-2777] Diagnostics missing when method name shadows a global function with a different signature. #45381

Closed
atrick opened this issue Sep 28, 2016 · 5 comments
Assignees
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

@atrick
Copy link
Member

atrick commented Sep 28, 2016

Previous ID SR-2777
Radar rdar://26058520
Original Reporter @atrick
Type Bug
Status Closed
Resolution Invalid
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee @atrick
Priority Medium

md5: 05b9c4dc28e7d3ab36b0e43e17bdbc8b

relates to:

  • SR-5459 Cannot overload with an inner function
  • SR-4660 Methods on self should not block unambiguous calls to free functions

Issue Description:

This is a problem that I've hit in practice multiple times. I have two functions with the same base name but different signatures--so effectively their names are different. One of the functions is generic. I'm unable to invoke the intended function. In this trivial test case, the compiler reports and invalid error. However, I've run into other scenarios where the compiler silently miscompiles the code.

func foo(with: Int) {}

struct S {
  func foo<T>(_: T) {}
  func bar() {
    foo(with: 1)
  }
}

t.swift:6:8: error: extraneous argument label 'with:' in call
    foo(with: 1)
       ^~~~~~~
@belkadan
Copy link
Contributor

This is behaving as designed: members always shadow top-level names with the same base name, ignoring both types and argument labels. This does keep coming up, though.

@atrick
Copy link
Member Author

atrick commented Sep 28, 2016

The "ignoring argument labels" aspect is very surprising.

The miscompile may be a different bug. Changing the name of expectEqualTest<T>(...) to expectEqual() in StdlibUnittest.swift.gyb broke a lot of tests last time I checked.

@belkadan
Copy link
Contributor

I think we should close this (in favor of other shadowing issues) until we have an example that doesn't involve that.

@atrick
Copy link
Member Author

atrick commented Sep 29, 2016

I'm attempting to reproduce the original type system bug but now hitting this crash:
https://bugs.swift.org/browse/SR-2787

Assuming the shadowing issue is expected, we have a diagnostic bug. We should add a note that the top-level name (which the user is obviously trying to invoke) is shadowed by something with the same base name but different signature.

@rudkx asked me for diagnostic bugs, so I'll keep this open unless he decides it's not worthwhile.

@atrick
Copy link
Member Author

atrick commented Aug 18, 2017

The example in the description is invalid. I'll file a new SR for

<rdar://problem/26058520> Generic type constraints incorrectly applied to functions with the same name

@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

2 participants