-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove LLVMRustCoverageHashCString
#113430
Conversation
r? @b-naber (rustbot has picked a reviewer for you, use r? to override) |
This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp. |
@rustbot label +A-code-coverage |
I've tested this locally in two ways:
|
I noticed that the string being hashed also doesn't need to be cloned with |
e9666a1
to
8d86dbb
Compare
A symbol already contains a `&str`, and in this context there's no need to make an owned copy, so we can just use the original string reference.
…ector The function body immediately treats it as a slice anyway, so this just makes it possible to call the hash function with arbitrary read-only byte slices.
The Rust-side declaration uses `libc::size_t` for the number of bytes, but the C++ declaration was using `unsigned` instead of `size_t`.
Coverage has two FFI functions for computing the hash of a byte string. One takes a ptr/len pair, and the other takes a NUL-terminated C string. But on closer inspection, the C string version is unnecessary. The calling-side code converts a Rust `&str` into a C string, and the C++ code then immediately turns it back into a ptr/len string before actually hashing it.
@bors r+ rollup |
⌛ Testing commit 352d031 with merge acdec7cc8e385d6fbaeb432fac1206829b883586... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Looks spurious. @bors r+ rollup |
💡 This pull request was already approved, no need to approve it again.
|
@bors r- |
@bors retry |
@bors r=b-naber |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ffb9b61): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 657.636s -> 659.067s (0.22%) |
Coverage has two FFI functions for computing the hash of a byte string. One takes a ptr/len pair (
LLVMRustCoverageHashByteArray
), and the other takes a NUL-terminated C string (LLVMRustCoverageHashCString
).But on closer inspection, the C string version is unnecessary. The calling-side code converts a Rust
&str
into aCString
, and the C++ code then immediately turns it back into a ptr/len string before actually hashing it. So we can just call the ptr/len version directly instead.This PR also fixes a bug in the C++ declaration of
LLVMRustCoverageHashByteArray
. It should besize_t
, since that's what is declared and passed on the Rust side, and it's whatStrRef
's constructor expects to receive on the callee side.