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-13619] Using SwiftSyntax to parse a definition file, results in unknown declarations #403

Open
swift-ci opened this issue Sep 27, 2020 · 5 comments
Labels
bug

Comments

@swift-ci
Copy link
Contributor

@swift-ci swift-ci commented Sep 27, 2020

Previous ID SR-13619
Radar rdar://problem/69701608
Original Reporter swiftuilab (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s SwiftSyntax
Labels Bug
Assignee None
Priority Medium

md5: 57f6cbe2a43f7ef6bb506bf778d15230

Issue Description:

Not sure if this is a bug, or a feature request, so I'm filing it as a bug for the moment.

I am using SwiftSyntax to parse a definition file (to be clear, I'm talking about the file generated by Xcode when you right click on a symbol and select "jump to definition").

For example, a stripped-down piece of the SwiftUI definition file looks like this:

public struct Binding<Value> {
  public var wrappedValue: Value { get nonmutating set }
  public var projectedValue: Binding<Value> { get }
}

The projectedValue variable is properly parsed as VariableDeclSyntax, but wrappedValue is parsed as UnknownDeclSyntax. The "set" part is what makes SwiftSyntax to not detect a variable.

This makes sense in a way, as that is not a valid syntax to use while writing code. However, in the context of the definition file it is ok. The color coding in Xcode also provides a hint, as the "nonmutating set" shows uncolored.

I tried to dig a little more, but I think the problem (if it is such), resides in the lib_InternalSwiftSyntaxParser.dylib library.

@typesanitizer
Copy link

@typesanitizer typesanitizer commented Sep 28, 2020

@swift-ci create

@akyrtzi
Copy link
Member

@akyrtzi akyrtzi commented Sep 30, 2020

As you also pointed out the interface generation source output is not valid syntax, it is intended for displaying-to-the-user purposes, not for consumption by tools.

Could you clarify what exactly you are trying to achieve? We may be able to point you to another direction.

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Sep 30, 2020

Comment by Javier (JIRA)

Thanks Argyrios. Yes you're right, that's why I was hesitant to catalog the issue as a bug. I work on the documentation of a framework (SwiftUI). I use SwiftSyntax to extract every method, property, initializer and protocol from the SwiftUI definition file generated by Xcode, in order to create the Table of Contents of my documentation.

This is not a big issue for me. To work around it, previous to parsing, I automatically edit the definition file and change all occurrences of:

{ get nonmutating set }

with

{ get /* nonmutating set */ }

@akyrtzi
Copy link
Member

@akyrtzi akyrtzi commented Oct 2, 2020

You should find useful the `swift-symbolgraph-extract` tool, part of Xcode 12/swift 5.3 toolchain. It outputs a json file that describes the API and documentation of a module. See a possible use for it in jazzy: realm/jazzy#1171

Feel free to ask questions about it in the forums.

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Oct 3, 2020

Comment by Javier (JIRA)

Thanks a lot for the pointer, that did not exist when I originally implemented my solution using SwiftSyntax. I performed a quick test and it looks promising (although a lot, lot, lot slower). I'll keep it in mind for a future rewrite of my extractor. For the time being, I'll keep using SwiftSyntax. The only unknown declarations I get are those mentioned, but they can be easily workaround. Thanks again for your help!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug
Projects
None yet
Development

No branches or pull requests

4 participants