Relax nullability checks on FlexibleTypes

[HarrisL2]

These changes allow flow-typing to view flexible types as non-nullable at relevant places.

[noti0na1]

I don't agree reporting warnings for .nn on flexible types, since it correctly rules out implicit nulls.

I would also not make flexible type a "notnull" type. It can have null value by definition...

[olhotak]

isNotNull is used in a number of places. One of those places is flow typing. @HarrisL2 you had some specific compelling use cases from the community build that would bring a significant benefit to flow typing from this change. Can you put some of those examples (or modified illustrative examples) here in the discussion and/or as compiler tests on this PR?

It may be that flow typing should use a different version of isNotNull than some of the other places where the compiler calls isNotNull. It would be useful for us to discuss the motivating examples for flow typing.

[HarrisL2]

I could not find the example where the change for isNotNull is needed. But I did find an example for the change in NullOpsDecorator.scala:50.

//> using options -Yexplicit-nulls import java.math.BigInteger def main() = val bint: BigInteger = new BigInteger( "5") var result: BigInteger | Null = bint.multiply(bint) result.longValue

gives an error for accessing longValue.

Having the change allows the access, but gives a warning if we use .nn.

I don't agree reporting warnings for .nn on flexible types, since it correctly rules out implicit nulls.

I would also not make flexible type a "notnull" type. It can have null value by definition...

If so, we could make it so that we don't give warnings if the .nn is on a FlexibleType.