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

Allow autotupling if fn's param is a type param #21741

Merged
merged 1 commit into from
Nov 13, 2024

Conversation

dwijnand
Copy link
Member

@dwijnand dwijnand commented Oct 9, 2024

Fixes #21682

@dwijnand dwijnand marked this pull request as ready for review October 30, 2024 10:09
@dwijnand dwijnand requested a review from odersky October 30, 2024 10:09
@odersky odersky assigned dwijnand and unassigned odersky Nov 4, 2024
@dwijnand
Copy link
Member Author

dwijnand commented Nov 4, 2024

@odersky in #21552 I constrained the conditions for autotupling, but it fails to consider constrainable type parameter types, which I'm looking to adding back here. Should I look to do this some other way?

formals.length == 1 && ptIsCorrectProduct(formals.head, args)
formals.lengthIs == 1 && {
ptIsCorrectProduct(formals.head, args)
| formals.head.dealias.isInstanceOf[TypeParamRef] // eg. i21682
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need an explanation what goes on here and why the test is necessary and sufficient. Right now I have no idea what goes on here.

@dwijnand dwijnand force-pushed the 21682-reg-infr-overload-dataprism branch from d93cc60 to 9d2aeac Compare November 6, 2024 11:41
// See i21682 for an example.
val tup = defn.tupleType(args.map(v => if v.tpt.isEmpty then WildcardType else typedAheadType(v.tpt).tpe))
val TypeBounds(lo, hi) = formal.paramInfo
lo <:< tup && tup <:< hi
Copy link
Member Author

Choose a reason for hiding this comment

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

Btw, I experimented pushing this change into ptIsCorrectProduct and extending it to TypeVar. That way, given that ptIsCorrectProduct is already used by typedFunctionValue, we would allow code like this, from tests/neg/function-arity.scala, to compile:

  def unary[T](x: T => Unit) = ???
  unary((x, y) => ())   // error

Are we interested in that working?

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.

Thanks, now it's clearer!

@odersky odersky merged commit 7243053 into scala:main Nov 13, 2024
29 checks passed
@dwijnand dwijnand deleted the 21682-reg-infr-overload-dataprism branch November 13, 2024 13:39
@WojciechMazur WojciechMazur added the backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. label Nov 13, 2024
@WojciechMazur WojciechMazur added this to the 3.6.2 milestone Nov 13, 2024
@WojciechMazur WojciechMazur added backport:accepted This PR needs to be backported, once it's been backported replace this tag by "backport:done" and removed backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. labels Nov 18, 2024
WojciechMazur added a commit that referenced this pull request Nov 18, 2024
…1963)

Backports #21741 to the 3.6.2.

PR submitted by the release tooling.
[skip ci]
@WojciechMazur WojciechMazur added backport:done This PR was successfully backported. and removed backport:accepted This PR needs to be backported, once it's been backported replace this tag by "backport:done" labels Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:done This PR was successfully backported.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Regression for type inference/ method overload in katrix/dataprism
3 participants