I ran local tests with this and a couple of the tests from the lldb suite failed:

yay!

In D60230#1454293, @ruiu wrote:

Does this mean a commit to lld could potentially break lldb?

Thanks!

In D60122#1453462, @stella.stamenova wrote:

This broke the LLDB tests on the Windows Bot:

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

This broke the LLDB tests on the Windows Bot:

LGTM

In D59847#1446671, @shafik wrote:

@stella.stamenova I committed a fix, please let me know if this does not address the regression:

http://llvm.org/viewvc/llvm-project?view=revision&revision=357210

This is causing failures on the windows bot. Please fix it or revert it.

This broke the Windows bot because now one of the TestPaths tests passes on Windows:

This caused a failure on the Windows bot:

This introduced a build break on Windows (which happened to coincide with another build break).

This is causing a failure on the Windows Bot:

This broke the windows LLDB bot:

This broke the windows bot:

LGTM. Now might not be the best time to commit it though because the LLDB build is broken on Windows.

In D58177#1397873, @labath wrote:

Thanks for the review Stella. I was hoping someone would step in and tell me that there is a better way to do that. However :), I see two problems with your proposal:

• build.py is a standalone file, and so it is not easy for it to share code with other stuff. This can be solved with some use_lldb_suite magic or moving the script some place else, but then comes the second problem:
• I am not sure these two use cases are actually compatible. Here I specifically want to "reinterpret_cast" binary bytes without doing any sort of encoding. The only place where to_string is used in build.py currently is on a value retrieved from the windows registry. I'm not 100% sure, but it seems to me that using utf8 encoding (which is what to_string is doing) is precisely the right thing to do there.
  
  With that in mind, I propose to do the following:
• leave build.py alone for now
• rename the new functions I'm introducing here to something less generic. Maybe bitcast_to_string and bitcast_to_bytes?
  
  WDYT?

This looks to have broken the windows build:

There's another patch (https://reviews.llvm.org/D54386/) which is fixing the fedora bot. You might want to leave that one.

This looks good. After it's checked in, it won't take effect until the master buildbot is updated though. You'd need @gkistanova to update it. She should also sign off on this.

This is failing on the windows bot:

This change broke one of the tests on Windows:

Build passes with VS now.

I am not sure if you saw this, but it looks like it broke one of the tests on the Windows bot:

@thakis Thanks for the information, I had actually missed that.

This change is causing build failures on Windows when using Visual Studio as the generator. It would also cause the same failure on for any other generator that supports multiple configurations.

I don't have a strong preference between using a separate module for interopability between python versions and implementing the functions as part of dotest if there are few of them, but I have to agree with @zturner that if we have more than a couple of functions, it makes sense to add them to an explicit module.

It looks like this change broke the windows bot:

In D57186#1372327, @craig.topper wrote:

@stella.stamenova I don't think reverting mine fixed it. I notice this commit was also around the same time, but isn't logged. http://llvm.org/viewvc/llvm-project?revision=352254&view=revision Does the bot also build lld and use it?

I haven't had time to look into it in details but it looks like either this change or https://reviews.llvm.org/D57259 broke the windows LLDB bot.

I haven't had time to look into it in details but it looks like either this change or https://reviews.llvm.org/D57186 broke the windows bot.

In D56548#1370711, @jyknight wrote:

In D56548#1370323, @stella.stamenova wrote:

One of the LLDB bots is still failing because of this change: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/978/steps/test/logs/stdio

Committed r352159 to fix this.

One of the LLDB bots is still failing because of this change: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/978/steps/test/logs/stdio

Thanks. You have to change a couple of the locations to '%T' though - '%t' is a file and '%T' is a directory - and you're using '%t' as a directory in a couple of the places.

It looks like this change broke a number of the LLDB tests:

TestFunctionRefs is failing on the Windows bot: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/677

The Windows Buildbot is failing because of one of the tests (SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s) added in this change. You can see the failure here: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/666. It looks like it is checking for the wrong path on Windows: