Skip to content

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