rust/compiler/rustc_codegen_llvm/src/coverageinfo, branch 1.76.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.76.02023-12-16T00:10:11+00:00coverage: Avoid creating `func_coverage` for marker statements2023-12-16T00:10:11+00:00ZalatharZalathar@users.noreply.github.com2023-12-12T02:49:19+00:00urn:sha1:c57f28bbf75572e10c6165c33a2aef922315fdb4
Coverage marker statements should have no effect on codegen, but in some cases
they could have the side-effect of creating a `func_coverage` entry for their
enclosing function. That can lead to an ICE for functions that don't actually
have any coverage spans.
rustc_codegen_llvm: Enforce `rustc::potential_query_instability` lint2023-12-12T12:16:14+00:00Martin Nordholtsmartin.nordholts@codetale.se2023-12-12T12:14:53+00:00urn:sha1:f44ccbab2bbdc538b739d6a1f5f9fbdb8339f8f8
Stop allowing `rustc::potential_query_instability` on all of
`rustc_codegen_llvm` and instead allow it on a case-by-case basis. In
this case, both instances are safe to allow.
coverage: Add `CoverageKind::SpanMarker` for including extra spans in MIR2023-12-08T11:40:49+00:00ZalatharZalathar@users.noreply.github.com2023-11-23T00:50:39+00:00urn:sha1:44b47aa976d6a6bdd7eb1f99a8ee5270afbe993e
There are cases where coverage instrumentation wants to show a span for some
syntax element, but there is no MIR node that naturally carries that span, so
the instrumentor can't see it.
MIR building can now use this new kind of coverage statement to deliberately
include those spans in MIR, attached to a dummy statement that has no other
effect.
merge `DefKind::Coroutine` into `DefKind::Closure`2023-11-26T13:05:08+00:00bohanbohan-zhang@foxmail.com2023-11-26T13:05:08+00:00urn:sha1:f23befe6c118573a2ca041bc89f959a8813b43a2Replace `custom_encodable` with `encodable`.2023-11-22T07:37:14+00:00Nicholas Nethercoten.nethercote@gmail.com2023-11-21T05:35:26+00:00urn:sha1:3ef9d4d0ed608b0493d66ffe8af2755529ce474c
By default, `newtype_index!` types get a default `Encodable`/`Decodable`
impl. You can opt out of this with `custom_encodable`. Opting out is the
opposite to how Rust normally works with autogenerated (derived) impls.
This commit inverts the behaviour, replacing `custom_encodable` with
`encodable` which opts into the default `Encodable`/`Decodable` impl.
Only 23 of the 59 `newtype_index!` occurrences need `encodable`.
Even better, there were eight crates with a dependency on
`rustc_serialize` just from unused default `Encodable`/`Decodable`
impls. This commit removes that dependency from those eight crates.
Fix `clippy::needless_borrow` in the compiler2023-11-21T19:13:40+00:00Nilstrieb48135649+Nilstrieb@users.noreply.github.com2023-11-21T19:07:32+00:00urn:sha1:21a870515b18e5b2b90435d0f1a6d3089b5217ae
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`.
Then I had to remove a few unnecessary parens and muts that were exposed
now.
coverage: Consistently remove unused counter IDs from expressions/mappings2023-10-27T22:33:48+00:00ZalatharZalathar@users.noreply.github.com2023-10-24T11:48:59+00:00urn:sha1:230dd5b8c71c1d176a6705bb458a473411788f68coverage: Emit the filenames section before encoding per-function mappings2023-10-22T12:17:15+00:00ZalatharZalathar@users.noreply.github.com2023-10-06T12:53:23+00:00urn:sha1:6af9fef08590fd499370a2f6cbbae9ceacf15336
Most coverage metadata is encoded into two sections in the final executable.
The `__llvm_covmap` section mostly just contains a list of filenames, while the
`__llvm_covfun` section contains encoded coverage maps for each instrumented
function.
The catch is that each per-function record also needs to contain a hash of the
filenames list that it refers to. Historically this was handled by assembling
most of the per-function data into a temporary list, then assembling the
filenames buffer, then using the filenames hash to emit the per-function data,
and then finally emitting the filenames table itself.
However, now that we build the filenames table up-front (via a separate
traversal of the per-function data), we can hash and emit that part first, and
then emit each of the per-function records immediately after building. This
removes the awkwardness of having to temporarily store nearly-complete
per-function records.
coverage: Encode function mappings without re-sorting them2023-10-22T09:37:39+00:00ZalatharZalathar@users.noreply.github.com2023-09-28T12:36:40+00:00urn:sha1:de4cfbca2ebec9c91037370146c518c069ece033
The main change here is that `VirtualFileMapping` now uses an internal hashmap
to de-duplicate incoming global file IDs. That removes the need for
`encode_mappings_for_function` to re-sort its mappings by filename in order to
de-duplicate them.
(We still de-duplicate runs of identical filenames to save work, but this is
not load-bearing for correctness, so a sort is not necessary.)
coverage: Encapsulate local-to-global file mappings2023-10-22T09:37:39+00:00ZalatharZalathar@users.noreply.github.com2023-09-28T12:36:40+00:00urn:sha1:88159cafa7444c6ec9cc521c1f8128d5ab777d29