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

Jump to bottom

[SR-13120] SourceKit syntaxMap doesn't contain info about trailing closure initializers #55566

Open
keith opened this issue Jun 30, 2020 · 4 comments
Open

[SR-13120] SourceKit syntaxMap doesn't contain info about trailing closure initializers #55566

keith opened this issue Jun 30, 2020 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@keith
Copy link
Collaborator

keith commented Jun 30, 2020

Previous ID SR-13120
Radar rdar://problem/64953104
Original Reporter @keith
Type Bug
Additional Detail from JIRA
Votes 1
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 19a40d4187b72eb310669862da7d3a83

Issue Description:

With this code:

extension String {
    init(foo: () -> Void) {
        self = ""
    }
}

_ = String {}

If you do a `source.request.editor.open` request the last token the syntax map contains is the reference to `String`, not it's initializer that is implicit here. If you change the code to `String(foo: {})` it ends up in the syntax map.

I was testing with `{ key.request: source.request.editor.open, key.sourcefile: "/tmp/bar.swift", key.name: "/tmp/bar.swift"}` in the sourcekitd-repl.

In SwiftLint we use the tokens in the syntax map to do individual cursorinfo requests to determine which module a token is defined it, so if it doesn't appear in the syntax map, we don't check it. I'm not sure if it's expected for this to show up there or not. In the meantime, similar to operators, we can get this info from the index requests, but I wanted to flag in case this was unexpected.
@typesanitizer
Copy link

@swift-ci create

@keith
Copy link
Collaborator Author

keith commented Jun 30, 2020

So I think related to this you can't actually get cursorinfo for the initializer at the callsite in this case. If you attempt to retrieve the info anywhere on the word 'String' it returns the type, and on the brackets it fails.

@akyrtzi
Copy link
Member

akyrtzi commented Jul 1, 2020

> you can't actually get cursorinfo for the initializer at the callsite in this case

Could you file a separate Jira for this? I think we should enhance cursor-info to provide additional symbol resolutions, e.g. pointing at the typename should give you the type symbol and the initializer symbol as additional interpretation.

For the syntactic stuff I'd really recommend to look into using SwiftSyntax, which was designed to provide full source fidelity.

@keith
Copy link
Collaborator Author

keith commented Jul 4, 2020

Filed a separate JIRA here https://bugs.swift.org/browse/SR-13140

For this use case in SwiftLint use case https://github.com/realm/SwiftLint/blob/075312af6e8b2ac527a02a725a51e55f65816a0f/Source/SwiftLintFramework/Rules/Lint/UnusedImportRule.swift#L150-L179 it uses the syntax map to determine what it should call cursorinfo for to get the module of each offset. Not sure if the general idea there is directly translatable to some SwiftSyntax API, but last I heard this was the blocker from moving to that https://www.jpsim.com/evaluating-swiftsyntax-for-use-in-swiftlint/

@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
No one assigned
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
@akyrtzi @keith @typesanitizer