-
Notifications
You must be signed in to change notification settings - Fork 29
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
Emit SemanticDB types and signatures #126
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
23 tasks
Strum355
force-pushed
the
nsc/type-signatures
branch
from
March 23, 2021 13:01
80236bd
to
eb371de
Compare
olafurpg
reviewed
Mar 23, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is exciting progress! The implementation looks good to me. Just missing the pretty-printer before we can merge this. It's best to wait until the lsif-semanticdb PR is merged before we integrate the pretty-printer into LSIF hover messages
semanticdb-javac/src/main/java/com/sourcegraph/semanticdb_javac/SemanticdbSignatures.java
Outdated
Show resolved
Hide resolved
semanticdb-javac/src/main/java/com/sourcegraph/semanticdb_javac/SemanticdbVisitor.java
Outdated
Show resolved
Hide resolved
olafurpg
reviewed
Mar 23, 2021
semanticdb-javac/src/main/java/com/sourcegraph/semanticdb_javac/SemanticdbSignatures.java
Outdated
Show resolved
Hide resolved
olafurpg
reviewed
Mar 23, 2021
semanticdb-javac/src/main/java/com/sourcegraph/semanticdb_javac/SemanticdbSignatures.java
Outdated
Show resolved
Hide resolved
Strum355
force-pushed
the
nsc/type-signatures
branch
from
March 23, 2021 17:47
1972d62
to
51fa199
Compare
olafurpg
changed the title
emit types and signatures
Emit SemanticDB types and signatures
Mar 24, 2021
Strum355
force-pushed
the
nsc/type-signatures
branch
from
March 24, 2021 13:51
51fa199
to
9c9a706
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Emit Type and Signature messages for symbol occurrences.
With this information, we can reconstruct accurate hover signatures when converting from SemanticDB to LSIF.
Footnotes
Wildcard (existential) types proved most difficult to decipher. My work here is a combination of scalameta Javacp.scala file, the semanticdb spec ("Hardlinking comes in handy in situations when an advanced type such as ...
ExistentialType
") and this one table entry from the semanticdb spec (in which the params are the opposite way around):As wildcard params dont have a symbol emitting for them, I create a hardlink as opposed to a symlink in the declarations field of the existential type. In a mixed wildcard and non-wildcard scenario, the declarations ordering must be derived from the
ExistentialType.tpe.type_arguments
field, as in the case ofTriplet<?, String, ? extends Integer>
, the ordering of declarations would besymlink: "String", hardlinks: "local_wildcard", hardlinks: "local_wildcard"+upper_bound: "java/lang/Integer#"
. The relative ordering of symlinks to symlinks and hardlinks to hardlinks is preserved, just not symlinks to hardlinks and vice versa, so there should be no problem there.I had to do some guessing as to the behaviour when theres multiple wildcard type params for a given type (as is the case with e.g.
Map<?, ?>
), which isn't covered in the semanticdb spec, but this seems fairly sane.Decoded Protobuf
Link to Java source for below: https://github.com/sourcegraph/lsif-java/pull/126/files#diff-3f725eecc09c1818a18120a2d471018890dd664200b233dcbee8c14c650824aeR10