In D64301#1574304, @rnk wrote:

I think @zturner wanted to teach lit to completely remove the Output/ directory for every test so we don't have to deal with stale files from previous tests hanging around. I remember objecting that we can't do that on startup since it's slow and not parallelized. However, I think we could probably add it as an early step to TestRunner.executeShTest so we don't have to add these extra 'rm' commands anymore.

Just a reminder, the DeleteFile API, and thus rm on Windows are async. See this. Occasionally, the tests are failing locally on my PC because of that (maybe 1 out of 50 times).

A bit more detail on what we're seeing on our end (specs in the post above). The 'Count' column represents the number of 1ms samples taken in that function. The 'Weight' column is cumulated times for all cores, for a given process, in ms.

Some quick stats on our end (running Windows 10 on a Intel W-2135, 6-core, 3.7 GHz, NVMe SSD): on a large .SLN compiling approx. 16,000 .CPP files through 600 unity .CPPs and 23,000 .H files, out of 86 secs spent in ClangScanDeps, about 32 secs are spent in DirectoryLookup::LookUpFile.

Case-insensitive on Linux as requested.

Thank you! :)

Ping!

Updated test.

LGTM! Thank you!

In D63453#1550865, @rnk wrote:
Still, I don't think that's a good reason not to do this change, although I certainly have less motivation now.

LGTM.

Thanks Anton!

Maybe Reid was talking about this icon, was it there before?

@thakis : Updated the existing test to fail without this patch.

You're right, there's indeed an issue, checking now.

In D60095#1528125, @rnk wrote:

I'm seeing a lot of LNK4099 warnings after this change, and Chromium links with -Werror. I also saw a fair number while doing some local testing with asan. I'll collect some more information, but I wanted to give a heads up that this might be problematic.

In D60095#1528125, @rnk wrote:

I'm seeing a lot of LNK4099 warnings after this change, and Chromium links with -Werror. I also saw a fair number while doing some local testing with asan. I'll collect some more information, but I wanted to give a heads up that this might be problematic.

Just for the record, the lldb tests issues above were caused first by a missing SWIG installation on my PC, then by using wrong SWIG version (4 instead if 3), and then my locale being fr_CA (which still causes a few tests to fail).

Will be fixed by D62772

LGTM! I'm less sure about the yaml->assembly change, but we could continue that offline :)
Maybe in a subsequent patch it'd be nice to fix obj2yaml IL part to avoid relying on SectionDatas.

I've noticed btw that obj2yaml/yaml2obj doesn't preserve the BinaryAnnotations if SectionData values are skimmed out of the .yaml (to reduce size). There's also something missing for S_FRAMEPROC in that regard:

@stella.stamenova : I'll have to revert it, I'm not sure what's going on. When I run the tests on my Windows PC, many tests are tagged as 'unsupported', I don't know why:

Unsupported Tests  : 796

Whereas on your build bot, there are no 'unsupported' tests:

Expected Passes    : 1596
Expected Failures  : 11
Unsupported Tests  : 46

If I try to manually run the test that fails on the bot: C:\Users\aganea\AppData\Local\Programs\Python\Python37-32\python.exe F:/svn/buildninja/./bin/llvm-lit.py -sv -vv -a F:\svn\lldb\lit\tools\lldb-mi\exec\exec-finish.test, I also get:

UNSUPPORTED: LLDB :: tools/lldb-mi/exec/exec-finish.test (1 of 1)
Test is unsupported

If I run the commands in the test manually, I get to a point where lldb-mi doesn't want to run:

F:\svn\buildninja\tools\lldb\lit>f:\svn\buildninja\bin\lldb-mi.exe
MI: Error: Driver. LLDB Debugger.
MI: Error: Driver Manager. Driver 'Machine Interface Driver Version: 1.0.0.9' (ID:'MIDriver') initialise failed. Driver. LLDB Debugger.

Any suggestions? I'll revert the patch in the meanwhile.

Looking now.

Thank you!

Ping @ruiu

Looks good, thanks!

The Interop.Dia2Lib.dll and the msdiaXXX.dll have to match. Try regsvr32.exe "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Packages\Debugger\msdia120.dll" (or look for msdia120.dll on your PC).

In D62347#1516136, @thakis wrote:

The "modernized" api is a good chunk wordier. Can you outline how composing launching would look like with and without this change?

You're right, I'll reduce it. There are a few unrelated changes that could be done after. I'll have to get back to you regarding the "without this change".

Thanks, I built it, but when I try to use it to load lld.pdb, it raises a "class not registered" exception, despite the fact that I followed the README.md instructions and registered msdia120.dll. DIA registration seems to be a continuing pain point in the Windows development world. :( I'll mess around with it.

Great stuff, thanks for doing this Reid! :) Inherently, this should make things a bit faster, it will also reduce cache misses.
We use a neat tool called Crunchersharp to have a broader overview:

If using -DLLVM_TOOL_LLDB_BUILD it now displays "Using /MD as required by LLDB."
If using -DLLVM_TOOL_LLDB_BUILD -DLLVM_USE_CRT_RELEASE=MT it displays "Disabling /MT as required by LLDB."
Otherwise /MT is the new default.

In D55056#1514451, @rnk wrote:

Previously I passed LLVM_USE_CRT_RELEASE=MT explicitly as part of my build, and I ran into the same problems with LLDB that you did. I'll try to modify this once it lands to warn when the user tries to do that. At the time, I couldn't see how to do it easily.