Move off of the final usage of an uncached AsyncLazy
Followup to https://github.com/dotnet/roslyn/pull/65719.
@jasonmalinowski This is ready for review. Once this goes in, all usages of AsyncLazy cache their value, and we can move to that being the only functionality supported for it.
Build: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build/results?buildId=7065812&view=results PR is: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/440423
@jasonmalinowski no rps or speedometer issues. Can you ptal?
@CyrusNajmabadi I think what might help here is a better understanding of what simplification this is saving us. As a direct tradeoff, I'd imagine this is adding as much code here as this would allow us to remove from AsyncLazy, but with potential new disadvantages.
To me, this is makign AsyncLazy simply much clearer and simpler. It lazily, asynchronously, computes a value, caching it once complete. That's literally how it's used for all but one case. Having it only be for that purpose, and having the odd case out clearly be odd, is a cleaner and simpler design.
If we commonly needed asynclazies that didn't cache, i would feel differently. But we dont'. So it feels like a very strange thing we bolted on for one use case, versus having that single case just be special.
@jasonmalinowski any thoughts on moving forward on this. can take for 17.6 if you're concerned.
Rebased to 17.6
target main since it is 17.6 now
Build is: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7443567&view=results PR is: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7443567&view=logs&j=7ae71e7c-d4fe-51ea-64cd-240849b77ab1&t=c4869a46-101d-5a27-7e56-5bbd31d167d6&l=16
Build is: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7572021&view=results PR is: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/462793
Build is: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7599589&view=results PR is: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/464186
@jasonmalinowski val PR passed without any issues whatsoever: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/464186
Can you ptal? I'd def like to simplify things here.
@sharwell is yours a hard block? I'd like to move forward with this as i'm trying to continue workign in this space and i find both the deviation from the norm confusing, and also find it harder to reason about when working in the ValueSource/AsyncLazy/ITextAndVersionSource/RecoverableText do have these sorts of extra knobs and literal one-off behaviors :)
Thanks!
Thanks both for the feedback and reviews.