Skip to content

Conversation

@ian-twilightcoder
Copy link
Contributor

@ian-twilightcoder ian-twilightcoder commented Jan 6, 2026

Cyndy suggested that the reason I was seeing lld-repro.c fail wasn't because lld doesn't support Darwin, but rather I had a swiftlang branch checked out when I built lld (which has Darwin support explicitly disabled), and lld didn't rebuild when I switched to an llvm branch. That appears to be the case, so set lld as a dependency of the clang tests.

@llvmbot llvmbot added the clang Clang issues not falling into any other category label Jan 6, 2026
@llvmbot
Copy link
Member

llvmbot commented Jan 6, 2026

@llvm/pr-subscribers-clang

Author: Ian Anderson (ian-twilightcoder)

Changes

Cyndy suggested that the reason I was seeing lld-repro.c fail wasn't because lld doesn't support Darwin, but rather I had a swiftlang branch checked out when I build lld (which has Darwin support explicitly disabled), and lld didn't rebuild when I switched to an llvm branch. That appears to be the case, so set lld as a dependency of the clang tests.


Full diff: https://github.com/llvm/llvm-project/pull/174512.diff

1 Files Affected:

  • (modified) clang/test/CMakeLists.txt (+4)
diff --git a/clang/test/CMakeLists.txt b/clang/test/CMakeLists.txt
index 3faf3d7d5f2aa..bee19fd375d3e 100644
--- a/clang/test/CMakeLists.txt
+++ b/clang/test/CMakeLists.txt
@@ -185,6 +185,10 @@ if( NOT CLANG_BUILT_STANDALONE )
     yaml2obj
     )
 
+  if(TARGET lld)
+    list(APPEND CLANG_TEST_DEPS lld)
+  endif()
+
   if(TARGET llvm-lto)
     list(APPEND CLANG_TEST_DEPS llvm-lto)
   endif()

Copy link
Member

@cyndyishida cyndyishida left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I didn't mean to add more work for you 🙈 This approach looks strictly correct, so LGTM, but it would be nice if the test were layered differently to avoid the dependency on lld for check-clang.

I.e., didn't actually invoke & check the output of lld. It would instead emit whatever reproduction info was necessary (contents of linker-crash*.tar), and that was checked. Then a test in the LLD sub-project verified that output without invoking clang. I don't know enough to say that's practical, though. Please wait a day before merging in case anyone else may have comments.

@perry-ca
Copy link
Contributor

perry-ca commented Jan 6, 2026

Looks good. Thinking along the lines that Cyndy is, should the support for lld/lto be captured in a resource so we can clean up the REQUIRE:/UNSUPPORTED: lines in the test cases?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clang Clang issues not falling into any other category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants