-
Notifications
You must be signed in to change notification settings - Fork 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
The inferred AppliedTypes from Java are not checked #7494
Comments
Wait a minute, why isn't it |
@TheElectronWill Thanks! I don't think See: 9.1.2. Generic Interfaces and Type Parameters and 4.5.1. Type Arguments of Parameterized Types . There are many types in Dotty which cannot be translated in Java, the lower bound is just one case. Another example is OrType: |
You're right! |
Checking every Select of a java-defined symbol would be too costly and still not perfect. The implemented compromise is to check bounds during the compilation of .java source files. To do this, a new JavaChecks file is added and called by FrontEnd. We can't simply discard java compilation units after PostTyper (instead of after Typer), because sbt.ExtractDependencies (and maybe others) runs before PostTyper and cannot process java sources.
Something goes wrong when we try to do mutually recursive F-bounds checking in Java units. I am not sure what exactly. But in any case, Scala should not try to do Java's typechecking. So we now check applications in Java units only if they refer to Scala classes. I added a test for scala#7494, which was originally addressed by scala#9370, the PR which introduced the Java bounds checking. Adding the test ensures that the new restrictions still glag the original error. Fixes scala#17763
Something goes wrong when we try to do mutually recursive F-bounds checking in Java units. I am not sure what exactly. But in any case, Scala should not try to do Java's typechecking. So we now check applications in Java units only if they refer to Scala classes. I added a test for #7494, which was originally addressed by #9370, the PR which introduced the Java bounds checking. Adding the test ensures that the new restrictions still flag the original error. Fixes #17763
We could construct
AppliedType
s from Java whose arguments do not conform to type bound. When the type is used in Dotty, it is not checked.minimized code
S.scala
J.java
expectation
I expected to see a type error at
J.getDS()
inS.scala
, sinceString
does not conform to lower boundA
. However, this test passed. I also test the same code in scalac 2.13, and it also compiled.The text was updated successfully, but these errors were encountered: