Trait rustc_mir::dataflow::BitDenotation[][src]

pub trait BitDenotation: BitwiseOperator {
    type Idx: Idx;
    fn name() -> &'static str;
fn bits_per_block(&self) -> usize;
fn start_block_effect(&self, entry_set: &mut IdxSet<Self::Idx>);
fn statement_effect(
        &self,
        sets: &mut BlockSets<Self::Idx>,
        location: Location
    );
fn terminator_effect(
        &self,
        sets: &mut BlockSets<Self::Idx>,
        location: Location
    );
fn propagate_call_return(
        &self,
        in_out: &mut IdxSet<Self::Idx>,
        call_bb: BasicBlock,
        dest_bb: BasicBlock,
        dest_place: &Place
    ); fn accumulates_intrablock_state() -> bool { ... }
fn before_statement_effect(
        &self,
        _sets: &mut BlockSets<Self::Idx>,
        _location: Location
    ) { ... }
fn before_terminator_effect(
        &self,
        _sets: &mut BlockSets<Self::Idx>,
        _location: Location
    ) { ... } }
🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Associated Types

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Specifies what index type is used to access the bitvector.

Required Methods

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

A name describing the dataflow analysis that this BitDenotation is supporting. The name should be something suitable for plugging in as part of a filename e.g. avoid space-characters or other things that tend to look bad on a file system, like slashes or periods. It is also better for the name to be reasonably short, again because it will be plugged into a filename.

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Size of each bitvector allocated for each block in the analysis.

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Mutates the entry set according to the effects that have been established prior to entering the start block. This can't access the gen/kill sets, because these won't be accounted for correctly.

(For example, establishing the call arguments.)

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Mutates the block-sets (the flow sets for the given basic block) according to the effects of evaluating statement.

This is used, in particular, for building up the "transfer-function" representing the overall-effect of the block, represented via GEN and KILL sets.

The statement is identified as bb_data[idx_stmt], where bb_data is the sequence of statements identified by bb in the MIR.

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Mutates the block-sets (the flow sets for the given basic block) according to the effects of evaluating the terminator.

This is used, in particular, for building up the "transfer-function" representing the overall-effect of the block, represented via GEN and KILL sets.

The effects applied here cannot depend on which branch the terminator took.

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Mutates the block-sets according to the (flow-dependent) effect of a successful return from a Call terminator.

If basic-block BB_x ends with a call-instruction that, upon successful return, flows to BB_y, then this method will be called on the exit flow-state of BB_x in order to set up the entry flow-state of BB_y.

This is used, in particular, as a special case during the "propagate" loop where all of the basic blocks are repeatedly visited. Since the effects of a Call terminator are flow-dependent, the current MIR cannot encode them via just GEN and KILL sets attached to the block, and so instead we add this extra machinery to represent the flow-dependent effect.

FIXME: Right now this is a bit of a wart in the API. It might be better to represent this as an additional gen- and kill-sets associated with each edge coming out of the basic block.

Provided Methods

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Some analyses want to accumulate knowledge within a block when analyzing its statements for building the gen/kill sets. Override this method to return true in such cases.

When this returns true, the statement-effect (re)construction will clone the on_entry state and pass along a reference via sets.on_entry to that local clone into statement_effect and terminator_effect).

When its false, no local clone is constucted; instead a reference directly into on_entry is passed along via sets.on_entry instead, which represents the flow state at the block's start, not necessarily the state immediately prior to the statement/terminator under analysis.

In either case, the passed reference is mutable; but this is a wart from using the BlockSets type in the API; the intention is that the statement_effect and terminator_effect methods mutate only the gen/kill sets.

FIXME: We should consider enforcing the intention described in the previous paragraph by passing the three sets in separate parameters to encode their distinct mutabilities.

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Similar to statement_effect, except it applies just before the statement rather than just after it.

This matters for "dataflow at location" APIs, because the before-statement effect is visible while visiting the statement, while the after-statement effect only becomes visible at the next statement.

Both the before-statement and after-statement effects are applied, in that order, before moving for the next statement.

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Similar to terminator_effect, except it applies just before the terminator rather than just after it.

This matters for "dataflow at location" APIs, because the before-terminator effect is visible while visiting the terminator, while the after-terminator effect only becomes visible at the terminator's successors.

Both the before-terminator and after-terminator effects are applied, in that order, before moving for the next terminator.

Implementors