|
|
|
|
(*
|
|
|
|
|
* Copyright (c) 2009 - 2013 Monoidics ltd.
|
|
|
|
|
* Copyright (c) 2013 - present Facebook, Inc.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* This source code is licensed under the BSD style license found in the
|
|
|
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
|
*)
|
|
|
|
|
|
|
|
|
|
open! IStd
|
|
|
|
|
|
|
|
|
|
(** Control Flow Graph for Interprocedural Analysis *)
|
|
|
|
|
|
|
|
|
|
(** A control-flow graph *)
|
|
|
|
|
type t
|
|
|
|
|
|
|
|
|
|
val load : SourceFile.t -> t option
|
|
|
|
|
(** Load the cfgs of the procedures of a source file *)
|
|
|
|
|
|
|
|
|
|
val store : SourceFile.t -> t -> unit
|
|
|
|
|
(** Save a cfg into the database *)
|
|
|
|
|
|
|
|
|
|
(** {2 Functions for manipulating an interprocedural CFG} *)
|
|
|
|
|
|
|
|
|
|
val create_cfg : unit -> t
|
|
|
|
|
(** create a new empty cfg *)
|
|
|
|
|
|
|
|
|
|
val create_proc_desc : t -> ProcAttributes.t -> Procdesc.t
|
|
|
|
|
(** Create a new procdesc *)
|
|
|
|
|
|
|
|
|
|
val fold_proc_desc : t -> (Typ.Procname.t -> Procdesc.t -> 'a -> 'a) -> 'a -> 'a
|
|
|
|
|
(** Fold over all the procdesc's *)
|
|
|
|
|
|
|
|
|
|
val find_proc_desc_from_name : t -> Typ.Procname.t -> Procdesc.t option
|
|
|
|
|
(** Find the procdesc given the proc name. Return None if not found. *)
|
|
|
|
|
|
|
|
|
|
val iter_all_nodes : ?sorted:bool -> (Procdesc.t -> Procdesc.Node.t -> unit) -> t -> unit
|
|
|
|
|
(** Iterate over all the nodes in the cfg *)
|
|
|
|
|
|
|
|
|
|
val check_cfg_connectedness : t -> unit
|
|
|
|
|
(** checks whether a cfg is connected or not *)
|
|
|
|
|
|
|
|
|
|
val remove_proc_desc : t -> Typ.Procname.t -> unit
|
|
|
|
|
(** Remove the procdesc from the control flow graph. *)
|
|
|
|
|
|
|
|
|
|
val specialize_types : Procdesc.t -> Typ.Procname.t -> (Exp.t * Typ.t) list -> Procdesc.t
|
|
|
|
|
(** Creates a copy of a procedure description and a list of type substitutions of the form
|
|
|
|
|
(name, typ) where name is a parameter. The resulting procdesc is isomorphic but
|
|
|
|
|
all the type of the parameters are replaced in the instructions according to the list.
|
|
|
|
|
The virtual calls are also replaced to match the parameter types *)
|
|
|
|
|
|
[clang] Executing methods with blocks as parameters by instantiating the parameters with current blocks
Summary:
This diff adds a new way of executing blocks when they are passed as parameters to a method. So far we just skipped the block in this case.
Now we can execute it. Let's demonstrate with an example. Say we have
//foo has a block parameter that it executes in its body
foo (Block block) { block();}
// bar calls foo with a concrete block
bar() {
foo (^(){
self->x = 10;
});
};
Now, when we call the method foo with a concrete block, we create a copy of foo instantiated with the concrete block, which in itself is translated as a method with a made-up name.
The copy of foo will get a name that is foo extended with the name of the block parameter, the call to the block parameter will be replaced to a call to the concrete block, and the captured variables
of the concrete block (self in this case), will be added to the formals of the specialized method foo_block_name.
This is turned on at the moment for ObjC methods with ObjC blocks as parameters, and called with concrete blocks. Later on we can extend it to other types of methods, and to C++ lambdas, that are handled similarly to blocks.
Another extension is to check when the block has been called with nil instead of an actual block, and raise an error in that case.
After this diff, we can also model various methods and functions from the standard library that take blocks as parameters, and remove frontend hacks to deal with that.
Reviewed By: ddino
Differential Revision: D6260792
fbshipit-source-id: 0b6f22e
7 years ago
|
|
|
val specialize_with_block_args :
|
|
|
|
|
Procdesc.t -> Typ.Procname.t -> Exp.closure option list -> Procdesc.t
|
|
|
|
|
(** Creates a copy of a procedure description given a list of possible closures
|
[clang] Executing methods with blocks as parameters by instantiating the parameters with current blocks
Summary:
This diff adds a new way of executing blocks when they are passed as parameters to a method. So far we just skipped the block in this case.
Now we can execute it. Let's demonstrate with an example. Say we have
//foo has a block parameter that it executes in its body
foo (Block block) { block();}
// bar calls foo with a concrete block
bar() {
foo (^(){
self->x = 10;
});
};
Now, when we call the method foo with a concrete block, we create a copy of foo instantiated with the concrete block, which in itself is translated as a method with a made-up name.
The copy of foo will get a name that is foo extended with the name of the block parameter, the call to the block parameter will be replaced to a call to the concrete block, and the captured variables
of the concrete block (self in this case), will be added to the formals of the specialized method foo_block_name.
This is turned on at the moment for ObjC methods with ObjC blocks as parameters, and called with concrete blocks. Later on we can extend it to other types of methods, and to C++ lambdas, that are handled similarly to blocks.
Another extension is to check when the block has been called with nil instead of an actual block, and raise an error in that case.
After this diff, we can also model various methods and functions from the standard library that take blocks as parameters, and remove frontend hacks to deal with that.
Reviewed By: ddino
Differential Revision: D6260792
fbshipit-source-id: 0b6f22e
7 years ago
|
|
|
that are passed as arguments to the method. The resulting procdesc is isomorphic but
|
|
|
|
|
a) the block parameters are replaces with the closures
|
|
|
|
|
b) the parameters of the method are extended with parameters for the captured variables
|
[clang] Executing methods with blocks as parameters by instantiating the parameters with current blocks
Summary:
This diff adds a new way of executing blocks when they are passed as parameters to a method. So far we just skipped the block in this case.
Now we can execute it. Let's demonstrate with an example. Say we have
//foo has a block parameter that it executes in its body
foo (Block block) { block();}
// bar calls foo with a concrete block
bar() {
foo (^(){
self->x = 10;
});
};
Now, when we call the method foo with a concrete block, we create a copy of foo instantiated with the concrete block, which in itself is translated as a method with a made-up name.
The copy of foo will get a name that is foo extended with the name of the block parameter, the call to the block parameter will be replaced to a call to the concrete block, and the captured variables
of the concrete block (self in this case), will be added to the formals of the specialized method foo_block_name.
This is turned on at the moment for ObjC methods with ObjC blocks as parameters, and called with concrete blocks. Later on we can extend it to other types of methods, and to C++ lambdas, that are handled similarly to blocks.
Another extension is to check when the block has been called with nil instead of an actual block, and raise an error in that case.
After this diff, we can also model various methods and functions from the standard library that take blocks as parameters, and remove frontend hacks to deal with that.
Reviewed By: ddino
Differential Revision: D6260792
fbshipit-source-id: 0b6f22e
7 years ago
|
|
|
in the closures *)
|
|
|
|
|
|
|
|
|
|
val pp_proc_signatures : Format.formatter -> t -> unit
|
|
|
|
|
|
|
|
|
|
val exists_for_source_file : SourceFile.t -> bool
|
|
|
|
|
|
|
|
|
|
val get_captured_source_files : unit -> SourceFile.t list
|
