Add InterruptibleLazy

[auduchinok]

Continues #16137 and adds Lazy implementation that doesn't cache exceptions, allowing it to be used when OperationCancelledException may be raised inside the factory function. I've initially added it to various IL types, but ended up transitively updating other places, so no conversion between lazy types is needed. It also allows to cancel in more places in future if we decide to add more cancellation points via Cancellable or other way.

It also adds tests for cancellation inside metadata reading in various places during project analysis startup and during code analysis. These tests show that previously cancelled requests now don't have any impact on subsequent requests and these requests return correct info. These tests have also shown some performance issues in metadata reading (see #16166), which is good, since we can improve these parts of the compiler too and even assert it with these tests.

Next steps may be these:

• Check LazyWithContext. It seems it's redundant to create it just for keeping the exception ranges, as errorRecovery also attaches relatively good range to errors. It needs to be checked and evaluated, though.

[vzarytovskii]

Out of curiosity, have you compared it to previous version in terms of perf/allocations? Is it any significantly different?

[auduchinok]

Out of curiosity, have you compared it to previous version in terms of perf/allocations? Is it any significantly different?

@vzarytovskii I haven't benchmarked it, but from the analysis of the changes there shouldn't be much difference.

The F# built-in lazy allocates one more Func instance everywhere to pass it to the BCL Lazy which keeps it, so the interruptible implementation saves some memory. Otherwise the implementation is very similar to the BCL Lazy:

• each instance have fields for the value, factory, and a sync object
• each instance allocates a new sync object
• there's a non-syncronized attempt to get calculated value first
• if not calculated, there's a lock/Monitor block that implements double checked locking

We can save one more field and allocation of the sync objects to save even more memory, if we decide that it'd be OK to lock on this inside these lazy objects, but I'm OK with discussing/doing it separately.

[abonie]

How does launching heavy operations in the checker and then immediately cancelling them affects GC or allocations in general?

[auduchinok]

How does launching heavy operations in the checker and then immediately cancelling them affects GC or allocations in general?

I think it depends on a particular place where a cancellation happens, but in a typical scenario it shouldn't add overhead compared to a normal subsequent request with a different source or project options. What I think important here is if a request is cancelled, then we're not interested in its result anymore and it's also likely that the world has changed in some way: it'll will likely need to do many things again for a fresh analysis anyway. One of the main ideas of #16137, of which this PR is a continuation, is to make it possible to prevent access to an outdated state, and this PR allows it in more cases.

[psfinaki]

To me this looks promising. Thanks!