[all-commits] [llvm/llvm-project] 552e68: [lldb][test] Don't treat 'xcrun clang' as a path f...

[Raphael Isemann via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 552e68d6acec45a9628ec4db279c511adbde062a
      https://github.com/llvm/llvm-project/commit/552e68d6acec45a9628ec4db279c511adbde062a
  Author: Raphael Isemann <rise at apple.com>
  Date:   2026-03-27 (Fri, 27 Mar 2026)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/builders/builder.py

  Log Message:
  -----------
  [lldb][test] Don't treat 'xcrun clang' as a path for finding clang++ (#188235)

[lldb][test] Don't treat 'xcrun clang' as a path for finding clang++
TestPrintObjectArray.py uses `xcrun clang` as the test compiler.
This is because the test source requires some Objective-C features
that are only available in downstream clang:

```
self.build(dictionary=[...], compiler="xcrun clang")
```

However, this currently just results in us running `clang++`
instead of `xcrun clang++` to compile test sources. If the downstream
`clang++` in PATH is not Apple's downstream version, this then causes
the tests to fail with compilation errors:

```
clang++: error: unknown argument: '-fno-constant-nsnumber-literals'
clang++: error: unknown argument: '-fno-constant-nsarray-literals'
clang++: error: unknown argument: '-fno-constant-nsdictionary-literals'
```

We end up in this situation as we treat this command as a path when
trying to assemble the `clang++` command. This patch just adds a
special case for `xcrun` and we now first try the compiler (verbatim)
before falling back to the inferred compiler type.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications