"is" checks aren't considered with generic-method types

[nex3]

If I run the analyzer over the following code in strong mode:

void fn/*<T>*/(/*=T*/ object) {
  if (object is String) print(object.substring(1));
}

I get the error "The method 'substring' is not defined for the class 'Object'.". This seems incorrect, since I'm asserting that object is String immediately before calling substring().

[jmesserly]

I think this is covered by one of the items at:
#25565
... but that said, this one is probably fairly easy to fix on its own -- we just need to consider the type parameter bound; we already made several fixes along those lines for Strong Mode.

@munificent @leafpetersen - any word lately on improved type promotion and/or related features? we're in a really tough spot right now, with so much stuff not working. I know I bump into it quite a lot too.

[leafpetersen]

I don't think considering the bound helps here, at least not directly. Currently promotion is only done if the type you're testing against is a subtype of the static type of the thing you're testing, which isn't the case here (and in general will never be the case for type variables without contra-variant bounds except in trivial cases). There does seem to a valid argument for not-promoting in some cases, but I can't think of any offhand in the type variable case. It seems like promoting if the type being tested against is a subtype of the bound would make sense.

[jmesserly]

It seems like promoting if the type being tested against is a subtype of the bound would make sense.

yeah, agreed. I had the same thought at first: "well don't promote because T could be anything". But given a type parameter T extends S, we will only allow you to do operations on S statically. So given: (T t) { if (t is R) { ... } }, where R <: S, it would be safe to promote t to R, as that is a superset of the operations you could express before promotion. (edit: clarity)

[jmesserly]

https://codereview.chromium.org/2214833002

[leafpetersen]

It occurs to me that an even better change would be to allow refinement of the upper bound, so that within the scope of the check the variable is treated as having an upper bound of the refined type. I don't think that fits into the existing type promotion structure, but something to think about as a future refinement.

[jmesserly]

fyi -- I filed #27040 to track your comment Leaf.