There are a large number of kinds of tree structured or tree-like data in CPROVER.
More...
|
| bool | is_nil () const |
| |
| bool | is_not_nil () const |
| |
| | irept (const irep_idt &_id) |
| |
| | irept (const irep_idt &_id, const named_subt &_named_sub, const subt &_sub) |
| |
| | irept ()=default |
| |
| const irep_idt & | id () const |
| |
| const std::string & | id_string () const |
| |
| void | id (const irep_idt &_data) |
| |
| const irept & | find (const irep_idt &name) const |
| |
| irept & | add (const irep_idt &name) |
| |
| irept & | add (const irep_idt &name, irept irep) |
| |
| const std::string & | get_string (const irep_idt &name) const |
| |
| const irep_idt & | get (const irep_idt &name) const |
| |
| bool | get_bool (const irep_idt &name) const |
| |
| signed int | get_int (const irep_idt &name) const |
| |
| std::size_t | get_size_t (const irep_idt &name) const |
| |
| long long | get_long_long (const irep_idt &name) const |
| |
| void | set (const irep_idt &name, const irep_idt &value) |
| |
| void | set (const irep_idt &name, irept irep) |
| |
| void | set (const irep_idt &name, const long long value) |
| |
| void | set_size_t (const irep_idt &name, const std::size_t value) |
| |
| void | remove (const irep_idt &name) |
| |
| void | move_to_sub (irept &irep) |
| |
| void | move_to_named_sub (const irep_idt &name, irept &irep) |
| |
| bool | operator== (const irept &other) const |
| |
| bool | operator!= (const irept &other) const |
| |
| void | swap (irept &irep) |
| |
| bool | operator< (const irept &other) const |
| | defines ordering on the internal representation More...
|
| |
| bool | ordering (const irept &other) const |
| | defines ordering on the internal representation More...
|
| |
| int | compare (const irept &i) const |
| | defines ordering on the internal representation comments are ignored More...
|
| |
| void | clear () |
| |
| void | make_nil () |
| |
| subt & | get_sub () |
| |
| const subt & | get_sub () const |
| |
| named_subt & | get_named_sub () |
| |
| const named_subt & | get_named_sub () const |
| |
| std::size_t | hash () const |
| |
| std::size_t | full_hash () const |
| |
| bool | full_eq (const irept &other) const |
| |
| std::string | pretty (unsigned indent=0, unsigned max_indent=0) const |
| |
| | sharing_treet (irep_idt _id) |
| |
| | sharing_treet (irep_idt _id, named_subt _named_sub, subt _sub) |
| |
| | sharing_treet () |
| |
| | sharing_treet (const sharing_treet &irep) |
| |
| | sharing_treet (sharing_treet &&irep) |
| |
| sharing_treet & | operator= (const sharing_treet &irep) |
| |
| sharing_treet & | operator= (sharing_treet &&irep) |
| |
| | ~sharing_treet () |
| |
| const dt & | read () const |
| |
| dt & | write () |
| |
There are a large number of kinds of tree structured or tree-like data in CPROVER.
irept provides a single, unified representation for all of these, allowing structure sharing and reference counting of data. As such irept is the basic unit of data in CPROVER. Each irept contains (or references, if reference counted data sharing is enabled, as it is by default - see the SHARING macro) to a node (see tree_nodet). The irept::pretty function outputs the explicit tree structure of an irept and can be used to understand and debug problems with irepts.
On their own irepts do not "mean" anything; they are effectively generic tree nodes. Their interpretation depends on the contents of result of the id() function, i.e. the data field. util/irep_ids.def contains a list of id values. During the build process it is used to generate util/irep_ids.h which gives constants for each id (named ID_). You can also make irep_idts which do not come from util/irep_ids.def. An irep_idt can then be used to identify what kind of data the irept stores and thus what can be done with it.
To simplify this process, there are a variety of classes that inherit from irept, roughly corresponding to the ids listed (i.e. ID_or (the string "or”) corresponds to the class or_exprt). These give semantically relevant accessor functions for the data; effectively different APIs for the same underlying data structure. None of these classes add fields (only methods) and so static casting can be used. The inheritance graph of the subclasses of irept is a useful starting point for working out how to manipulate data.
There are three main groups of classes (or APIs); those derived from typet, codet and exprt respectively. Although all of these inherit from irept, these are the most abstract level that code should handle data. If code is manipulating plain irepts then something is wrong with the architecture of the code.
Many of the key descendants of exprt are declared in std_expr.h. All expressions have a named subexpression with ID "type", which gives the type of the expression (slightly simplified from C/C++ as unsignedbv_typet, signedbv_typet, floatbv_typet, etc.). All type conversions are explicit with a typecast_exprt. One key descendant of exprt is symbol_exprt which creates irept instances with ID “symbol”. These are used to represent variables; the name of which can be found using the get_identifier accessor function.
codet inherits from exprt and is defined in std_code.h. It represents executable code; statements in a C-like language rather than expressions. In the front-end there are versions of these that hold whole code blocks, but in goto-programs these have been flattened so that each irept represents one sequence point (almost one line of code / one semi-colon). The most common descendant of codet is code_assignt so a common pattern is to cast the codet to an assignment and then recurse on the expression on either side.
Definition at line 351 of file irep.h.
Inheritance diagram for irept: