Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: X10 2.1.2
-
Fix Version/s: X10 2.3.2
-
Component/s: X10 Compiler: Front-end Typechecking
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
The following code:
public class XTENLANG_2480 { public static def main(Array[String]) { val v <: Double = 3; } }
fails to compile with this error:
./XTENLANG_2480.x10:3: Computed type is not a subtype of type bound.
Computed Type: x10.lang.Int{self==3}
Type Bound: x10.lang.Double
1 error.
while changing <: to : makes compilation succeed.
Typechecking partial types should attempt coercing the initializer to the type bound before reporting an error.
Issue Links
- is depended upon by
-
XTENLANG-2484
clarification needed for accessing static fields in a class via native code
-
-
XTENLANG-2439
X10 2.2 language design decisions (umbrella)
-
-
XTENLANG-2971
Umbrella language/front-end JIRA for X10 2.4
-
- relates to
-
XTENLANG-2487
Method Resolution doesn't handle user-defined implicit coercions correctly.
-
-
XTENLANG-2435
When inferring the return type, we should consider overriding methods and HasType.
-
-
XTENLANG-2526
Specify "operator (x:T) as ? <: U "
-
- supercedes
-
XTENLANG-1151
<:-declarations should try type conversions, too.
-
Fixed for fields and locals in r20384.
Fixing this for method/closure return types requires inserting coercions at return points. This means that the partial type bound needs to be in context as we're typechecking the method body, so that we can generate the appropriate coercions in one pass.