Module Concurrency__StarvationModels

module F = Stdlib.Format
type severity =
| Low
| Medium
| High
val compare_severity : severity -> severity -> int
val pp_severity : F.formatter -> severity -> unit
val may_block : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> severity option

is the method call potentially blocking, given the actuals passed?

val is_strict_mode_violation : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_monitor_wait : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_synchronized_library_call : IR.Tenv.t -> IR.Procname.t -> bool

does the method call lock-then-unlock the underlying object? legacy Java containers like Vector do this, and can interact with explicit locking

val should_skip_analysis : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool

should we treat a method call as skip (eg library methods in guava) to avoid FPs?

val is_annotated_nonblocking : IR.Tenv.t -> IR.Procname.t -> bool

is procedure transitively annotated @Nonblocking

val is_annotated_lockless : IR.Tenv.t -> IR.Procname.t -> bool

is procedure transitively annotated @Lockless

val schedules_work : IR.Tenv.t -> IR.Procname.t -> bool

call known to schedule runnable first argument to some executor/handler or subclass

type scheduler_thread_constraint =
| ForUIThread
| ForNonUIThread
| ForUnknownThread

an instance field holding a reference to an executor may be annotated as running on UI/non-UI thread

val equal_scheduler_thread_constraint : scheduler_thread_constraint -> scheduler_thread_constraint -> bool
val get_executor_thread_annotation_constraint : IR.Tenv.t -> Absint.HilExp.AccessExpression.t -> scheduler_thread_constraint option

given an executor receiver, get its thread constraint, if any. None means lookup somehow failed, whereas Some UnknownThread means the receiver is an unannotated executor.

val get_run_method_from_runnable : IR.Tenv.t -> Absint.HilExp.AccessExpression.t -> IR.Procname.t option

given a receiver, find the run() method in the appropriate class

val get_returned_executor : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> scheduler_thread_constraint option

does the function return an executor and of which thread?

val schedules_first_arg_on_ui_thread : IR.Tenv.t -> IR.Procname.t -> bool

method call known to directly schedule the runnable object provided as first procedure argument on the UI thread

val schedules_second_arg_on_ui_thread : IR.Tenv.t -> IR.Procname.t -> bool

method call known to directly schedule the runnable object provided as second procedure argument on a background thread

val schedules_first_arg_on_bg_thread : IR.Tenv.t -> IR.Procname.t -> bool

method call known to directly the runnable object provided as first procedure argument on a background thread

val is_getMainLooper : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_handler_constructor : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_thread_constructor : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_future_get : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_future_is_done : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool
val is_assume_true : IR.Tenv.t -> IR.Procname.t -> Absint.HilExp.t list -> bool

is the callee equivalent to assuming its first argument true

val is_java_main_method : IR.Procname.t -> bool

does the method look like a Java main