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-6572] Specialize ExtensionDeclSyntax in libSyntax Parsing #49122

Closed
nkcsgexi opened this issue Dec 11, 2017 · 2 comments
Closed

[SR-6572] Specialize ExtensionDeclSyntax in libSyntax Parsing #49122

nkcsgexi opened this issue Dec 11, 2017 · 2 comments
Labels
compiler The Swift compiler in itself declarations Feature: declarations extension Feature → declarations: `extension` declarations † libswiftSyntax † Area → compiler: the once-integrated C++ Syntax library succeeded by SwiftSyntax parser Area → compiler: The legacy C++ parser task

Comments

@nkcsgexi
Copy link
Member

Previous ID SR-6572
Radar None
Original Reporter @nkcsgexi
Type Task
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Source Tooling
Labels Task
Assignee sigito (JIRA)
Priority Medium

md5: 0c91fdc7ba3ed9ea78b10c4bea2ed8fd

Issue Description:

Currently, libSyntax parsing doesn't specialize extension declarations, meaning all extension declarations are manifested as UnkownDecl. Since libSyntax clients will very likely interested in specialized analysis on extensions. We need to teach the parser to specialize them.

To demo what we have now:

$cat ~/Desktop/test.swift
extension C{}
func foo() {}
$../build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift-syntax-test -input-source-filename ~/Desktop/test.swift -parse-gen -print-node-kind -print-trivial-node-kind
<SourceFile><DeclList><TopLevelCodeDecl><StmtList><DeclarationStmt><UnknownDecl>extension <SimpleTypeIdentifier>C</SimpleTypeIdentifier>{<DeclList></DeclList>}</UnknownDecl></DeclarationStmt><DeclarationStmt><FunctionDecl>
func foo<FunctionSignature>(<FunctionParameterList></FunctionParameterList>) </FunctionSignature><CodeBlock>{<StmtList></StmtList>}</CodeBlock></FunctionDecl></DeclarationStmt></StmtList></TopLevelCodeDecl></DeclList>
</SourceFile>

See that the function decl is specialized however the extension decl is not. The desirable feature will be having extension decls specialized as well. One can follow the patch we specialized struct declaration from: c4604d7
@swift-ci
Copy link
Collaborator

Comment by Yura Samsoniuk (JIRA)

I have noticed some differences in what libSyntax emits for structs and extensions:

  1. struct name is not parsed as a type, while extension has a defined type node (same is for a function, shouldn't foo in the example be part of the signature?);

  2. struct member list is additionally wrapped in MemberDeclList which includes braces + DeclList, while in extension braces are consumed as independent tokens.

Are these differences intentional? Should they be addressed as a part of this bug?

@swift-ci
Copy link
Collaborator

Comment by Yura Samsoniuk (JIRA)

Done in #13632

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis mentioned this issue Apr 5, 2023
Merged
@AnthonyLatsis AnthonyLatsis added compiler The Swift compiler in itself parser Area → compiler: The legacy C++ parser † libswiftSyntax † Area → compiler: the once-integrated C++ Syntax library succeeded by SwiftSyntax extension Feature → declarations: `extension` declarations declarations Feature: declarations labels Apr 5, 2023
@AnthonyLatsis AnthonyLatsis mentioned this issue Apr 5, 2023
Closed
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler The Swift compiler in itself declarations Feature: declarations extension Feature → declarations: `extension` declarations † libswiftSyntax † Area → compiler: the once-integrated C++ Syntax library succeeded by SwiftSyntax parser Area → compiler: The legacy C++ parser task
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nkcsgexi @swift-ci @AnthonyLatsis