Thank you for the swift action. Unfortunately another MSVC-ism has reared its head.

We are seeing a build error on Windows building with MSVC. Attempt to access a private typedef.

One of the main problems we found in this investigation was getting reliable performance metrics. Scudo was at least very consistent. Windows Heap appears to be wildly influenced by the allocation/de-allocation profile. In some circumstances WinHeap was seen to perform and scale very well over multiple threads. But in others it was seen to perform amazingly badly. One suspected culprit for this effect is the interaction between the 'low-fragmentation' heap scheme used for smaller allocations vs the 'big heap' for larger.

Fixed missing commit in diff file.

This commit is failing the test on non-arm targets (e.g. https://lab.llvm.org/buildbot/#/builders/139/builds/5932). I think the test needs a 'requires' line for aarch64.

Looks like some lines got truncated from the head of the first test file. Test is failing due to no run line.

I'm afraid we are seeing a build failure here on our local Windows checking MSVC build. Unfortunately I cannot find a public buildbot that uses the exact configuration that causes the assertion. The assertion we are seeing is

May I ask if the changes made to 'binary-formats.canonical.json' in regards to making the filename checks more strict were deliberate? It is just that on Windows systems these checks now fail due to path name differences (the good old '/' vs '\' problems). I notice you did keep a more relaxed filename check intact in some other tests.

In D42369#984155, @probinson wrote:

I'm not seeing where the add/getLocalLexicalDIEs APIs are being used.

Apologies, I had a lot of trouble getting svn setup on my machine. Seems I lost some changes in the original diff. Updated for code to issues the lexical DIEs.

Hello, I'm afraid this commit is failing on Windows.

I'm afraid this has broken Windows builds (http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/12860/steps/test/logs/stdio).

This change is failing to build on windows buildbots.

I must apologise to you all. The problem was reported in our out-of-tree version of the compiler and I must have hit finger problems when I confirmed it in tree. Repeating the test I can no longer reproduce the fault with the 3.9.0 public build. It must be some effect of a local change.

Thank you for the acceptance.

Thank you for your review. I have removed the changes to the bug description. Apologies, I did not realize it would alter the hash.