[SR-4559] Method called 'self' can be confused with regular 'self'

[swift-ci]

Previous ID	SR-4559
Radar	rdar://problem/24223414
Original Reporter	mouhcine (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Environment

macOS 10.12.4, Xcode 8.3.1

Additional Detail from JIRA

Votes	8
Component/s	Compiler
Labels	Bug
Assignee	mouhcine (JIRA)
Priority	Medium

md5: 557db84df0937d03fb4a61df8d1c72cf

is duplicated by:

• [SR-4865] target self should be illegal in property constructor #47442
• [SR-6895] Timer property with initializer and self target causes crash at runtime #49444
• [SR-7198] Using self in computed let #49746
• [SR-7368] Bugs of self-referencing Default Property Values in subclasses #49916
• [SR-7981] self available without backticks in let initialization closure of NSObject #50515
• [SR-8440] Using self inside a let initializer #50962

relates to:

• [SR-4138] Static properties are allowed to use without qualifier in initializer of instance property #46721

Issue Description:

This compiles because instance method `self` is accessible as a static member: `self`(_ self: TypeWithSelfMethod) -> () -> Void

func funcThatReturnsSomething(_ any: Any) -> Any {
    any
}

struct TypeWithSelfMethod {
    let property = self
    
    let propertyFromClosure: () = {
        print(self)
    }()
    
    let propertyFromFunc = funcThatReturnsSomething(self)
    
    func `self`() {
    }
}

This is particularly problematic as NSObject has a method with this name, so code to add target is compiling and doesn't refer to the self the user likely expects

import UIKit

class A: NSObject {

  private let control: UIControl = {
    let control = UIControl()
    control.addTarget(self, action: #selector(valueChanged), for: .valueChanged)
    return control
  }()

  @objc private func valueChanged() {
  }
}

[belkadan]

It looks like there's no actual loss of safety here, because self isn't actually the object being initialized. I'm not quite sure what it is, and we should fix this, but it's not doing what you think it is.

<stdin>:9:11: error: value of type '(NSObject) -> () -> A' has no member 'x'
    print(self.x)
          ^~~~ ~

[swift-ci]

Comment by Andrej (JIRA)

Consider the following example:

class Foo {

private let dimmingView: UIView = {
  let view = UIView();

  view.addGestureRecognizer(
    UITapGestureRecognizer(
      target: self, 
      action: #selector(handleBackdropTap(gestureRecognizer:))
    )
  )

  return view
}()

// ...

}

When you run this code you'll find that the view does have gesture recognizer added but its target is nil. This is highly misleading. I don't think Swift < 4 allowed this kind of behavior.

[nolanw]

There's more discussion at the closed-as-duplicate #47442

[typesanitizer]

Implementation notes from Slava and Pavel:

Approach 1: In contexts where self does not refer to an instance (i.e. outside of instance methods bodies and instance property bodies), references to the self method should be either qualified (so Foo.self) or the identifier is escaped with backticks (so `self`), otherwise, there is a warning. (say "self in a stored property initializer refers to the method NSObject.self, which may be unexpected" "add NSObject. to disable this warning" with fix-it). The best place to implement this is in PreCheckExpr.cpp, probably in resolveDeclRefExpr()

Approach 2: Implemented as a fix in constraint system, similar to AddQualifierToAccessTopLevelName that currently detects some forms of name shadowing. You'd likely have to implement a tailored fix for this situation and check all conversions from a function type to Any to make sure that function type doesn’t originate from an unapplied reference to member self on NSObject.

[swift-ci]

Comment by Jack March (JIRA)

Thanks a bunch theindigamer (JIRA User) for getting those notes! Went with approach 1 and made fix generic as isn't just for NSObject, it can also occur for any type that has/inherits a function called 'self'.

fix here #37992

[xedin]

Fixed by #37992 Please use next available snapshot of main branch to verify and close.

[keith]

I believe I found a case where this warning is invalid, I filed #57970

[keith]

Note that there is a swiftlint rule for many cases of this that you can enable now before the warning lands in swift 5.6 https://realm.github.io/SwiftLint/self_in_property_initialization.html