tree 909c6a8c61f9b81f58bcccd2a53f10e7cbbcf5c7
parent c81e7ae886d18e2eeb01e681ed56f6b90cf2d86c
author Heschi Kreinick <heschi@google.com> 1573518520 -0500
committer Heschi Kreinick <heschi@google.com> 1573600957 +0000

internal/memoize: propagate cancellation

If a user is typing fast, they will quickly invalidate many snapshots.
We don't want to stack up a bunch of stale type check and analysis
operations, so we should propagate cancellation through the cache.

Handles are long-lived, so we may cancel an operation only to
restart it again later. Also, there may be multiple operations waiting on
the same computation, and just because one is cancelled doesn't mean we
should necessarily stop. The easiest way to support all that was to add
an explicit state to each handle, and track the number of waiters.

See the code for more details on Handle life cycles.

As far as I can tell, the rest of gopls is prepared for this behavior.
I added an explicit check to the type checking code, where I was worried
it might get overly confused. But long-term it would probably be good to
return an error from Get.

Change-Id: I3ea6e141b52b94300a41248d3f2e039b023709d0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206879
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>