In D117779#4497748, @kastiglione wrote:

@broadwaylamb hi, have you been using the PointerUnion formatter? We have seen a variety of issues, which don't seem to have easy fixes. If you're not using it, I will disable it. Alternatively, I propose creating a separate file that you and others could choose to import separately from lldbDataFormatters.py.

In D117779#3258798, @kastiglione wrote:

I take it these expression evaluations are necessary?

Address review comments

LGTM

Support --test-executable in run.py, update config.py to always pass the new argument.

We're having the same issue on our buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/3013

D85032 has landed, this patch is not needed anymore.

Make the path() member function of TempDir non-template.

ping

@sammccall could you please take a look?

Address review comments, change some tests that didn't use the RAII objects to use them where appropriate.

In D83490#2177256, @vvereschaka wrote:

• looks like ssh.py arguments have been changed since the diff file was placed. Currently the correct string for COMPILER_RT_EMULATOR is the following:

set(COMPILER_RT_EMULATOR                "\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/libcxx/utils/ssh.py\\\" --execdir %%T --host ${REMOTE_TEST_USER}@${REMOTE_TEST_HOST} %%t" CACHE STRING "")

I've verified that it works with the test suites that you've mentioned, and also compiler-rt tests. I'm going to commit it now.

Remove redundant conversion of a list comprehension to list.

Replace %% with #_MARKER_# before each substitution.

Address the review comments

Could you please explain why D83486 broke this test and what does PowerPC have to do with it? I’m just curious.

In rG5ab446cfe5503fd4431a94db4d741cf3b5fdcd15#931971, @amyk wrote:

Hi!
I believe this patch is causing sanitizer failures for PowerPC on the following buildbots:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux
http://lab.llvm.org:8011/builders/clang-ppc64be-linux
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt

Could you please fix or pull the changeset?

In D83429#2142066, @ldionne wrote:

Is it not possible to satisfy this convention in the compiler-rt tests?

@compnerd thank your for responding so fast!

In D83485#2141930, @compnerd wrote:

Can you add an explanation for why the conversion to ascii was removed? I don't immediately see why that is needed, not that ascii is a great choice.

Gentle ping.

In D70815#2108406, @raahlb wrote:

In D70815#1768359, @mstorsjo wrote:

I went ahead and reverted this, as it broke how some cmake tests within libunwind work.

As this disables linking, it falsely makes any test succeed that depends on linking, and there's a few such tests in cmake/config-ix.cmake (check_library_exists(c fopen "" LIBUNWIND_HAS_C_LIB), check_library_exists(dl dladdr "" LIBUNWIND_HAS_DL_LIB), etc).

Therefore, set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) has to be carefully placed at a spot where all such tests that does require linking already has been completed.

This was fixed in a later commit, correct?

In D79892#2072039, @phosek wrote:

Do you have commit permissions or do you need us to land this for you?

@compnerd can I ask you to take a look?

ping

ping

Copy the logic of setting execute_external from lit.common.cfg.py.

Reimplement CWDGuard using POSIX functions.

In D78200#2025807, @EricWF wrote:

Buildbot's Git module allows you to pass in a config object, so I don't understand the problem.
http://docs.buildbot.net/0.8.9/manual/cfg-buildsteps.html#git

Are you using an even older version of Buildbot?
If so you can always insert the symlink config option by putting it in a .gitconfig file.

In D78200#2023624, @smeenai wrote:

Sorry for jumping in without context, but wanted to chime in on one thing.

Windows doesn't really have a concept of symlinks. So, when the monorepo is cloned, those symlinks turn to ordinary text files. Previously, if we cross-compiled libc++ for some symlink-friendly system (e. g. Linux) and ran tests on the target system, some tests would fail.

This isn't right. Windows has supported symbolic links since Vista. The big limitation was that you needed to be in an elevated process to be able to create symbolic links. Windows 10 lifted that limitation in Developer Mode starting with the April 2017 release (https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/). If git for Windows isn't creating symbolic links properly, that's a git issue and not a Windows issue (although I recognize it doesn't make much difference for the end user). Some searching suggests that you should be able to configure Git on Windows to handle symlinks correctly (https://github.com/libgit2/libgit2/pull/4713, and https://github.community/t5/How-to-use-Git-and-GitHub/git-bash-symbolic-links-on-windows/m-p/11488#M3732 shows an option to enable symbolic links when running the setup).

In D78200#2023574, @ldionne wrote:

If we can solve this problem differently, I'm all for it. One possibility would be to store a tarball of the static environment in the source tree, and then automatically untar it only when on the target system -- this way Windows would never see any symlinks. Thoughts?

I've reverted the commit.

I'm sorry, I've messed up. I first committed this as rG645ad5badbabdeca31de5c98ea8135c5a6e7d710, but then realized that I've committed the previous version of this patch. So I reverted it and recommitted as 52cc8bac7780dbfb90dcc8cfe24696618eeaa06e.

Update the diff to reflect the committed changes

@ldionne @EricWF am I getting it right that this patch is the wrong direction? How the described Windows issue could be resolved otherwise?

ping