`is_a?(T)` can break further type filtering if `T` is an uninstantiated generic

[HertzDevil]

All of the expressions at the top should return true, and the NoReturn at the bottom should be B(Int32) since it simply swaps the order of the operands to && compared to the typeof immediately below:

class A; end
class B(T) < A; end

x = B(Int32).new.as(A)

x.is_a?(B       ) && x.is_a?(B       ) # => false
x.is_a?(B       ) && x.is_a?(B(Int32)) # => false
x.is_a?(B(Int32)) && x.is_a?(B       ) # => true
x.is_a?(B(Int32)) && x.is_a?(B(Int32)) # => true

typeof(x.is_a?(B       ) && x.is_a?(B       ) ? x : raise "") # => B(T)
typeof(x.is_a?(B       ) && x.is_a?(B(Int32)) ? x : raise "") # => NoReturn
typeof(x.is_a?(B(Int32)) && x.is_a?(B       ) ? x : raise "") # => B(Int32)
typeof(x.is_a?(B(Int32)) && x.is_a?(B(Int32)) ? x : raise "") # => B(Int32)

All the failures occur when x.is_a?(B) is used, which constrains the type of the x after the && to B(T).

[HertzDevil]

If we allow uninstantiated generic classes to have virtual types, then B+ (not B) will produce the correct results, but since B has no subclasses, x.is_a?(B) will still only restrict x to B, rather than B+. Another example:

class A; end
class B(T) < A; end
class C(T) < B(T); end

x = C(Int32).new.as(A)

x.is_a?(B) && x.is_a?(B) # => true # (before: false)
x.is_a?(B) && x.is_a?(C) # => true # (before: false)
x.is_a?(C) && x.is_a?(B) # => true
x.is_a?(C) && x.is_a?(C) # => false

typeof(x.is_a?(B) && x.is_a?(B) ? x : raise "") # => B(T)
typeof(x.is_a?(B) && x.is_a?(C) ? x : raise "") # => C(T) # (before: NoReturn)
typeof(x.is_a?(C) && x.is_a?(B) ? x : raise "") # => C(T)
typeof(x.is_a?(C) && x.is_a?(C) ? x : raise "") # => C(T)

Now B has a subclass, so B+ will show up. The failure x.is_a?(C) && x.is_a?(C) # => false remains because it is now C that has no subclasses. Those virtual uninstantiated generics might be required for #10394 (comment).

But even without this change, B in the OP or C here should already behave like a virtual type with respect to its instantiations; this is why #10785 defines "polymorphic types" through the presence of subtypes rather than subclasses (instantiations of B are subtypes, but not subclasses, of the uninstantiated B). Plus I would rather rewrite large parts of the intersection logic once #10781 is merged.

[HertzDevil]

The first example is now fixed on master. The second example now outputs:

class A; end
class B(T) < A; end
class C(T) < B(T); end

x = C(Int32).new.as(A)

p x.is_a?(B) && x.is_a?(B) # => true
p x.is_a?(B) && x.is_a?(C) # => false
p x.is_a?(C) && x.is_a?(B) # => true
p x.is_a?(C) && x.is_a?(C) # => true

p typeof(x.is_a?(B) && x.is_a?(B) ? x : raise "") # => B(T)
p typeof(x.is_a?(B) && x.is_a?(C) ? x : raise "") # => NoReturn
p typeof(x.is_a?(C) && x.is_a?(B) ? x : raise "") # => C(T)
p typeof(x.is_a?(C) && x.is_a?(C) ? x : raise "") # => C(T)

The false and NoReturn should be true and C(T) / C(Int32) respectively.