renvg.h should not use model headers, however, currently it does. This,
combined with the fact that the revngSupport library did not depend on
revngModel or the header generation led to non-deterministic build
failures.
Before this commit the bug can be found by:
orc clean revng
orc uninstall revng
orc configure revng
orc shell -c revng ninja renvgSupport
The error should manifest itself as some generated headers missing.
The proper fix would be to rewrite revng.h so that it does not uses the
model.
Model classes are now described by a YAML document, which is used to
generate C++ headers containing classes and all the boilerplate
required for YAML serialization/deserialization, usage in
SortedVectors, etc. See the README in include/revng/Model for more
info.
`main` is not in all cases a dynamically exported symbol, therefore,
it's not safe to rely on it.
This commit switches to use `PathList`'s `getCurrentExecutableFullPath`,
which reads `/proc/self/exe`.
StringRef::data() does not ensure that the string is zero terminated,
thus when printed it can contain more data than expected.
Specifically, this triggered the reported name of the registers to be
incorrect, and this manifested itself as wrong inline assembly emitted.
The constructor now accepts a llvm::object::Binary directly rather than
a path. Will be used by the revng-pipeline which will retain ownership
of the binary.
A dereference iterator is used to map a pointer-like object to the
pointee, as an example given a `vector<unique_ptr<int>> Vector`, using
`dereferenceRange(Vector)` will present a range of `int &` rather than a
range of `unique_ptr<int> &`.
mapToValueIterator can be used on a map range
to access the underlying object directly rather
than the pair<key, object>.
This allows e.g. the following programming pattern:
```
RecursiveCoroutine<std::optional<SomeType>> f();
int g() {
return *f();
}
```
Without operator* defined for `RecursiveCoroutine` this would fail,
requiring an explicit cast such as:
```
int g() {
return *static_cast<std::optional<SomeType>>(f());
}
```
Before this commit `is_specialization<const X<T>, X>` was not
specialized, so that `const X<T>` did not count as a specialization of
`X`. This resulted in bad selection of template specialization based on
concepts that were using `is_specialization_v`, such as
`IsUpcastablePointer`.
This commit fixes the problem, so that now the concept
`IsUpcastablePointer` is true for `const UpcastablePointer<T>` as well.
This also enabled to remove some workarounds for the `IsMutableSet` and
`IsSortedVector` concepts, and treat them uniformly with other concepts
that were using `is_specialization_v`.
Before this commit, it was only matched by types that satisfied the
constraint `IsUpcastablePointer`, which is too strict.
Now also types that match `UpcastablePointerLike` satisfy the
constraints for this concept.
Massimo Fioravanti