Prototyping TypeLambda and MatchType #1
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
To construct symbol table before referring the ParamRef it's required to traverse the child trees before registering the symbol.
Previously, there were the risks that localIdx receives the symbol that doens't have `span` because `TypeOps` generates dummy symbols for refinements in `RefinedType` and `RecType`. However, with the following commits, scala@7dd91ad scala@226e26f now we never generate dummy symbol in `TypeOps`. So re-insert the assertion we deleted when copying this method from `ExtractSemanticDB`. see: https://github.com/lampepfl/dotty/pull/12885/files#r658150249
For wildcard type `C[_ <: T]`, it's internal type representation will be `AppliedType(TypeBounds(lo = <Nothing>, hi = <T>))`. As scalameta for Scala2 does, we'll convert the wildcard type to `ExistentialType(TypeRef(NoPrefix, C, <local0>), Scope(hardlinks = List(<local0>)))` where `<local0>` has - display_name: "_" and, - signature: type_signature(..., lo = <Nothing>, hi = <T>) See: https://github.com/lampepfl/dotty/pull/12885/files#r663797616 https://scalameta.org/docs/semanticdb/specification.html#type-2 Now, when we compile the following Scala program to semanticdb ```scala class Wildcards { def e1: List[_ <: Int] = ??? } ``` The semanticdb's SymbolInformation for `e1` looks like: From scala3 ``` symbols { symbol: "advanced/Wildcards#e1()." kind: METHOD display_name: "e1" language: SCALA signature { value_signature { tpe { by_name_type { tpe { existential_type { tpe { type_ref { symbol: "scala/collection/immutable/List#" type_arguments { type_ref { symbol: "local0" } } } } declarations { hardlinks { symbol: "local0" kind: TYPE display_name: "_" language: SCALA signature { type_signature { type_parameters { } lower_bound { type_ref { symbol: "scala/Nothing#" } } upper_bound { type_ref { symbol: "scala/Int#" } } } } } } } } } } } } } ``` On the other hand, generated from scalameta's metac with scalac 2.13.6 ```sh $ metac --version Scala compiler version 2.13.6 -- Copyright 2002-2021, LAMP/EPFL and Lightbend, Inc. ``` ``` symbols { symbol: "advanced/Wildcards#e()." kind: METHOD display_name: "e" language: SCALA signature { method_signature { type_parameters { } return_type { existential_type { tpe { type_ref { symbol: "scala/package.List#" type_arguments { type_ref { symbol: "local0" } } } } declarations { hardlinks { symbol: "local0" kind: TYPE properties: 4 display_name: "_" language: SCALA signature { type_signature { type_parameters { } lower_bound { type_ref { symbol: "scala/Nothing#" } } upper_bound { type_ref { symbol: "scala/Int#" } } } } access { public_access { } } } } } } } } access { public_access { } } } ```
For example: `def foo(x: T)(y: T): T` and for `<y>.owner.info` would be like `MethodType(...<x>, resType = MethodType(...<y>, resType = <T>))`. (Let's say the outer `MethodType` "outer", and `MethodType` who is `resType` of outer "inner") Before this commit, we register <y> to the symbol table with `(<y>, outer)`, which should be `(<y>, inner)`. For such a nested method signature, we have to find the "actual" binder for parameters and register them to the symbol table.
When the prefix of SingleType is Type.Emtpy, we had been printing them as `<?>.sym.type`, but it should be `sym.type`
tanishiking
force-pushed
the
semanticdb-signature
branch
2 times, most recently
from
8fa0fb6 to
8e7e764
Compare
tanishiking
force-pushed
the
semanticdb-signature
branch
3 times, most recently
from
f51da32 to
056f4a4
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.
No description provided.