Looks like this broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/20566

In D128230#3606600, @stellaraccident wrote:

Thank you for this. As we discussed on Discord, I didn't know about the inheritable sources on interface libraries, and that simplifies things. A couple of comments for my own education, but otherwise looks good.

Have you happened to have tested this with a downstream yet?

This broke the Windows LLDB bot:

In D125943#3587778, @wallace wrote:

@stella.stamenova, I've just tried that compile command with several versions of gcc, including g++ (GCC) 8.5.0 on CentOS and got no error Sadly I couldn't install 7.3.1. Could you try again in top of tree?

In D125943#3586910, @wallace wrote:

yes, i'm trying to fix it now. Thanks!

These changes (the set of [trace][intelpt] changes) broke the windows lldb bot. It's most likely this particular change, but it could be one of the others. Unfortunately, the bot had just been broken by https://reviews.llvm.org/D127882, so it didn't show the failure until that was reverted:

LGTM

Make clang-format happy

In D125284#3502410, @stellaraccident wrote:

I am glad that an actual Windows dev (versus someone who just occasionally plays one on TV) is looking at this. I've never understood the windows debug/release/runtime version dichotomies when not just working on a stock VS based project that automatically does the right thing.

I'm fine with landing if we special case the header like I suggest. Otherwise, open to discuss more.

I'll need to check when I'm back online, but I could have sworn we had this enabled on a bot somewhere (I've broken it before). But in any case, +1 on more coverage.

In D125122#3497606, @stellaraccident wrote:

Thanks for the fixes. I'm out today but will have a detailed look this weekend. Over time, I've tried to keep these things working for Windows but we must be building with a Windows setup that doesn't tickle the weird bits.

One request: can we special case the copy_if_different thing for Windows only. Symlinks are pretty convenient for dev because you can just edit/run, and I'd prefer to not regress that too account for this weird Windows-ism.

@mehdi_amini : This patch does not quite work because of the built-in calling convention (https://github.com/llvm/llvm-project-staging/blob/cc926dc3a87af7023aa9b6c392347a0a8ed6949b/mlir/docs/LLVMDialectMemRefConvention.md). Was the goal with the clang-tidy change to also change the convention? I could fix it the other way and undo the clang-tidy to these specific functions instead. This would be a smaller change.

This change introduced a race condition in the mlir build. We're now occasionally seeing:

Looks like this broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/18228

We are seeing an error when building on Ubuntu with warnings treated as errors after this change:

I think this broke the windows mlir bot: https://lab.llvm.org/buildbot/#/builders/13/builds/17954/steps/6/logs/stdio

It looks like this broke the windows lldb bot:

LGTM

It looks like the new test is failing on the Windows bot:

It looks like there's a failure that was previously hidden by the unexpected passes:

LGTM, I think there might be a couple more places to remove the xfail, but otherwise ship it!

They should correspond to these files:

This broke the windows bot in the best way possible - by making some tests pass now that didn't use to. Could you un-xfail those too?

Disabling the watchpoint tests was sufficient to get the buildbot happy, so we no longer have need of this.

Add more details for developer command prompt