Possible fix for a null-pointer problem

Possible fix for a null-pointer problem

R=paulberry@google.com

Committed: https://github.com/dart-lang/sdk/commit/63865b5d1bda3861f4fd65edec38d99e44dd6ce4

[Brian Wilkerson, 2015-10-21 17:53:05]

brianwilkerson@google.com changed reviewers:
+ leafp@google.com, paulberry@google.com

[Brian Wilkerson, 2015-10-21 17:53:05]

I don't have a reproduction case, hence the lack of a test method. I can't even
be sure this will fix the problem that Leaf noticed. But I'm fairly confident
that this is reasonable guard code.

[Paul Berry, 2015-10-21 17:57:34]

lgtm assuming the fix below is applied.

https://codereview.chromium.org/1408393007/diff/1/pkg/analyzer/lib/src/contex...
File pkg/analyzer/lib/src/context/context.dart (right):

https://codereview.chromium.org/1408393007/diff/1/pkg/analyzer/lib/src/contex...
pkg/analyzer/lib/src/context/context.dart:1521:
pendingFutures[i].forciblyComplete();
After this line, add:

pendingFutures.removeAt(i);

Otherwise we will try to forcibly complete the same futures over and over again
every time _evaluatePendingFutures() is called.

[Brian Wilkerson, 2015-10-21 18:05:02]

https://codereview.chromium.org/1408393007/diff/1/pkg/analyzer/lib/src/contex...
File pkg/analyzer/lib/src/context/context.dart (right):

https://codereview.chromium.org/1408393007/diff/1/pkg/analyzer/lib/src/contex...
pkg/analyzer/lib/src/context/context.dart:1521:
pendingFutures[i].forciblyComplete();
Good catch! Done.

[Brian Wilkerson, 2015-10-21 18:10:21]

Committed patchset #1 (id:1) manually as
63865b5d1bda3861f4fd65edec38d99e44dd6ce4 (presubmit successful).

[Leaf, 2015-10-21 18:15:47]

Thanks! I'll try it out.

https://codereview.chromium.org/1408393007/diff/1/pkg/analyzer/lib/src/contex...
File pkg/analyzer/lib/src/context/context.dart (right):

https://codereview.chromium.org/1408393007/diff/1/pkg/analyzer/lib/src/contex...
pkg/analyzer/lib/src/context/context.dart:1521:
pendingFutures[i].forciblyComplete();
On 2015/10/21 18:05:01, Brian Wilkerson wrote:
> Good catch! Done.

This is the same location that I was generally seeing the null cache entry
errors, so likely this will fix it.  I don't know if you want to pursue this
further, but I did observe that if you change the get method to throw an error
if it reaches the end of the method (which is not supposed to happen), then you
get a test failure:

python tools/test.py --host-checked -mrelease -cdart2analyzer -rnone -t240
language/internal_library_test/02

I didn't track it down any further at the time though.