assert prevents `refresh.template.py` from handling custom CC toolchains

[lukasoyen]

Steps to reproduce:

• clone https://github.com/bazelbuild/examples/tree/main/cpp-tutorial/stage3
• add the grailbio LLVM toolchain as per their quickstart (don't forget the line in .bazelrc)
• add the snippet to include the compile-commands-extractor
• run bazelisk run @hedron_compile_commands//:refresh_all

Output:

  File "$HOME/.cache/bazel/_bazel/008ff1d9dbee3b1e6642ec19c761ba55/execroot/__main__/bazel-out/k8-fastbuild/bin/external/hedron_compile_commands/extract.runfiles/hedron_compile_commands/extract.py", line 128, in _check_in_clang_args_format
    assert re.search(r'(?:clang|clang\+\+|gcc|g\+\+)(?:-[0-9\.]+)?$', compile_args[0]), f"Compiler doesn't look like normal clang/gcc. Time to add windows support? CMD: {compile_args}"
AssertionError: Compiler doesn't look like normal clang/gcc. Time to add windows support? CMD: ['external/llvm_toolchain/bin/cc_wrapper.sh', '--target=x86_64-unknown-linux-gnu', '-U_FORTIFY_SOURCE', '-fstack-protector', '-fno-omit-frame-pointer', '-fcolor-diagnostics', '-Wall', '-Wthread-safety', '-Wself-assign', '-std=c++17', '-stdlib=libc++', '-MD', '-MF', 'bazel-out/k8-fastbuild/bin/lib/_objs/hello-time/hello-time.pic.d', '-frandom-seed=bazel-out/k8-fastbuild/bin/lib/_objs/hello-time/hello-time.pic.o', '-fPIC', '-iquote', '.', '-iquote', 'bazel-out/k8-fastbuild/bin', '-no-canonical-prefixes', '-Wno-builtin-macro-redefined', '-D__DATE__="redacted"', '-D__TIMESTAMP__="redacted"', '-D__TIME__="redacted"', '-fdebug-prefix-map=external/llvm_toolchain_llvm/=__bazel_toolchain_llvm_repo__/', '-c', 'lib/hello-time.cc', '-o', 'bazel-out/k8-fastbuild/bin/lib/_objs/hello-time/hello-time.pic.o']

extract.py does not like the external/llvm_toolchain/bin/cc_wrapper.sh script. If we fix that regex to also accept the wrapper script, we get: FileNotFoundError: [Errno 2] No such file or directory: 'external/llvm_toolchain/bin/cc_wrapper.sh': 'external/llvm_toolchain/bin/cc_wrapper.sh'. If that file happens to be vendored in the workspace and just call to a binary from an external repository, the call inside the wrapper script fails.

Not sure what a good way to solve this would be.

[cpsauer]

Hello again, Lukas!

What's happening here is that the grailbio toolchain wraps its compilers inside shell scripts, rather than just enabling direct use of the compilers. clangd can't peer through the wrapper scripts Bazel itself uses by default on, e.g., Apple platforms, so we'd added code to de-bazel those wrappers, and added that (perhaps over zealous) assert to enforce the assumption that the platform-specific unwrap code was doing its job. But I think clangd should be able to peer through these particular llvm wrappers--I'd just wrongly assumed that the wrappers were an Bazel-Apple-specific one-off.

The fix goes like this:

1. I've just pushed a commit that disables that assert, since it's not a good assumption in this case. Sorry about that. Please update your hash to get a new copy of this code :)
2. The FileNotFoundError is just coming from needing to add the external symlink from the readme. To add it: ln -s bazel-out/../../../external . More on how/whether to remove symlinks in #14, but for the sake of this example, let's go with it.
3. No step three. I'm then seeing that things then work :)

If you're seeing problems finding standard library headers (and have checked via external that bazel has indeed downloaded them), then you might need to pass the --query-driver=external/llvm_toolchain/bin/cc_wrapper.sh flag to clangd to tell it to interrogate the wrapper script, the same way we pass the other flags in the README. More docs on that here: https://clangd.llvm.org/troubleshooting. To be clear, I'm not seeing that issue in my quick tests over here, but I'm on macOS. If you do run into this case let me know. I'd be great to get that part of the fix into the docs.

---

I'm going to close this (optimistically), but if that fix isn't working, lmk, and I'll reopen it and jump right back in with you.

Chris

[cpsauer]

^ Note, there were probably some issues, requiring the --query-driver. See #33. Should have been recommended to everyone in 8b16750