-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Good code is red. Java interop issue with collectors #19637
Comments
SimY4
added
itype:bug
stat:needs triage
Every issue needs to have an "area" and "itype" label
labels
Feb 7, 2024
workaround: import java.util.stream.*
import java.util.function.*
val map: java.util.Map[String, String] = Stream.of("1", "2", "3").collect(Collectors.toMap(
(s: String) => s,
Function.identity(),
((k: String, v: String) => (k, v) match {
case ("1", "1") => "1"
case (_, l) => l
})
)) |
second workaround: import java.util.stream.*
import java.util.function.*
val map: java.util.Map[String, String] = Stream.of("1", "2", "3").collect(Collectors.toMap(
(s: String) => s,
Function.identity(),
{
case ("1", "1") => "1"
case (_, l) => l
}: java.util.function.BinaryOperator[String]
)) |
bishabosha
added
area: type inference
and removed
stat:needs triage
Every issue needs to have an "area" and "itype" label
labels
Feb 7, 2024
Can we get a bisect on this? |
If we add the test in
In the logs we see
The issue started in 6c556aa |
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Feb 9, 2024
The previous code tried to recursively apply the current instance of FullyDefinedAccumulator to the prospective instance type. This can have unforeseen side-effects, as i19637 shows. We now are more conservative: We check that the prospective instance type is already fully defined without the possibility to instantiate more type variables. This still passes the test cases that type variable improvement solves and avoids the problem with scala#19637. Fixes scala#19637
odersky
added a commit
that referenced
this issue
Feb 9, 2024
The previous code tried to recursively apply the current instance of FullyDefinedAccumulator to the prospective instance type. This can have unforeseen side-effects, as i19637 shows. We now are more conservative: We check that the prospective instance type is already fully defined without the possibility to instantiate more type variables. This still passes the test cases that type variable improvement solves and avoids the problem with #19637. Fixes #19637
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiler version
Reproducible on 3.4.0-RC4. This code works fine on 3.3.1
Minimized code
Output
Expectation
Should compile
The text was updated successfully, but these errors were encountered: