Parameter untupling with context function args #16994
Comments
ojow
added
itype:bug
itype:crash
stat:needs triage
Kordyjan
added
area:transform
and removed
stat:needs triage
|
Still reproducible both on |
|
Stems from two factors:
// post typer
type ZZ = String => Int
def f: ZZ = ???
val f2: ZZ = f
// vs
type ZZ = (String) ?=> Int
def f: ZZ =
{
def $anonfun(using evidence$1: String): Int = ???
closure($anonfun)
}
val f2: ZZ =
{
def $anonfun(using evidence$2: String): Int = f.apply(evidence$2)
closure($anonfun)
}Those two clash with each other, as now {
def $anonfun(using evidence$1: String): Int =
x$1._1.apply(evidence$1)
closure($anonfun)
}There are thus two ways to solve this problem:
We believe option 2 to be superior, but did not have time to implement it, we can however simplify the test case, now all that remains to test is that type ZZ = String ?=> Int
def f: ZZ = ???
val f2: ZZ = fLooks like the following after typer ( package <empty> {
final lazy module val i16994$package: i16994$package = new i16994$package()
final module class i16994$package() extends Object() {
this: i16994$package.type =>
type ZZ = (String) ?=> Int
val f: ZZ = ???
val i: Int = f
}
} |
|
Background information needed: |
|
Actually, with the reduced test, only knowledge of context functions is needed |
|
This issue was picked for the Issue Spree No. 28 of 28 March 2023 which takes place in a week from now. @Sporarum, @dwijnand, @yawen-guan will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here. |
|
I had made a branch for this issue: |
|
Maybe we could add something to |
|
We realised this is a harder problem to solve than expected, this is due to val x: String ?=> Int = 4
// becomes:
val x: String ?=> Int = (_: String) ?=> 4So type ZZ = String ?=> Int
def f: ZZ = ???
val f2: ZZ = f
// becomes naturally something like:
...
val f2: ZZ = (_: String) ?=> f(using summon[String])Given this seems to be the specced behaviour we determined the fastest way for this issue to be solved was to instead change This allows for this issue to be closed sooner, and in case these useless closures become more of a problem, it can always be changed later |
|
@odersky btw, this was the issue I was attempting to describe. The handling of context function is unique in being sort of "pre-adapted" in typer, which doesn't allow for this simple (but less common) counter-example to be typed in an expected way. I now realise that there are only calls to "readapt" in adapt, there's no re-typing, as far as I can see. So even if this would be moved to adapt, it would be a bit of an outlier there too. And at the cost of cpu and memory for the more common cases: we'd spend time assigning error types and then have to clone trees to be able to assign the right types the second time round. So perhaps we should leave this as is. One of the cases I looked at with Quentin did end up removing the pointless closure, somewhere in Just jotting down my mental notes on this. I think we should just make |
|
Context functions deeply need these alias closures. They will be elimiinated later at erasure. But to do a realiable job of elimination we have to make sure these closures are there in the first place. So yes, we need to change |
|
Thank you for your insights, it's good to know in particular these are deleted later ! I do wonder however if there are other places where we assume a tree to be of a certain shape, and this can break it ? In regards to this issue, I believe it to still be suitable for a Spree, as the fix is now relatively well scoped, alternatively, @dwijnand and/or I could fix it directly |
Compiler version
3.2.2
Minimized code
Output (click arrow to expand)
The text was updated successfully, but these errors were encountered: