pub struct Counts {
pub checked: usize,
pub live: usize,
pub derived: usize,
pub skipped: usize,
pub judged: usize,
pub carried: usize,
pub asked: usize,
pub wrote: usize,
pub filled: usize,
pub moved: usize,
pub promised: usize,
pub scoped: usize,
}Expand description
How many checks a run of insert put in.
Reported rather than discarded because the number of checks a function starts with is the denominator of everything document 13 measures, and it is not recoverable later: by the time the optimizer has run, the checks that were discharged are gone and nothing says how many there were.
The three counts are kept apart rather than added up because they are discharged by different rules and at very different rates. Document 07 expects bounds to go away often, lifetime to go away when the instance does not escape, and derivation to survive, so one number would hide exactly the thing the measurement is for.
Fields§
§checked: usizeAccesses that were given a bounds check.
live: usizeAccesses that were given a lifetime check, which is the same set as checked.
derived: usizePointers computed from another pointer that were given a derivation check.
skipped: usizeAccesses that got nothing, because the pointer they go through is not a value this pass can take the capability of.
judged: usizeStores that recorded what the bytes they wrote were stored through.
Not in --emit=safety-summary yet, which is the one count here that is not. The summary
reports a class as a pair, how many went in and how many are left, and nothing discharges a
plane write today, so the pair would be one number written twice. It goes in beside the
first rule that removes one.
carried: usizeCopies that carried whatever the bytes they read said over to the bytes they wrote.
Kept apart from judged for the reason the three check counts are kept apart. A store
records a type the compiler knows and a copy records one only the plane knows, so the two
are discharged by different rules: a store into storage nothing watches can be dropped by
looking at the store, and a copy cannot be looked at the same way.
asked: usizeAccesses that asked the plane whether the bytes agree with the type they name.
Fewer than checked, and the reason is in ask: an access the front end did not name a
type for has no question to put. Without -fsafety-subobject it is fewer again, because
only a read asks, and the reason a store asks only when somebody asked for it is on
rucc_session::Subobject.
wrote: usizeStores that recorded that the bytes they wrote hold what they wrote.
The same set as checked minus the reads, and unlike judged it does not thin: a store
records into the init plane whatever it was storing through, because what the init plane
holds is whether anything was stored at all.
filled: usizeReads that asked the plane whether anything ever wrote the bytes they are about to read.
The same set as the reads in checked, and unlike asked it does not thin: the question is
whether the bytes hold anything at all, which is a question about every read whatever type
the front end did or did not name for it.
moved: usizeCopies that carried whether the bytes they read held anything over to the bytes they wrote.
The same set as carried, and counted beside it for the reason wrote is counted beside
judged: the two planes will be discharged by different rules, so the day one of them
thins the numbers have to be able to differ.
promised: usizeAccesses that asked their block whether another restrict pointer of it got there first.
Zero without -fsafety-restrict, and zero in the overwhelming majority of functions with
it, because the only accesses that ask are the ones the front end traced back to a
restrict declaration. promise is where both of those are argued.
scoped: usizeBlocks that opened a scope, which is one per restrict clique that has an access in it.
Kept apart from promised because it is the part of the cost that is paid per call rather
than per access: two calls and a stack slot, against which a block that checks a thousand
accesses and a block that checks one look very different.