Test AsyncLocal diagnostics feasibility, again.

[majocha]

As minimal as possible, just to see how it fares in CI, for now.

The goal is to get almost everything to pass apart from Transparent Compiler / AsyncMemoize tests.

[github-actions]

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.300.md	No release notes found or release notes format is not correct

[majocha]

@0101 from the call stacks it looks like some of the the failing tests here, for example in Build Linux leg, are running with Transparent Compiler? (I'm seeing AsyncMemoize.Get in the callstack).
These tests are green for me locally, when running without FSHARP_EXPERIMENTAL_FEATURES.

My question is, is there a way to tell which parts of the CI run with Transparent Compiler?

[0101]

@majocha this one: fsharp-ci (Build WindowsCompressedMetadata transparent_compiler_release)

There's another env var used there, TEST_TRANSPARENT_COMPILER. Because when I tried using the experimental features one some unrelated tests started failing.

[majocha]

Thanks! Turns out I have a hard time telling which failed tests failed in which jobs.

[majocha]

OK what's going on here, is Threadstatics leaking from one test to another. I guess threads get reused?
Looks like it's benign as in it does not or very rarely cause actual test failures. Just the detection method here, comparing at each getter access is much more sensitive than waiting for an actual test failure.

This behavior, of threadstatics leaking to unrelated tests, is very much exacerbated by NodeCode.Parallel. I replaced Parallel with Sequential in IncrementalBuild and it became green, (apart from desktop_release, it seems).
Note, the CI runs here are not green, because I put a failwith in AsyncMemoize to isolate the new Transparent Compiler stuff.

One thing makes me wonder, there were lots of weird strangely unrelated test failures right after merging Transparent Compiler. Is it possible it was related somehow?

Apart from this one issue, it seems AsyncLocal follows the behavior of ThreadStatics quite well and it looks like the issue is on the ThreadStatics / NodeCodeBuilder side.
IMV it is much easier to get predictable and deterministic behavior out of AsyncLocal. I also suspect there are some unresolved issues in the current implementation, especially regarding concurrent execution.