Class AbstractInterpretationVisitor<Domain, OtherInfo, Config>Abstract

A control flow graph visitor to perform abstract interpretation.

However, the visitor does not yet support inter-procedural abstract interpretation and abstract condition semantics.

Type Parameters

Hierarchy (View Summary)

Hierarchy-Diagram

UML class diagram of AbstractInterpretationVisitor

Constructors

Properties

config: Config & {
    defaultVisitingOrder: "forward";
    defaultVisitingType: "exit";
}
trace: Map<NodeId, StateAbstractDomain<Domain>> = ...

The abstract trace of the abstract interpretation visitor mapping node IDs to the abstract state at the respective node.

visited: Map<NodeId, number>

Methods

  • Gets the inferred abstract state at the location of a specific AST node. This requires that the abstract interpretation visitor has been completed, or at least started.

    Parameters

    • id: undefined | NodeId

      The ID of the node to get the abstract state at

    Returns undefined | StateAbstractDomain<Domain>

    The abstract state at the node, or undefined if the node has no abstract state (i.e. the node has not been visited or is unreachable).

  • Protected

    This event triggers for every assignment call, i.e., for every call to <- or = that assigns a value to a variable.

    For example, this triggers for <- in x <- 42 or assign in assign("x", 42). This also triggers for the data.table assign := active within subsetting calls, e.g., DT[, x := 42].

    Please be aware that replacements (e.g. assignments with a function call on the target side) like names(x) <- 3 are subject to SemanticCfgGuidedVisitor#onReplacementCall|onReplacementCall instead.

    Parameters

    Returns void

  • Protected

    This event triggers for every function call that is not handled by a specific overload, and hence may be a function that targets a user-defined function. In a way, these are functions that are named, but flowR does not specifically care about them (currently) wrt. to their dataflow impact.

    Use SemanticCfgGuidedVisitor#getOrigins|getOrigins to get the origins of the call.

    For example, this triggers for foo(x) in

    foo <- function(x) { x + 1 }
    foo(x)

    This explicitly will not trigger for scenarios in which the function has no name (i.e., if it is anonymous). For such cases, you may rely on the SemanticCfgGuidedVisitor#onUnnamedCall|onUnnamedCall event. The main reason for this separation is part of flowR's handling of these functions, as anonymous calls cannot be resolved using the active environment.

    Parameters

    Returns void

  • Protected

    This event triggers for every anonymous call within the program.

    For example, (function(x) { x + 1 })(42) or the second call in a()().

    This is separate from SemanticCfgGuidedVisitor#onDefaultFunctionCall|onDefaultFunctionCall which is used for named function calls that do not trigger any of these events. The main differentiation for these calls is that you may not infer their semantics from any name alone and probably have to rely on SemanticCfgGuidedVisitor#getOrigins|getOrigins to get more information.

    Parameters

    Returns void