Don Syme

This is a classic case where error recovery and subsequent errors make later errors more obscure. @vzarytovskii We should probably implement a general rule: **always suppresses later errors if they...

Treating as a duplicate of #13341

I took a look. Methodology: 1. Collect arguments via ``` cd reproduction-fsharp-compilation-diff-method-let\reproduction-fsharp-compilation-diff-method-let\LetBindings dotnet build -v n > args.txt ``` then hand edit args.txt to contain only the arguments to the...

So note that the two inputs are fairly different - the `member` code has no file-level initialization, while the `let` code does. The second seems to hit a choke point...

Note also a lot of exception handlers are being emitted in the initialization code, which may not be entirely obvious, because of this: ``` let inline jsNative

So the test only recently moved to ComponentTests, in https://github.com/dotnet/fsharp/pull/12985. So only recently started running on MacOS So I guess we have an edge condition somehow where we're at the...

I think it must be some variation in the size of the stack at the calling point, likely due to the test framework For some reason (e.g. concurrent processing of...

Different paths in printing tests: ```fsharp 2022-08-19T15:56:39.4580448Z - --> Referenced 'C:/Users/dsyme/.nuget/packages/newtonsoft.json/13.0.1/lib/net45/Newtonsoft.Json.dll' (file may be locked by F# Interactive process) 2022-08-19T15:56:39.4582311Z + --> Referenced 'C:/Users/cloudtest/.nuget/packages/newtonsoft.json/13.0.1/lib/net45/Newtonsoft.Json.dll' (file may be locked by F#...

@vzarytovskii This is ready, I've added a test

Might be duplicate of https://github.com/dotnet/fsharp/issues/9631, is certainly similar