feat(coverage): Demangling C++ & Rust function names in coverage results #398
Conversation
Demangle C++ and Rust symbols using `c++filt` and `rustfilt`. We rely on those tools to be installed on the $PATH. I was also considering whether I should compile `c++filt` and / or `rustfilt` to WebAssembly, but decided against it, given that this would make the build much more complicated and it is currently unclear to me whether we will stick with the "traditional" tool chains (npm, webpack, cargo, ...) or if we will pivot to using Bazel.
vogelsgesang
requested review from
coeuvre,
jfirebaugh and
cameron-martin
as code owners
| // we prefer rustfilt over c++filt. For C++ mangled names, rustfilt | ||
| // will fail and we will fallback to c++filt. | ||
| // See https://internals.rust-lang.org/t/symbol-mangling-of-rust-vs-c/7222 | ||
| const demangled = |
There was a problem hiding this comment.
It's a shame that we don't know what language the lcov was generated from here. Is there no reasonable way of getting this info out of Bazel?
There was a problem hiding this comment.
The LCOV file from Bazel might even be merged across multiple different languages. E.g., if I run ./bazel coverage //..., Bazel will merge coverage between Java, C++ and Go test cases.
We could use some heuristic by looking at the file extension, but then again: What would we gain by doing so?
What is your underlying concern with trying multiple decoders and using the first one that can interpret the name?
There was a problem hiding this comment.
I was just concerned that a decoder could incorrectly demangle a symbol from another language. However, I'm not sure how likely this is and if this isn't possible to easily determine the language then I'm happy with this approach.
There was a problem hiding this comment.
I think we should be good here in almost all cases. As soon as we run into it, we will find a better solution 🙂
Demangle C++ and Rust symbols using
c++filtandrustfilt. We rely on those tools to be installed on the$PATH.I was also considering whether I should compile
c++filtand / orrustfiltto WebAssembly, but decided against it, given that this would make the build much more complicated and it is currently unclear to me whether we will stick with the "traditional" tool chains (npm, webpack, cargo, ...) or if we will pivot to using Bazel.