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

[SemanticDB] Support TypeApply Synthetic #13481

Merged
merged 1 commit into from Nov 24, 2021

Conversation

tanishiking
Copy link
Member

#13135

This PR adds support Inferred Type Application to Synthetic. See https://scalameta.org/docs/semanticdb/specification.html#synthetic-1

val lst = List(1)
lst.map(_ + 2)

// synthetic
val lst = List.apply[Int](1)
lst.map[Int](_ + 2)

Synthetic(
  <List>,
  TypeApplyTree(
    SelectTree(
      OriginalTree(<List>),
      IdTree(<apply>)
    ),
    List(TypeRef(None, <Int>, List()))
  )
)
Synthetic(
  <lst.map>,
  TypeApplyTree(
    OriginalTree(<lst.map>),
    List(TypeRef(None, <Int>, List()))
  ))

@@ -3302,6 +3380,15 @@ Occurrences:
[39:10..39:17): leftVar -> local3
[40:10..40:18): rightVar -> local4

Synthetics:
Copy link
Member Author

Choose a reason for hiding this comment

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

Unlike scala2, we don't have [4:6..4:19): (left, right) => *.apply[Int, Int] because actually we don't have it.

-Xprint:typer shows:

before

  val (left, right) = (1, 2)

after

    private[this] val $1$: (Int, Int) = Tuple2.apply[Int, Int](1, 2)
    val left: Int = this.$1$._1
    val right: Int = this.$1$._2

Copy link
Member Author

Choose a reason for hiding this comment

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

I didn't add synthesized Tuple2.apply[Int, Int](*) to Synthetic section, because Scala2 doesn't include it (even though there is synthesized Tuple2.apply )

Copy link
Member

Choose a reason for hiding this comment

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

maybe something can be done here with tree attachments, this case only occurs when a pattern is exactly identifiers in a tuple:

https://github.com/dotty-staging/dotty/blob/82677dab26eb2c9bd6c978f6bbf4d5318d797cc6/compiler/src/dotty/tools/dotc/ast/Desugar.scala#L1126-L1128

Copy link
Member

Choose a reason for hiding this comment

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

or at least the code linked above deals with all desugaring of patterns in val definitions so the door is open for other patterns than tuples

@bishabosha bishabosha self-requested a review September 6, 2021 16:09
@bishabosha bishabosha self-assigned this Sep 6, 2021
@bishabosha
Copy link
Member

this needs a rebase

@bishabosha bishabosha assigned tanishiking and unassigned bishabosha Sep 27, 2021
@smarter
Copy link
Member

smarter commented Nov 8, 2021

What's the status of this PR? It needs a rebase but otherwise can it be merged @bishabosha ?

@bishabosha
Copy link
Member

I think it was just about improving support for Tuple patterns in a val definition, but that could be done in a later PR

@tanishiking
Copy link
Member Author

sorry i'd been busy and couldn't update it, I'll rebase onto master later.

@bishabosha
Copy link
Member

bishabosha commented Nov 24, 2021

I rebased and re-ran from sbt scala3-compiler/Test/runMain dotty.tools.dotc.semanticdb.updateExpect

@bishabosha bishabosha merged commit 1eeb4fb into scala:master Nov 24, 2021
@tanishiking
Copy link
Member Author

Ah, sorry for the late response, and thank you for rebasing (and of course reviewing)!

@Kordyjan Kordyjan added this to the 3.1.2 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants