Due to the removal of `S3StorageClient`, simplify the infrastructure
under `/Storage/`:
* Move and rename `LocalStorageClient` to `StorageClient`, de-virtualize
all of its methods
* Move and rename `LocalWritableFile`, `LocalReadableFile` to
`WritableFile` and `ReadableFile`, de-vitualize all methods
* Drop the `Std{in,out}StorageClient`, make `FilePath` handle the
stdin/stdout logic
* Remove `setStorageCredentials` from `PipelineManager`
When using revng through `revng daemon` the variable `InputPath` is not
populated, leading to `lddtree` failing silently. Fall back to the input
binary in the resume directory in case the the `InputPath` variable is
empty.
The `rp_manager_set_storage_credentials` is now skipped when running a
trace in `revng trace run`. This is needed because the storage backend
when running a trace is replaced with a local one and calling the
function does not make sense.
On the C++ side of revng it is important that LLVM's signal handlers are
registered within the initialization of `revng::InitRevng`, as this
allows downstream users (e.g. `revng daemon`) to preserve its signal
handlers before setting up the C++ infrastructure. In
`Tracing/Runner.cpp` there's `CommandHandler` which is statically
initialized and called `llvm::sys::AddSignalHandler`, this happened at
`dlopen` time, breaking the promise outlined above. Rework the code so
that the function is called lazily instead of statically.
This commit changes the following method names across the codebase:
* `storeToDisk` -> `store`
* `loadFromDisk` -> `load`
This has been done since the storage is no longer bound to the local
storage.
This commit introduces the concept of `Component` to a pipeline step.
This, in turn, can be used by clients to figure out which artifacts are
produced by which revng component.
Additionally, this commit overhauls the `revng daemon-self-test`
command, renaming it to `revng graphql` and adding extra flexibility.
Move much of the logic of `rp_manager_produce_targets` to a method
inside `PipelineManager`, add additional checks for the existence of the
targets that are requested to be produced.
Add support for tracing onto the PipelineC. This is done by:
1. Creating wrapper functions for each PipelineC function with the
script in `scripts/PipelineC_add_tracing.py`. These will call a
special function called `wrap` which will ultimately call a method
with a `_` prepended to the name
2. Conversion of all PipelineC methods in `PipelineC.cpp` to `static`
and their rename with a `_` in front, in order for them to work with
the wrapper function in (1)
3. Generation of 2 additional include files, one for types and one for
functions, to be used by users of tracing files in order to have
introspection.
These steps allow the creation of a trace file with the use of the
`REVNG_C_API_TRACE_PATH` environment variable. The traces can then be
used in conjunction with the `revng trace run` and `revng trace
inspect` commands.
Switch from specifying `libraries` and `pipelines` in `rp_initialize`
and `rp_manager_create` to the use of command-line options that are to
be passed via `argc` and `argv` in `rp_initialize`.
Alessandro Di Federico