Generic method invocations have no type argument in the generated Java code

[quintesse]

Code like this:

void bar<T>(T x) {
}
void bartest() {
    bar<Object>("foo");
}

results in this code for the call to bar;

        .test.bar.bar(.ceylon.language.String.instance("foo"));

It's missing the <Object> on the method invocation.

[tombentley]

FTR, what concrete problem(s) does this cause?

[gavinking]

@tombentley we don't think we've run into one yet, but it's certainly very fragile. Our type argument inference rules are definitely not the same as Java's.

[quintesse]

That I can't do Array<Object> objs = arrayOfSome<Object>("one", "two", "three") for example. The typechecker will infer <String> which means (internally) the code will actually make a String[] instead of the Object[] I'm requesting.

[gavinking]

Ignore what I just typed :)

[quintesse]

I just saw it appear seconds before hitting the comment button ;)

[quintesse]

Ok, my explanation wasn't completely correct, so the arrayOfSome<Object>() will generate the correct type of array (Object[]) but Java will infer arrayOfSome<String>() because of the arguments passed to it, which will result in:

Arrays.ceylon:288: error: inconvertible types
    java.take_Objects(arrayOfSome<Object>({"aap", "noot", "mies"}));
                      ^
  required: Array<Object>
  found:    Array<String>

[FroMage]

Looks like this one can wait for M5

[gavinking]

Looks like this one can wait for M5

@FroMage Really? C'mon, this has gotta be pretty easy, doesn't it?

[FroMage]

Everything with type arguments is hard unless proven otherwise. We still have +50 open issues for M4.

[gavinking]

We still have +50 open issues for M4.

The thing is that fixing this one probably fixes all kinds of other issues by side-effect.

[FroMage]

Perhaps, but none of the +50 issues.

[FroMage]

Moving to M6

[tombentley]

I wanted to look at this while I was fresh from #1095. To be clear, as far as I'm aware everywhere there's a Tree.InvocationExpression we instantiate methods with type arguments except when any of the arguments is erased to java.lang.Object or Sequential.

Firstly it seems the Sequential part is superfluous.

The main barrier to using an erased java.lang.Object when instantiating the method is that java.lang.Object might not satisfy any constraints on the type parameter. It's usually possible to figure out the bounds though, unless multiple type parameters are interdependent and one of them is being erased. So in many cases we could do better than we are currently. (Remember that although we'll be using java.lang.Object for one of the type arguments in this case that's still better than going raw because there might be other type arguments).

I'd like @FroMage's opinion on this because he's the expert on erasure: Perhaps I've missed some consequences of not going raw.

[tombentley]

I should have made clear, this isn't hypothetical: I have seemingly working code.

[FroMage]

Looks good to me

[tombentley]

Great, thanks!