Skip to content

Handle leading given parameters in inline unapplies #13158

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Handle leading given parameters in inline unapplies #13158

wants to merge 1 commit into from

Conversation

nicolasstucki
Copy link
Contributor

Fixes #12991

@nicolasstucki nicolasstucki force-pushed the fix-#12991 branch 3 times, most recently from 6395973 to 5b2ba2c Compare July 27, 2021 07:19
@nicolasstucki nicolasstucki requested a review from odersky July 27, 2021 11:33
odersky
odersky reviewed Aug 1, 2021
View reviewed changes
Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

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

This makes the code considerably more obscure. So it would have to be commented much better.

But that brings me to the other point. This considerably increases the complexity footprint of an already very complex method. So the question is: Is there an actual use case? Or could we just as well also disallow leading given parameter for inline unapplies?

I am worried that we create unpenetrable code that nobody will dare to touch anymore in the future.

compiler/src/dotty/tools/dotc/typer/Inliner.scala
val unappplySym = newSymbol(cls, sym.name.toTermName, Synthetic | Method, unapplyInfo, coord = sym.coord).entered
val unapply = DefDef(unappplySym, argss =>
inlineCall(fun.appliedToArgss(argss).withSpan(unapp.span))(using ctx.withOwner(unappplySym))
val unapplySym = newSymbol(cls, sym.name.toTermName, Synthetic | Method, unapplyInfo, coord = sym.coord).entered
Copy link
Contributor

Choose a reason for hiding this comment

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

Where did the inlineCall go? Don't we need that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't need to expand it at this point, the inlining phase takes care of inlining the code.

@odersky odersky assigned nicolasstucki and unassigned odersky Aug 1, 2021
@nicolasstucki
Copy link
Contributor Author

So the question is: Is there an actual use case?

For path-dependent unapplies. I can imagine the following case the the reflection API.

object Foo:
  inline def unapply(using Quotes)(term: quotes.reflect.Term): Option[...] = ...

@nicolasstucki nicolasstucki mentioned this pull request Jun 17, 2022
Closed
nicolasstucki added a commit to dotty-staging/dotty that referenced this pull request Jul 4, 2022
@nicolasstucki
Check is inline unapply has leading implicits
bcaf705 
We patch the crash in the compiler but do not support this feature yet.

To support it see scala#13158

Fixes scala#12991
nicolasstucki added a commit to dotty-staging/dotty that referenced this pull request Jul 4, 2022
@nicolasstucki
Check is inline unapply has leading implicits
776e4d6 
We patch the crash in the compiler but do not support this feature yet.

To support it see scala#13158

Fixes scala#12991
@nicolasstucki nicolasstucki mentioned this pull request Jul 4, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@odersky odersky odersky left review comments

Assignees

@nicolasstucki nicolasstucki

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Inline unapply with leading contextual parameter used as extractor crashes compiler
2 participants
@nicolasstucki @odersky