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-48] Create warning for missing self in lazy var initialization #42671

Closed
swift-ci opened this issue Dec 4, 2015 · 4 comments
Closed

[SR-48] Create warning for missing self in lazy var initialization #42671

swift-ci opened this issue Dec 4, 2015 · 4 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Dec 4, 2015

Previous ID SR-48
Radar rdar://22067698
Original Reporter hagi (JIRA User)
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

Verified with Apple Swift version 2.1.1 and Apple Swift version 2.2-dev
OS X 10.11.1 (15B42). Requires Foundation framework and ObjC runtime.

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @slavapestov
Priority Medium

md5: 484aa387c639f336a3aed7547f1776b1

is duplicated by:

  • SR-484 Bad error message for lazy var

relates to:

  • SR-484 Bad error message for lazy var
  • SR-2203 Implicit self doesn't work in initializer of lazy var
  • SR-4663 Bad diagnostic when missing explicit type in lazy property declaration

Issue Description:

Usually, when `self` is missing from a call within a closure, a warning is generated (unless you explicitly capture `self`). This generally holds true for closures used to initialize lazy variables.

However, I've found that some methods (possible `objc`-related) don't require `self` to compile without warnings, but they don't work as expected either, which leads to bugs that are really easy to miss and a pain to find. It would be great to have warnings in these cases.

Steps to Reproduce:
Please see the file attached. On OS X, you can just run `swift lazy_block.swift` in the Terminal (from the respective directory).

Please read the comments in the file, too.

Expected Results:
The naive expectation when I encountered the bug was that `respondsToSelector` (line 16) would be called on the instance and return `true` (but it returns `false`).

The correct expectation should be a warning/error in that line, and possibly a fix-it, leading to what I've written in line 22 (which does return/print `true`).

Actual Results:
No warning/error, but `respondsToSelector` does not return the expected result.

Notes:
This problem does not seem to occur in normal closures (see lines 51 ff). I could only reproduce this in lazy variable initializations.

This has been filed as a radar before, but I think this bug tracker offers a better chance of getting attention from the Swift team or the general community. For reference: rdar://22067698. The example has been updated/simplified, so please prefer this bug report over the radar.

@swift-ci
Copy link
Collaborator Author

Comment by Sebastian Hagedorn (JIRA)

I've verified that this is still as issue in the latest dev snapshot (Swift 3.0, January 25, 2016).

@rintaro
Copy link
Mannequin

rintaro mannequin commented Jun 29, 2016

It seems, this is because Lazy.self class object have respondsToSelector method.

Lazy.self is NSObjectProtocol is true

@slavapestov
Copy link
Member

#9920

@swift-ci
Copy link
Collaborator Author

Comment by Sebastian Hagedorn (JIRA)

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
Projects
None yet
Development

No branches or pull requests

2 participants