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.

Sign up for GitHub

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

Jump to bottom

[SR-9777] SourceKit's 'editor open' request not returning correct accessibility value in Swift 5 #52203

Open
jpsim opened this issue Jan 28, 2019 · 3 comments
Open

[SR-9777] SourceKit's 'editor open' request not returning correct accessibility value in Swift 5 #52203

jpsim opened this issue Jan 28, 2019 · 3 comments
Assignees
@akyrtzi
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@jpsim
Copy link
Contributor

jpsim commented Jan 28, 2019

Previous ID SR-9777
Radar None
Original Reporter @jpsim
Type Bug
Additional Detail from JIRA
Votes 1
Component/s Source Tooling
Labels Bug
Assignee @akyrtzi
Priority Medium

md5: c83ce94350f84a6accca1bec8eed73bc

Issue Description:

For instance members of a private type with no explicit ACL annotation, SourceKit from Swift 4.x correctly inferred an ACL of private.

SourceKit from the Swift 5 preview included in Xcode 10.2 beta 1 incorrectly infers an ACL of internal.

I believe this to be a regression in Swift 5 compared to Swift 4.2.1 (and versions going back quite a bit, at least to 4.0 if not earlier).

Note that I'm just using 3rd party tools like SourceKitten and jq to simplify this demonstration, this problem is present without them.

$ cat file.swift
private class Foo {
  func bar() {}
}
$ cat request.yml
key.request: source.request.editor.open
key.name: "/tmp/SR-9777/file.swift"
key.sourcefile: "/tmp/SR-9777/file.swift"
$ brew install sourcekitten
$ DEVELOPER_DIR=/Applications/Xcode-10.1.app/Contents/Developer sourcekitten request --yaml request.yml | jq '."key.substructure"'
[
  {
    "key.accessibility": "source.lang.swift.accessibility.private",
    "key.attributes": [
      {
        "key.attribute": "source.decl.attribute.private",
        "key.length": 7,
        "key.offset": 0
      }
    ],
    "key.bodylength": 17,
    "key.bodyoffset": 19,
    "key.kind": "source.lang.swift.decl.class",
    "key.length": 29,
    "key.name": "Foo",
    "key.namelength": 3,
    "key.nameoffset": 14,
    "key.offset": 8,
    "key.runtime_name": "_TtC4main3Foo",
    "key.substructure": [
      {
        "key.accessibility": "source.lang.swift.accessibility.private",
        "key.bodylength": 0,
        "key.bodyoffset": 34,
        "key.kind": "source.lang.swift.decl.function.method.instance",
        "key.length": 13,
        "key.name": "bar()",
        "key.namelength": 5,
        "key.nameoffset": 27,
        "key.offset": 22
      }
    ]
  }
]
$ DEVELOPER_DIR=/Applications/Xcode-10.2.app/Contents/Developer sourcekitten request --yaml request.yml | jq '."key.substructure"'
[
  {
    "key.accessibility": "source.lang.swift.accessibility.private",
    "key.attributes": [
      {
        "key.attribute": "source.decl.attribute.private",
        "key.length": 7,
        "key.offset": 0
      }
    ],
    "key.bodylength": 17,
    "key.bodyoffset": 19,
    "key.kind": "source.lang.swift.decl.class",
    "key.length": 29,
    "key.name": "Foo",
    "key.namelength": 3,
    "key.nameoffset": 14,
    "key.offset": 8,
    "key.runtime_name": "_TtC4mainP33_DC7C78BA85A59EC6A4D8097C64295BD73Foo",
    "key.substructure": [
      {
        "key.accessibility": "source.lang.swift.accessibility.internal",
        "key.bodylength": 0,
        "key.bodyoffset": 34,
        "key.kind": "source.lang.swift.decl.function.method.instance",
        "key.length": 13,
        "key.name": "bar()",
        "key.namelength": 5,
        "key.nameoffset": 27,
        "key.offset": 22
      }
    ]
  }
]
@marcelofabri
Copy link
Contributor

This also happens on the latest 5.0 and master snapshots.

@belkadan
Copy link
Contributor

Technically internal is correct according to SE-0025, but I agree it's not necessarily the most useful answer.

@jpsim
Copy link
Contributor Author

jpsim commented Jan 28, 2019

Ah, very interesting @belkadan, I hadn't seen this paragraph from SE-0025:

The compiler should not warn when a broader level of access control is used within a type with more restrictive access, such as internal within a private type. This allows the designer of the type to select the access they would use were they to make the type more widely accessible. (The members still cannot be accessed outside the enclosing lexical scope because the type itself is still restricted, i.e. outside code will never encounter a value of that type.)

Thanks for sharing! Seems like the effective visibility of those declarations is actually fileprivate however, which is what I would expect SourceKit to return.

Though I just noticed that members with an inferred ACL don't have a "key.attribute": "source.decl.attribute.private" so I think we can leverage this as a workaround for realm/SwiftLint#2607 .

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@akyrtzi akyrtzi

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jpsim @belkadan @marcelofabri