Specifically, the version of libc++ that lives alongside the c-index-test
binary. After r348365 driver relies on a correct value of argv[0] to find
libc++ and 'c-index-test' did not pass proper argv[0] when calling the
driver.
Details
- Reviewers
thakis ioeric EricWF arphaman dexonsmith
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 27884 Build 27883: arc lint + arc unit
Event Timeline
I'm not sure who the owners of c-index-test are, so adding people who touched the file recently or might be interested in this landing.
Suggestions for other reviewers are very welcome.
Still struggling to make one test pass: Index/index-file.cu fails with:
.../index-file.cu:8:20: error: CHECK-HOST-NOT: excluded string found in input // CHECK-HOST-NOT: macro definition=__CUDA_ARCH__ ^ <stdin>:3631:48: note: found here // CHECK: __clang_cuda_runtime_wrapper.h:77:9: macro definition=__CUDA_ARCH__ Extent=[77:9 - 77:26]
The catch is that I see this line both after and before my change when I run the corresponding invocation of c-index-test with --cuda-host-only by hand.
Any ideas why this might be happening? How do I emulate the environment of llvm-lit completely to get a repro?
Looking at D54630, it seems arphaman and dexonsmith are probalby good reviewers for this.
The real problem is that clang_parseTranslationUnit2 is broken, so this just fixes one client, c-index-test. All other macOS clients that call that function will still be unable to find the libc++ headers.
clang_parseTranslationUnit2 should try to infer the binary directory based on the libclang path. Libclang already does that for -resource-dir, see (CIndexer::getClangResourceDir). I think that you should set the clang path to CINdexer::getClangToolchainPath()/bin/clang, and that should fix the issue.
@arphaman, thanks for pointing this out. It's definitely nice to change stuff only in one place.
There are two issues still pending:
- index-file.cu still fails, I haven't looked into it closely yet, any idea why that might be happening?; repro is simple, just patch this in locally and run the test.
- I'm not sure it's safe to use temporary storage for argv[0] in clang_parseTranslationUnit2. The resulting translation units probably holds references to argv and is free to read the data later. A simple and safe alternative would be to store this string in CIndexer and return a reference here. Does that LG?
No idea why it fails, I'll try to take a look.
- I'm not sure it's safe to use temporary storage for argv[0] in clang_parseTranslationUnit2. The resulting translation units probably holds references to argv and is free to read the data later. A simple and safe alternative would be to store this string in CIndexer and return a reference here. Does that LG?
Yes, that would be better. Let's store the string in CIndexer like we do for toolchain path and the resource dir.
Lost this one after vacation, sorry.
Still need to figure out why the test is failing. Any help appreaciated