With the latest VS 2019, the error is still the same (MSVC 19.24).

No difference (I would have been surprised, really, as the issue doesn't appear to be with the way the constructor is declared, but with how it is used):

In D72310#1820632, @nicolasvasilache wrote:

my apologies, I lost track of this and do not have an easy repro atm, Aart is taking a shot at it.

This also broke a number of the tests on the Windows LLDB bot, so when you get around to resubmitting the change with a fix, please make sure the bot doesn't get broken again: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12551

This introduced a failure on the Windows LLDB bot (there were already other failing tests though, so maybe you missed it):

This broke the Windows LLDB bot:

It looks like this also caused a failure on the Windows LLDB bot:

This broke the windows LLDB bot:

Sorry, I was out on vacation until today :).

Sadly, I think this broke the windows bot now (assuming it got applied to staging, otherwise I have to figure out what did):

This is broken on Windows. I moved the Buildbot to staging to resolve some of the issues with the move to the monorepo, so you can see the failures here:

Thanks @labath

Oh, and TestCallOverridenMethod still has some failures on Windows:

In D68130#1713620, @teemperor wrote:

Yeah, seems like constructing objects in expressions isn't implemented on Windows. I'm not sure if there is a reliable way to test that constructors aren't shadowed by these global functions if constructors themselves don't work on Windows, but I filed llvm.org/pr43707 for the underlying bug and x-failed the tests. Will push in a few minutes.

Unfortunately, this is failing on the windows bot:

Please also file a bug and reference it in the skip statement.

The tests passed in my setup. After you commit this, please monitor the windows Buildbot (it currently has a couple of failures, so you will have to check it and not rely on an email).

This is causing a failure on the Windows Bot:

In D68980#1709967, @mstorsjo wrote:

In D68980#1709931, @labath wrote:

In D68980#1709884, @stella.stamenova wrote:

The two things that come to mind are the path to clang-cl (which is sometimes a clang build and sometimes installed on the system as part of a VS installation or an LLVM installation) as well as the path to the linker when it is needed. This is most often an issue in the case of a VS install - I don't remember all the details any more, but I believe that before Zach added the script, we were often picking up the wrong clang-cl and ending up not being able to compile the tests at all.

Thanks.

Was this during a standalone lldb build? In a non-standalone build, lit should definitely prefer the just-built clang/lld (and if it doesn't, it should be fixed to do that). The situation is more complicated for a standalone build because the clang binary is sort of out of our control. But, in this case, I don't see how having build.py around can help, because the information about which clang to use has to come externally anyway...

How do tests like test/Shell/Register/x86*.test work in such standalone builds then? They use lines like these:

# XFAIL: system-windows
# REQUIRES: native && target-x86_64
# RUN: %clangxx -fomit-frame-pointer %p/Inputs/x86-64-gp-read.cpp -o %t
# RUN: %lldb -b -s %s %t | FileCheck %s

(The XFAIL for system-windows, at least in this test, when I tried it out, seemed to relate to the fact that register read --all on windows didn't include all the 32 bit subregisters.)

If tests already can use such constrcuts, I don't see why we couldn't use # RUN: %clang_cl .., as lit sets up %clang_cl in the same way as %clangxx.

In D68980#1709968, @mstorsjo wrote:

In D68980#1709954, @stella.stamenova wrote:

Both. Again, it's been a long time, but when we use VS for building, the environment already contains a path to clang-cl so regardless of whether the build is standalone or not, the build gets confused about which clang-cl to use. @mstorsjo might want to update the tests to use clang-cl but then make sure that the update works on the Windows Buildbot (or similar environment) before committing.

Is there any way of checking whether it works on this buildbot, other than committing (after doing best effort testing of it in whatever comparable windows environments I have available)?

In D68980#1709931, @labath wrote:

In D68980#1709884, @stella.stamenova wrote:

The two things that come to mind are the path to clang-cl (which is sometimes a clang build and sometimes installed on the system as part of a VS installation or an LLVM installation) as well as the path to the linker when it is needed. This is most often an issue in the case of a VS install - I don't remember all the details any more, but I believe that before Zach added the script, we were often picking up the wrong clang-cl and ending up not being able to compile the tests at all.

Thanks.

Was this during a standalone lldb build? In a non-standalone build, lit should definitely prefer the just-built clang/lld (and if it doesn't, it should be fixed to do that). The situation is more complicated for a standalone build because the clang binary is sort of out of our control. But, in this case, I don't see how having build.py around can help, because the information about which clang to use has to come externally anyway...

In D68980#1709866, @labath wrote:

In D68980#1709830, @stella.stamenova wrote:

I suspect that using clang-cl directly will not work though - the script does a lot of the setup needed to run clang-cl correctly today (previously the environment for clang-cl was not setup correctly and the tests either didn't pass or passed for the wrong reasons, so using build.py has been a huge improvement).

Can you elaborate on what kind of setup do you have in mind here? Bear in mind that here we are only talking about tests that do not use any system libraries or headers, and which already run fine on a linux system which does not have any windows-specific stuff installed. With those restrictions, I don't see what can be possibly gained from using build.py. The only thing I can see it possibly doing is to clear some environment variables which might otherwise be present and confuse clang-cl. However, that's something that can be easily done in lit.

I haven't fully debugged this, but it looks like this change caused a failure on the Windows LLDB bot. There was already another failure, so you probably didn't get an email:

This change looks fine assuming all the tests continue to pass.

This is still failing on the Windows bot. Please fix it ASAP or revert it.

In D67347#1706405, @stella.stamenova wrote:

It looks like this changed fixed at least one of the XFAILed tests on Windows:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9751

So now the test results would be red because of the unexpectedly passing test (if there wasn't another failure). Could you have a look at whether any of the other tests that were XFAILed for the same bug are also now passing and remove the expected failure tags as appropriate?

It looks like this changed fixed at least one of the XFAILed tests on Windows:

This is failing on the windows bot. There was already another failure, so you probably didn't get an email:

It looks like this broke one of the tests on the Windows LLDB bot:

The windows LLDB bot also has the same failure: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9600

Thanks for taking care of this!

This broke the windows build: http://lab.llvm.org:8011/buildslaves/win-py3-buildbot. There was already a test broken from earlier today, so you might not have gotten an email.

This broke the windows bot. A couple of other issues have shown up and been fixed since, but this change is still causing a break:

This broke the windows bot:

LGTM as long as all the tests still pass

Is there a way to reduce some of the code duplication? The more duplication there is, the harder it is to maintain.

It looks like this broke the windows build bot:

LGTM. Please monitor the windows Buildbot to make sure it still passes after your commit though.

I think this is actually fine. The change that was needed for multi-configuration generators is how the two default paths for the compilers are set. The USE variables were to make it explicit when we will or we won't override the user-set compiler. As long as we are OK overriding it if they set it to an empty string (which is probably an error, anyway), this change is good.

LGTM

It looks like this changed caused 30 or so of the tests to fail on the Windows bot. It was already broken, so you wouldn't have gotten an email:

This change caused failures on the Windows bot: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7681 compounding on the existing failures from [lldb] Refactor guard variable checks in IRForTarget

The windows bot for LLDB is still broken after the partial fix for the breakage:

@mgorny Could you download the patch and see if it fixes your scenario? I tested it on both Ubuntu and Linux, but neither installation of LLVM I have actually contains FileCheck or not, so my setup is not entirely the same as yours.

Yes, it was! Thanks for catching that :)

Test passes now. Thanks!

LGTM. Please keep an eye on the bot after you commit though

I am able to do some testing as well.

HERE: useExternalSh: False

This actually breaks the lit tests on Windows when the path to Python has spaces. For example:

It is indeed https://reviews.llvm.org/D65156 which introduced the failure

It could be either actually. I'll run the tests with just the first one and see if it reproduces. I *think* it's this one.

This actually breaks the lit tests on Windows when the path to Python has spaces. For example:

One failure:

I'll run some tests and let you know the result.

I think you need one small change for lld still - to make it clear that it is required on Windows in the Windows section, but it looks good otherwise. Please fix that before committing.

Re: Windows CMake: I am not sure, I'd have to do look into it further.

LGTM!

This broke the Windows LLDB bot: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/6493/steps/build/logs/stdio

I am not sure if you've seen this yet, but this broke the Windows LLDB bot: