Skip to content

[SourceKit] add qualified types in type requests #61246

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

Merged
merged 2 commits into from
Oct 4, 2022

Conversation

skrtks
Copy link
Contributor

@skrtks skrtks commented Sep 22, 2022

This adds the fully qualified type to the response of expression and variable type requests in SourceKit.

The qualified type can be accessed through the <key.expression_qualified_type> and <key.variable_qualified_type> keys in the response of the expression and variable type requests.

@skrtks
Copy link
Contributor Author

skrtks commented Sep 22, 2022

@ahoppen do you perhaps know who would be the right person to ask as a reviewer here?

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me in general. A couple conceptual questions:

  • What’s the reason you went for a fully-qualified type instead of a USR? Is it because fully-qualified types are easier to parse than USRs?
  • I’m thinking whether sending back the fully-qualified types might blow up the response and if we should add an option to the request to control whether fully-qualified types are sent. I don’t have strong opinions either way but @rintaro might.

@skrtks
Copy link
Contributor Author

skrtks commented Sep 23, 2022

Thanks for the quick response!

What’s the reason you went for a fully-qualified type instead of a USR? Is it because fully-qualified types are easier to parse than USRs?

To give you some context, we would like to use this to improve Swift support in JetBrains IDE's. I considered the USR, but since we have everything in place for parsing type strings to our internal type representation, this seemed like the better option to me.

I’m thinking whether sending back the fully-qualified types might blow up the response and if we should add an option to the request to control whether fully-qualified types are sent. I don’t have strong opinions either way but @rintaro might.

I think adding this as an option would have been the better in the first place, so I'm open to updating it. But let's first see if @rintaro has any comments on this.

@rintaro
Copy link
Member

rintaro commented Sep 23, 2022

While it's true that this will more than double the size of the result, since duplicated type names are shared in the string buffer, I'm not too worried about the size of the response.

That being said, having a option would be great 👍

@skrtks skrtks force-pushed the SourceKit_qualified_types branch from f4a9e8d to 350f863 Compare September 27, 2022 14:45
@skrtks
Copy link
Contributor Author

skrtks commented Sep 27, 2022

I've updated the implementation so that it doesn't return the fully qualified type as an extra key anymore. Instead, the request option fully_qualified can be used to get the fully qualified type.

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. One suggestion to merge two test files.

@@ -0,0 +1,35 @@
let x: Int = 3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a copy of basic.swift, right? You could also just add another RUN: line to it with %FileCheck %s --check-prefix CHECK-FULLY-QUALIFIED

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is indeed, I was looking for a way to do this, but missed the custom prefix. Thanks for pointing it out!

@skrtks skrtks force-pushed the SourceKit_qualified_types branch from 350f863 to 1bd0d97 Compare September 29, 2022 09:01
@ahoppen
Copy link
Member

ahoppen commented Oct 4, 2022

@swift-ci Please smoke test

@ahoppen ahoppen merged commit 0ab44d5 into swiftlang:main Oct 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants