Philipp Stephani
Philipp Stephani
I too think that the commands should all be run remotely. This provides an obvious form of consistency: a command is guaranteed to work exactly as if run locally on...
In general the typical strategy to support remote filenames is: - Run all processes remotely using `process-file`, `start-file-process`, etc. - Such remote processes accept local filenames on the remote system....
I'm quite sure this is still happening. In fact, with Bazel 7 (after https://github.com/bazelbuild/apple_support/pull/113), the C++-only toolchain is enabled by default, so coverage support on macOS is now broken by...
After experimenting a bit, I managed to at least create something that looks like a valid coverage.dat file on macOS with Bazel 7: ``` bazel coverage --test_env=COVERAGE_GCOV_PATH=/Library/Developer/CommandLineTools/usr/bin/llvm-profdata --test_env=BAZEL_USE_LLVM_NATIVE_COVERAGE=1 --test_env=LLVM_COV=/tmp/llvm-cov --experimental_generate_llvm_lcov...
> `BAZEL_USE_LLVM_NATIVE_COVERAGE` shouldn't be necessary on macOS ack, thanks > I don't see how bazel is supposed to be discovering llvm-cov and llvm-profdata, seems like there might need to be...
> Passing `--cxxopt=-ffile-compilation-dir=.` helps (as long as your compiler version supports it). At least 1 of the failure causes is the covered files don't exist with sandboxing and works in...
https://github.com/protocolbuffers/protobuf/issues/6049 also looks related.
Speedbar uses Imenu by default. The only thing that should be necessary is ```elisp (speedbar-add-supported-extension ".go") ```
I've resolved the conflict; please take another look.