Heschi Kreinick 76a3b8da50 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>		2019-11-12 23:22:37 +00:00
..
memoize_test.go	internal/memoize: changes to only one handle per key	2019-09-17 14:40:27 +00:00
memoize.go	internal/memoize: propagate cancellation	2019-11-12 23:22:37 +00:00
nocopy.go	internal/memoize: a new library to memoize functions	2019-06-10 23:17:49 +00:00