Signature information in Semanticdb #12885

tanishiking · 2021-06-21T07:48:14Z

Related: #12766

This PR enables Scala3 to generate Signature information in Semanticdb. I have some questions for model some Scala3 types into Semanticdb types:

Future work? (in other PR)

Do not encode F[T][U] to F[T, U] (need extending SemanticDB).
- Signature information in Semanticdb #12885 (comment)
- Extend Signatures to have multiple type parameter clauses scalameta/scalameta#2450
Traverse the symbol from TypeTree
- Signature information in Semanticdb #12885 (comment)
- [SemanticDB] Fix missing symbol occurrence of type params' type bounds for constructor #13284
Nested annotation
- Signature information in Semanticdb #12885 (comment)
- [SemanticDB] Nested annotations are ignored in SemanticDB signatures #13291
Use StringBuilder in pprint?
- Signature information in Semanticdb #12885 (comment)
Support inline property
- Signature information in Semanticdb #12885 (comment)
- done [SemanticDB]Support new Scala3 modifiers in SemanticDB #13239
Support MatchType and LambdaType

TODO (in this PR)

Exclude wildcard types in an existential type
- Signature information in Semanticdb #12885 (comment)
Remove synthetic symbols from occurrences
- fd3b71c
- Add package object symbol to occurrences
  - 4f60d9f
- Add secondary constructor to occurrences
  - ba8140f
Generate fake symbol for refinements
- Signature information in Semanticdb #12885 (comment)

Overview

Generate Signature information for Types except MatchType and TypeLambda
- There might be some bugs though
Add pretty-printer for signature and update metac.expect
- Still, it's crappy... (might be better to just copy-and-paste from metap?)
Add test for Scala3 types
Support MatchType and TypeLambda (won't support in this PR)

Solved Questions

Can we retrieve declarations' symbols from RefinedType?

I'm trying to model RefinedType in Scala3 by StructuralType in Semanticdb. As StructuralType's declarations are modeled as Scope, I try to retrieve all the declarations' symbols of RefinedType.
For example, { def x: Int; def y: Int } in def m (x: {def x: Int; def y: Int}), we need the symbols for def x and def y.

In Scala2, RefinedTypes has their declarations as Scope directly, and therefore scalameta can convert them to Semanticdb Scope.

However, in Scala3, the information RefinedType have is only (declarations') type and names, and it doesn't have its declarations' symbols.

For example,
{ def x: Int; def y: Int } in def m (x: {def x: Int; def y: Int}) has the following type:

RefinedType(
  parent = RefinedType(
    parent = TypeRef(..., Object)
    ...
  ),
  refinedName = x,
  refinedInfo = TypeRef(..., Int)
)

Can we retrieve those symbols, from RefinedType?
- (tpe.member(tpe.refinedName) didn't work).
If it's impossible to reconstruct those symbols from RefinedType
- Is there a way to retrieve symbols for declarations, from the symbol (whose type is RefinedType)?
- If it's difficult, maybe we can retrieve those symbols from AST.

Reconstruct a symbol from `TypeParamRef` and `TermParamRef`

Trying to model TypeParamRef as TypeRef, for example:

def m[T]: T = ???

// `<def m>.info` is
PolyType(
    List(Z),
    List(TypeBounds(TypeRef(ThisType(TypeRef(NoPrefix,module class scala)),class Nothing),TypeRef(ThisType(TypeRef(NoPrefix,module class scala)),class Any))),
    TypeParamRef(Z)
)

// this should be modeled as
MethodSignature(
   ...
   returnType = TypeRef(..., Z)
)

Is there a way to retrieve the symbol (of Z in the above case) from TypeParamRef?
If not, I consider retrieving the symbol by sym.rawParamss and TypeParamRef#paramNum

Use metap?

To pretty-print the generated signature information in metac.expect which is printed by Tools#metac, we have to implement a Signature's pretty-printer in Scala3.
However, the pretty-printer is already implemented in scalameta's metap
Should we duplicate the pretty-printer in Scala3 for the testing? Or, another options: use metap for updating the metac.expect ?

tanishiking · 2021-06-21T07:54:14Z

@bishabosha @tgodzik Could you take a look at the questions?

compiler/src/dotty/tools/dotc/semanticdb/ExtractSemanticDB.scala

compiler/src/dotty/tools/dotc/semanticdb/SymbolInformationOps.scala

compiler/src/dotty/tools/dotc/semanticdb/SymbolOps.scala

bishabosha · 2021-06-21T09:55:27Z

However, the pretty-printer is already implemented in scalameta's metap
Should we duplicate the pretty-printer in Scala3 for the testing? Or, another options: use metap for updating the metac.expect ?

In this case we do not add dependencies to Scala compiler repos unless they are Java interfaces, so we reimplement printing in the Tools object, this can be extended for the symbol information

tanishiking · 2021-06-21T12:21:25Z

In this case we do not add dependencies to Scala compiler repos unless they are Java interfaces

I was thinking about installing metap CLI and somehow invoke it from SemanticDBTest, instead of adding a dependency to scalameta.

But I got second though it's still quite messy and we shouldn't do that, so never mind :)

scala#12885 (comment)

compiler/src/dotty/tools/dotc/semanticdb/Descriptor.scala

compiler/src/dotty/tools/dotc/semanticdb/SemanticSymbolBuilder.scala

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

tests/semanticdb/expect/Advanced.expect.scala

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala

tanishiking · 2021-06-24T18:48:50Z

@bishabosha @tgodzik
Could you take a look? (sorry it's gigantic...)
I think there's a lot of room for improvement, but I wanna make sure we're on the right track.

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

tgodzik · 2021-06-25T12:59:30Z

compiler/src/dotty/tools/dotc/semanticdb/ConstantOps.scala

+      case DoubleTag => s.DoubleConstant(const.doubleValue)
+      case StringTag => s.StringConstant(const.stringValue)
+      case NullTag => s.NullConstant()
+      // ConstantType(_: Type, ClazzTag) should be converted as it's type


Let're move these comments if they are not needed.

still could remove these comments

tgodzik

Looks pretty good! Great work! I think we need to figure out the issues with missing symbols for type refinements and also whether to actually copy the printer. Other than that, it all look ok and it's impossible to be sure about the tests 100%, since we got so many of those, but on first glance it looks correct.

We can always fix things later on and any changes will be much clearer now,.

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

tanishiking · 2021-06-29T09:26:10Z

The previous approach didn't work (couldn't resolve the TypeParamRef and TermParamRef) for the types something like type X[T] = List[T] (which is equivalent with type X = [T] =>> List[T], because in this case the sym.rawparamss and sym.paramSymss are empty.

We might resolve the symbol of the TypeParamRef and TermParamRef by

traverse the children tree first, create symbol table Map[(LambdaType, Name), Symbol]
then the signatures that contain TypeParamRef and ParamRef, we can resolve those symbols by looking up the symbol table.

We could apply this approach (traverse children first and construct symbol table) to RefinedType and RecTypes.

compiler/src/dotty/tools/dotc/semanticdb/ExtractSemanticDB.scala

tanishiking · 2021-06-29T14:54:26Z

@bishabosha @tgodzik
Hey, I think I successfully filled the symbols for RefinedType (and did some bugfixes for LambdaTypes) 🎉 Could you take a look?
I wrote a small piece of explanation on #12885 (comment) but I think it's complicated, and if you need more information, let me know :)

bishabosha · 2021-06-29T15:29:20Z

@bishabosha @tgodzik
Hey, I think I successfully filled the symbols for RefinedType (and did some bugfixes for LambdaTypes) 🎉 Could you take a look?
I wrote a small piece of explanation on #12885 (comment) but I think it's complicated, and if you need more information, let me know :)

Hey, I intend to take a look tomorrow

tgodzik

Great work! I need to still look a bit more into TyeOps, but it looks pretty amazing!

compiler/src/dotty/tools/dotc/semanticdb/Scala3.scala

tgodzik · 2021-06-30T15:53:51Z

compiler/src/dotty/tools/dotc/semanticdb/Scala3.scala

+        else if sym.isTerm && sym.owner.isTerm then
+          SymbolInformation.Kind.LOCAL
+        else if sym.isInlineMethod || sym.is(Macro) then
+          SymbolInformation.Kind.MACRO


Should we have an additional kind for inline ? We might need to update the modifiers in semanticdb. Also, should we recognize inline methods as macros? @bishabosha what do you think?

I think it could be good to have a new Inline kind, and possibly TransparentInline TransparentMacro (due to the different semantics) but maybe they should be properties?

@tanishiking maybe let's add this together with TypeLambda and MatchType PR?

compiler/src/dotty/tools/dotc/semanticdb/Scala3.scala

compiler/src/dotty/tools/dotc/semanticdb/SemanticSymbolBuilder.scala

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

tgodzik · 2021-07-01T14:00:34Z

tests/semanticdb/expect/recursion.expect.scala

@@ -21,5 +21,5 @@ object Nats/*<-recursion::Nats.*/ {
      case Succ/*->recursion::Nats.Succ.*//*->recursion::Nats.Succ.unapply().*//*->local2*/(p/*<-local3*/) => toIntg/*->recursion::Nats.toIntg().*/(p/*->local3*/) +/*->scala::Int#`+`(+4).*/ 1
    }

-  val j31/*<-recursion::Nats.j31.*/ = toIntg/*->recursion::Nats.toIntg().*/(Zero/*->recursion::Nats.Zero.*/.++.++.++/*<-local4*//*->recursion::Nats.Zero.*//*->recursion::Nats.Nat#`++`().*/ + /*<-local5*//*->recursion::Nats.Nat#`++`().*/Zer/*<-local6*//*->recursion::Nats.Nat#`++`().*//*->recursion::Nats.Nat#`+`().*/o/*->recursion::Nats.Zero.*/.++/*->recursion::Nats.Nat#`++`().*/)
+  val j31/*<-recursion::Nats.j31.*/ = toIntg/*->recursion::Nats.toIntg().*/(Zero/*->recursion::Nats.Zero.*/./*->recursion::Nats.Zero.*/++.++.++/*<-local4*//*->recursion::Nats.Nat#`++`().*/ + /*<-local5*//*->recursion::Nats.Nat#`++`().*/Zer/*<-local6*//*->recursion::Nats.Nat#`++`().*//*->recursion::Nats.Nat#`+`().*/o/*->recursion::Nats.Zero.*/.++/*->recursion::Nats.Nat#`++`().*/)


This change looks weird, we get double occurrence of Zero here. Though, it's probably unrelated, but we might want to raise an issue for the future.

this looks to be because of the inlining, if I change from transparent inline to inline, then there is no repetition (also need to add "-Ystop-after:extractSemanticDB" to the compiler args in SemanticdbTests)

bishabosha

I still have more to look over, thank you for your efforts so far!

compiler/src/dotty/tools/dotc/semanticdb/Scala3.scala

compiler/src/dotty/tools/dotc/semanticdb/SemanticSymbolBuilder.scala

bishabosha · 2021-07-02T14:43:59Z

compiler/src/dotty/tools/dotc/semanticdb/Tools.scala

-    sb.append(info.displayName).nl
-  end processSymbol
+  private def processSymbol(info: SymbolInformation, printer: SymbolInfomationPrinter)(using sb: StringBuilder): Unit =
+    sb.append(printer.pprintSymbolInformation(info)).nl


we can pass in sb to pprintSymbolInformation here for more efficiency

Should we much priority on string concatenation efficiency?

I personally prefer returning String instead of passing StringBuilder (because of its code readability).

While I understand StringBuilder concatenation is generally faster, this pretty printer is used only for testing and the efficiency might be not a big deal?

btw, what do you think about this approach? Signature information in Semanticdb #12885 (comment)

Its true the efficiency is not the priority before the correctness of the actual output, so this would only be the last thing to address.

I have addressed that other comment now.

bishabosha · 2021-07-02T14:46:00Z

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala

+  val notes = InfoNotes()
+  val infoPrinter = InfoPrinter(notes)
+
+  def pprintSymbolInformation(info: SymbolInformation): String =


we should try to reuse the current StringBuilder by passing it in as an argument, then either return the StringBuilder or Unit

@tanishiking what about this comment? We could reuse the sam StringBuilder everywhere.

bishabosha · 2021-07-02T14:48:20Z

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala

+  class InfoPrinter(notes: InfoNotes) {
+    private enum SymbolStyle:
+      case Reference, Definition
+    def pprint(info: SymbolInformation): String =


again would be good to try and reuse StringBuilder where possible

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala

compiler/src/dotty/tools/dotc/semanticdb/SemanticSymbolBuilder.scala

tests/semanticdb/expect/Local.expect.scala

bishabosha · 2021-07-05T12:14:07Z

tests/semanticdb/expect/recursion.expect.scala

@@ -21,5 +21,5 @@ object Nats/*<-recursion::Nats.*/ {
      case Succ/*->recursion::Nats.Succ.*//*->recursion::Nats.Succ.unapply().*//*->local2*/(p/*<-local3*/) => toIntg/*->recursion::Nats.toIntg().*/(p/*->local3*/) +/*->scala::Int#`+`(+4).*/ 1
    }

-  val j31/*<-recursion::Nats.j31.*/ = toIntg/*->recursion::Nats.toIntg().*/(Zero/*->recursion::Nats.Zero.*/.++.++.++/*<-local4*//*->recursion::Nats.Zero.*//*->recursion::Nats.Nat#`++`().*/ + /*<-local5*//*->recursion::Nats.Nat#`++`().*/Zer/*<-local6*//*->recursion::Nats.Nat#`++`().*//*->recursion::Nats.Nat#`+`().*/o/*->recursion::Nats.Zero.*/.++/*->recursion::Nats.Nat#`++`().*/)
+  val j31/*<-recursion::Nats.j31.*/ = toIntg/*->recursion::Nats.toIntg().*/(Zero/*->recursion::Nats.Zero.*/./*->recursion::Nats.Zero.*/++.++.++/*<-local4*//*->recursion::Nats.Nat#`++`().*/ + /*<-local5*//*->recursion::Nats.Nat#`++`().*/Zer/*<-local6*//*->recursion::Nats.Nat#`++`().*//*->recursion::Nats.Nat#`+`().*/o/*->recursion::Nats.Zero.*/.++/*->recursion::Nats.Nat#`++`().*/)


this looks to be because of the inlining, if I change from transparent inline to inline, then there is no repetition (also need to add "-Ystop-after:extractSemanticDB" to the compiler args in SemanticdbTests)

tests/semanticdb/metac.expect

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

tests/semanticdb/metac.expect

bishabosha · 2021-07-05T15:12:42Z

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

+          val sargs = args.map(loop)
+          loop(tycon) match
+            case ref: s.TypeRef => ref.copy(typeArguments = sargs)
+            // is there any other cases?


We can have curried type application with type lambdas so we need to support that, instead of just replacing the previously applied type arguments

You mean something like def x[T](a: T): ([X] =>> List[X])[T] = ??? ?
For type lambdas, it looks in this phase, what we will have is just an already applied type: e.g. List[T] in the above example. There might be another type than TypeRef here, but I couldn't find the example...

here is an example I use to test the Scala 2 TASTy unpickler:

class HKClass[F <: [T] =>> [U] =>> (U, T)] { def foo[T,U](x: F[T][U]): String = x.toString() }

fixed 26fc7ca

bishabosha · 2021-07-05T15:14:13Z

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

+
+        case ann: AnnotatedType if ann.annot.symbol.info.isInstanceOf[ClassInfo] =>
+          def flatten(tpe: Type, annots: List[Annotation]): (Type, List[Annotation]) = tpe match
+            case AnnotatedType(parent, annot) if annot.symbol.info.isInstanceOf[ClassInfo] =>


might want to be careful of type aliases used as annotations here, which won't have ClassInfo as their info, maybe annot.symbol takes care of this

Judging from the Annotations.symbol https://github.com/lampepfl/dotty/blob/601184787508d8fd655f1dc4e48ed19c418fa710/compiler/src/dotty/tools/dotc/core/Annotations.scala#L13-L15 I guess we can expect there should only be ClassInfo.
Since I tried but couldn't find a counter-example for this, maybe we can go with it, and fix it in the future when we find a example here.

I confirmed with testing it does not matter if the type is aliased, however it does not work for nested annotated types, e.g.

// tests/semanticdb/expect/InstrumentTyper.scala type paramAlias = param type paramRec = param @param type AnnotatedType = Int @param type AnnotatedType2 = Int @paramAlias type AnnotatedType3 = Int @(param @param) type AnnotatedType4 = Int @paramRec

In these cases AnnotatedType<3|4> info is Int @param but scala 2 would have Int @param @param

I believe this still needs resolving

bishabosha · 2021-07-05T15:21:33Z

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala

+                enterRefined(expr.resType)
+              case m: MethodType =>
+                enterRefined(m.resType)
+              case _ => ()


maybe missing PolyType here?

As far as I know, PolyType shouldn't appear here as long as they're handled by toSemanticSig (at least I confirmed there're no appearance in semanticdb/expect) (and actually I'm not sure how to convert PolyType into SemanticDB types, if there exists).

see my comment here #12885 (comment)
Edit: it does not seem to help by adding PolyType here, but still something is up

Because there could be an unexpected types for incompilable sources and if we show the warning for uncompilable sources, it could be confusing.

see: scala#12885 (comment) scala#12885 (comment)

tanishiking · 2021-08-10T19:12:53Z

Rebased and then removed the merge commits 👍

bishabosha · 2021-08-11T01:04:38Z

test performance please

dottybot · 2021-08-11T01:05:58Z

performance test scheduled: 1 job(s) in queue, 0 running.

dottybot · 2021-08-11T02:16:20Z

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/12885/ to see the changes.

Benchmarks is based on merging with master (38b983c)

Reset local symbol index for each TextDocument, updateExpect PrettyPrint signature and update metac.expect Integrate SymbolInformationOps into Scala3#SymbolOps Model WithType for AndType scala#12885 (comment) Resolve ParamRef by constructing SymbolTable To construct symbol table before referring the ParamRef it's required to traverse the child trees before registering the symbol. Lookup symbols for refinements in RefinedType and RecType Re-insert assertion to localIdx 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 Convert AndType to IntersectionType Refactor enterRefined Refactor: move all extension (of Symbol) method into Scala3 Don't add type parameters as parameters to MethodSignature Refactor not to use isInstanceOf for designator of TypeRef and TermRef Use intersection type for the parent of RefinedType Convert wildcard type as ExistentialType 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 { } } } ``` Use finalResultType for MethodSignature to get actual return type. Register the symbol of nested method with "actual" binder 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. Remove unused parameter sym from toSemanticType Fix pprint issue for SingleType When the prefix of SingleType is Type.Emtpy, we had been printing them as `<?>.sym.type`, but it should be `sym.type` Convert symbols to local index for funParamSymbol Refactor style of if Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com> Fix printing upper type bounds Add evidence params to SemanticDB Add refinements to RefinedType generated by opaque types Fix empty refinement for RefinedType for the result of polymorphic method Print definition of ExistentialType instead of displaySymbol Update comment Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com> None for empty decls Warn if symbol lookup failed for paramRef and RefinedType Workaround symbol not found for higher kinded type param Suppress warning for known issue of exporting Polymorphic type Support multiple type param clauses for extension method By combining two type param clause into one Exclude synthetic symbols from occurrences Fallback to Type.member for refinements who can't access to the tree For example, ```scala trait SpecialRefinement { def pickOne(as: String*): Option[Any] } class PickOneRefinement_1[S <: SpecialRefinement { def pickOne(as: String*): Option[String] }] { def run(s: S, as: String*): Option[String] = s.pickOne(as:_*) } ``` In the typed AST, the SpecialRefinement is inside of the TypeTree and cannot access to the refinement (pickOne) from tree, therefore we can't register the symbol of pickOne to symbol table. In this case, fallback to `Type.member` to find the symbol of `pickOne`. Fallback to Type.member for ParamRef Workaround symbol not found for HKTypeLambda in upper bounds and fix type for curried applied type Remove unnecessary comment Do not create newSymbol for wildcard type symbol instead, create a proxy data that will be converted to semanticdb symbol who represents wildcard symbol Warn if unexpected type appear while converting type to SemanticDB type Dealias LazyRef while converting types to SemanticDB Do not emit warning for unexpected type Because there could be an unexpected types for incompilable sources and if we show the warning for uncompilable sources, it could be confusing. Do not create a newSymbol for ParamRef Make wildcard type symbol global Hardlink fake symbols Excude symbols that doesn't present in source from occurrence Make namePresenInSource safe for IndexOutOfRange Make package objects present in source Fallback to fake symbol for refinements in RefinedType of upper bound see: scala#12885 (comment) scala#12885 (comment) Add occurrences of secondary constructors Add fakeSymbols to symbol section and don't hardlink fake syms Convert tp <:< FromJavaObject to tp <:< Any Do not add wildcard symbol of existential type to symbol section Refactor styles

tanishiking commented Jun 21, 2021

View reviewed changes

compiler/src/dotty/tools/dotc/semanticdb/ExtractSemanticDB.scala Show resolved Hide resolved

bishabosha reviewed Jun 21, 2021

View reviewed changes

tanishiking force-pushed the semanticdb-signature branch from a46e4c7 to 9c6015e Compare June 24, 2021 14:34

tanishiking added a commit to tanishiking/scala3 that referenced this pull request Jun 24, 2021

Model WithType for AndType

de36d34

scala#12885 (comment)

tanishiking commented Jun 24, 2021

View reviewed changes

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala Show resolved Hide resolved

tanishiking changed the title ~~[WIP] Signature information in Semanticdb~~ Signature information in Semanticdb Jun 24, 2021

tanishiking marked this pull request as ready for review June 24, 2021 18:39

tgodzik reviewed Jun 25, 2021

View reviewed changes

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala Outdated Show resolved Hide resolved

bishabosha self-requested a review June 25, 2021 13:21

bishabosha self-assigned this Jun 25, 2021

tgodzik reviewed Jun 25, 2021

View reviewed changes

compiler/src/dotty/tools/dotc/semanticdb/PPrint.scala Show resolved Hide resolved

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala Outdated Show resolved Hide resolved

tanishiking commented Jun 29, 2021

View reviewed changes

compiler/src/dotty/tools/dotc/semanticdb/ExtractSemanticDB.scala Show resolved Hide resolved

tanishiking mentioned this pull request Jun 29, 2021

Add access information to SymbolInformation #12964

Merged

tanishiking mentioned this pull request Jul 1, 2021

[Scala3] Proposal to add new Scala3 Types: TypeLambda and MatchType scalameta/scalameta#2403

Closed

tgodzik requested changes Jul 1, 2021

View reviewed changes

bishabosha reviewed Jul 2, 2021

View reviewed changes

compiler/src/dotty/tools/dotc/semanticdb/TypeOps.scala Outdated Show resolved Hide resolved

bishabosha added the area:semanticdb label Jul 5, 2021

bishabosha reviewed Jul 5, 2021

View reviewed changes

tanishiking added 14 commits August 11, 2021 04:06

Dealias LazyRef while converting types to SemanticDB

326e43e

Do not emit warning for unexpected type

9f0063d

Because there could be an unexpected types for incompilable sources and if we show the warning for uncompilable sources, it could be confusing.

Do not create a newSymbol for ParamRef

45c8cc1

Make wildcard type symbol global

fd75b36

Hardlink fake symbols

4e97e76

Excude symbols that doesn't present in source from occurrence

fef5be0

Make namePresenInSource safe for IndexOutOfRange

adae1ff

Make package objects present in source

c3bd0d5

Fallback to fake symbol for refinements in RefinedType of upper bound

0e3c8ad

see: scala#12885 (comment) scala#12885 (comment)

Add occurrences of secondary constructors

c3548a1

Add fakeSymbols to symbol section and don't hardlink fake syms

4af72b9

Convert tp <:< FromJavaObject to tp <:< Any

d9838df

Do not add wildcard symbol of existential type to symbol section

a82605f

Refactor styles

056f4a4

tanishiking force-pushed the semanticdb-signature branch from f51da32 to 056f4a4 Compare August 10, 2021 19:09

bishabosha approved these changes Aug 11, 2021

View reviewed changes

tanishiking mentioned this pull request Aug 11, 2021

Add context / implicit params to synthetics #13279

Closed

tgodzik mentioned this pull request Aug 12, 2021

Test semanticdb performance #13285

Closed

tgodzik merged commit 6e7299e into scala:master Aug 12, 2021

tgodzik mentioned this pull request Aug 18, 2021

go to implementation not working for Scala 3 scalameta/metals#1706

Closed

Kordyjan added this to the 3.1.0 milestone Aug 2, 2023

Signature information in Semanticdb #12885

Signature information in Semanticdb #12885

Conversation

tanishiking commented Jun 21, 2021 • edited Loading

Future work? (in other PR)

TODO (in this PR)

Overview

Can we retrieve declarations' symbols from RefinedType?

Reconstruct a symbol from TypeParamRef and TermParamRef

Use metap?

tanishiking commented Jun 21, 2021

bishabosha commented Jun 21, 2021

tanishiking commented Jun 21, 2021 • edited Loading

tanishiking commented Jun 24, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tgodzik left a comment

Choose a reason for hiding this comment

tanishiking commented Jun 29, 2021

tanishiking commented Jun 29, 2021

bishabosha commented Jun 29, 2021

tgodzik left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bishabosha left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bishabosha Jul 7, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bishabosha Jul 7, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bishabosha Jul 7, 2021 • edited Loading

Choose a reason for hiding this comment

tanishiking commented Aug 10, 2021

bishabosha commented Aug 11, 2021

dottybot commented Aug 11, 2021

dottybot commented Aug 11, 2021

tanishiking commented Jun 21, 2021 •

edited

Loading

Reconstruct a symbol from `TypeParamRef` and `TermParamRef`

tanishiking commented Jun 21, 2021 •

edited

Loading

bishabosha Jul 7, 2021 •

edited

Loading

bishabosha Jul 7, 2021 •

edited

Loading

bishabosha Jul 7, 2021 •

edited

Loading