infer null from context, this avoids bottom being introduced

infer null from context, this avoids bottom being introduced
Note this regresses inference on ternary ops, so it may not be worth it

[Jennifer Messerly, 2016-08-04 13:10:15]

jmesserly@google.com changed reviewers:
+ leafp@google.com

[Jennifer Messerly, 2016-08-04 13:10:16]

HI Leaf, wanted to get your opinion on this approach. I'm not sure it's a good
idea, as illustrated by one of the test cases. But it does ensure we won't have
"bottom" show up incorrectly.

(Likely we could clean up some logic in other places that are defensive about
inferring bottom. I didn't do that yet, though.)

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/generated...
File pkg/analyzer/test/generated/strong_mode_test.dart (right):

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/generated...
pkg/analyzer/test/generated/strong_mode_test.dart:2049:
expectInitializerType('foo', 'dynamic', isNull);
This case is really unfortunate and makes me doubtful of the merits of this CL.
To some extent, it may be avoidable with null aware ops, but not always.

I suppose we could add some logic for ternary ops when one of the branches is
null? Or is that just papering over the problem.

[Leaf, 2016-08-04 23:52:55]

Yeah, I think I agree that this isn't quite what we want yet.  We might want to
whiteboard this out at some point.

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/generated...
File pkg/analyzer/test/generated/strong_mode_test.dart (right):

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/generated...
pkg/analyzer/test/generated/strong_mode_test.dart:2049:
expectInitializerType('foo', 'dynamic', isNull);
On 2016/08/04 13:10:16, John Messerly wrote:
> This case is really unfortunate and makes me doubtful of the merits of this
CL.
> To some extent, it may be avoidable with null aware ops, but not always.
> 
> I suppose we could add some logic for ternary ops when one of the branches is
> null? Or is that just papering over the problem.

Yeah, I think this will cause problems.  I think it will show up in other places
that LUB is used as well.  I think there are ways we could tackle this, but not
sure it's worth it right now.

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/src/task/...
File pkg/analyzer/test/src/task/strong/inferred_type_test.dart (right):

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/src/task/...
pkg/analyzer/test/src/task/strong/inferred_type_test.dart:2823: var y = (c.n *=
/*error:STATIC_TYPE_ERROR*/null);
This doesn't seem right either.

[Jennifer Messerly, 2016-08-05 13:46:36]

Thanks for the sanity check. Worthwhile experiment but closing this out for now.

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/generated...
File pkg/analyzer/test/generated/strong_mode_test.dart (right):

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/generated...
pkg/analyzer/test/generated/strong_mode_test.dart:2049:
expectInitializerType('foo', 'dynamic', isNull);
On 2016/08/04 23:52:55, Leaf wrote:
> On 2016/08/04 13:10:16, John Messerly wrote:
> > This case is really unfortunate and makes me doubtful of the merits of this
> CL.
> > To some extent, it may be avoidable with null aware ops, but not always.
> > 
> > I suppose we could add some logic for ternary ops when one of the branches
is
> > null? Or is that just papering over the problem.
> 
> Yeah, I think this will cause problems.  I think it will show up in other
places
> that LUB is used as well.  I think there are ways we could tackle this, but
not
> sure it's worth it right now.

Yeah, definitely doesn't seem right at the moment.

Another thought here is define a type for `null` (maybe Null?), and have it be
subtype of other nullable types. essentially LUB(Null, T) becomes T in our
current system (and could be extended once we have non-nullable types).

But that's getting a little out of the scope of this change, so going to close
this one :)

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/src/task/...
File pkg/analyzer/test/src/task/strong/inferred_type_test.dart (right):

https://codereview.chromium.org/2210293002/diff/1/pkg/analyzer/test/src/task/...
pkg/analyzer/test/src/task/strong/inferred_type_test.dart:2823: var y = (c.n *=
/*error:STATIC_TYPE_ERROR*/null);
On 2016/08/04 23:52:55, Leaf wrote:
> This doesn't seem right either.

yeah, this one could be fixed in a straightforward way though, I'm guessing we
just never felt the need to bother with a context type here.