Skip to content
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

Raw type used in argument position is not existentially quantified #4712

Closed
scabug opened this issue Jun 18, 2011 · 8 comments
Closed

Raw type used in argument position is not existentially quantified #4712

scabug opened this issue Jun 18, 2011 · 8 comments
Assignees

Comments

@scabug
Copy link

scabug commented Jun 18, 2011

// BaseInterface.java
public interface IBaseInterface<T> { 
    void f(T t); 
}
// IDerivedInterface.java
public interface IDerivedInterface extends IBaseInterface<Class> { 
    void g(Class c); 
}
// Problem.scala
object Problem { 
  def a(i:IDerivedInterface) = i.f(classOf[String]) // error!
  def b(i:IDerivedInterface) = i.g(classOf[String]) 
}
problem.scala:2: error: type mismatch;
 found   : Class[_$1] where type _$1
 required: java.lang.Class
  def a(i:IDerivedInterface) = i.f(classOf[String].asInstanceOf[Class[_]]) 

Notice the required type 'java.lang.Class', which should be transformed to an existential type when seen from IDerivedInterface. The compiler does the correct thing for the method g, which is not inherited.

@scabug
Copy link
Author

scabug commented Jun 18, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4712?orig=1
Reporter: @dragos
Affected Versions: 2.8.1, 2.9.0

@scabug
Copy link
Author

scabug commented Jun 20, 2011

@adriaanm said (edited on Jun 20, 2011 1:03:56 PM UTC):
I had a quick look, and I think the problem is that cooking of a symbol's info happens irrespective of the actual type arguments that are provided for the type parameters in scope at the symbol.

Concretely, cooking is a no-op for the info of method f since T is not considered a raw type. Of course it is instantiated to the mother of all raw types, Class, here, but that happens after cooking.

Debug info for illustration:

typing i.f(classOf[String]): pt = ?
  typing i.f: pt = ?
[...]
  cooking: method f: (x$1: T)Unit to (x$1: T)Unit
typed i.f: (x$1: java.lang.Class)Unit
adapted i.f: (x$1: java.lang.Class)Unit to ?,

@scabug
Copy link
Author

scabug commented Jun 20, 2011

@adriaanm said (edited on Jun 20, 2011 1:40:09 PM UTC):
proposed fix:

         } else if (!context.undetparams.isEmpty && !inPolyMode(mode)) { // (9)
          assert(!inHKMode(mode)) //@M
          instantiate(tree, mode, pt)
+        } else if (tree.hasSymbol && tree.symbol.isJavaDefined && (tree.tpe.isInstanceOf[MethodType] || tree.tpe.isInstanceOf[OverloadedType])) {
+          // may need to re-cook now that type parameters have been instantiated to possibly raw type arguments
+          tree setType rawToExistential(tree.tpe)
        } else if (tree.tpe <:< pt) {
          tree

@scabug
Copy link
Author

scabug commented Jun 20, 2011

@odersky said:
We could do that, but it comes a bit late for my taste. The problem is when we compute the base type of Derived. I'd rather eliminate the raw type there.

@scabug
Copy link
Author

scabug commented Jun 20, 2011

@soc said:
This seems to be related to #3634.

@scabug
Copy link
Author

scabug commented Jun 20, 2011

@adriaanm said:
right, I see what you meant now in my office -- I've found it a bit trickier to find a nice hook so that TypeRef's baseType and baseTypeSeq uniformly do the right thing...

@scabug
Copy link
Author

scabug commented Jun 21, 2011

Commit Message Bot (anonymous) said:
(odersky in r25126) Fixes #4712. Review by moors.

@scabug scabug closed this as completed Jun 21, 2011
@scabug
Copy link
Author

scabug commented Jun 21, 2011

@odersky said (edited on Jun 21, 2011 10:12:20 AM UTC):
My earlier attempts did not work because other things fail by going from raw to existential too early. The new (admittedly kludgey) fix is to do rawToExistential very late, once we already got an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants