Replace the stub implementation of invalidation with the proper
implementation. A ReadPathCache is added to each global so that it can
keep tracks of what target are associated to which read paths.
One of the two passes to purge unused types from the model had a
ill-defined semantics.
This commit simplifies them in two passes: one that purges all the types
unreachable from outside `Binary::Types` and one that does the same but
also preserves types with a `CustomName` or an `OriginalName`.
This commit improves the formalization of how we handle names.
The main changes are:
* Now `_` is a reserved prefix and all the generated names start with
`_`.
* The model verification routine now checks that `CustomName`s in the
global scope do not collide with any local namespace (e.g., fields of
a `StructType`).
* We changed the prefix `prefix_` to `unreserved_` to better convey the
fact that the prefix has been introduce to use an non-reserved name.
This commit switches `model::Type::ID` from being a GUID to be a
progressive number, in order to make things easier for humans.
On top of this, this commit introduces the following changes:
* TypeCopier: import all the necessary PrimitiveTypes and improve
handling of CustomName.
* Move Kind as the last field of the key of each TupleTree type used in
an `UpcastablePointer`.
* Update the ground truth of tests to ignore the `CustomName` in favor
of focusing on `OriginalName`.
* Increase adoption of `model::Binary::makeType`, equivalent to
`Binary.recordNewType(makeType<model::*Type>())`.
Before this commit, if there was a failure during the verification of a
type (which is recursive), we'd get an assertion in ~VerifyHelper due to
a "pending" type still being verified.
This commit ensure the BaseAddress is propagate as appropriate to all
levels of the importers and that it is ignored for executables
(non-PIC).
This was a recurring source of importing the same function twice, once
relocated, once not.
This method is similar to `getByAddress`, but it returns an
`llvm::StringRef`.
It is intended for those users that need to manipulate the bytes as
strings. In those cases, the `llvm::ArrayRef<uint8_t>` returned by
`getByAddress` is not suitable, because it triggers warnings due to
`uint8_t` not being the same as `char`.
Alessandro Di Federico