* Introduce some documentation for the model.
* Improve the way enums are serialized/deserialized.
* Mark certain fields of model data structures as optional.
* introduces some error messages during model validation.
This commit reserves the "unnamed_" prefix for revng.
The first use of this reserved prefix is in `model::Type`s
`CustomName`s and `model::Identifier`s.
This commit also makes the `verify()` method stricter for
`model::Identifier` so that an `Identifier` whose name starts with the
reserved prefix does fails verification.
This commit changes the `TupleTree::deserialize` method to return an
`llvm::ErrorOr<TupleTree>`, enabling users to choose their policies on
error reporting.
This commit introduces the type system of the model along with several
various other improvements to the model and its users.
* Introduce the type system.
* Introduce possibility to tag certain fields in the model as to be
optional during YAML serialization.
* All the `Name` fields have been replaced in favor of `CustomName` plus
a `name` method that will use `CustomName` if available, or an
automatically generated name otherwise.
* Make TupleTreeReferences behavior more robust: now you either need to
have a valid pointer to `Root` and a `Path` or be default constructed
(`nullptr` for `Root` and an empty `Path`). Any other configuration is
invalid.
* The type system introduces `RawFunctionType`: this superseds the
previous way in which we were specifying arguments and return
values. Users of such information have been updated accordingly.
The previous design returned a model::Binary &, which did not allow
users writing the model to properly initialize cross references between
different parts of the model.
This commit drops the KeyTraits in favor of a std::any-like solution.
Basically, we type erase any key the user wants to employ, just exposing
a virtual version of the destructor, a comparison operator and a clone
primitive.
We used to mark call to noreturn functions as killers, but this is not
correct.
Note that this is a temporary solution, we need to explicitly handle
such situations.
Alessandro Di Federico