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.
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`.
In the previous implementation of Model.verify an llvm::Error was
returned. Some call sites retained the logic associated with it. Fix
these with the correct logic.
Also fix an instance of `verify` that was missing an assert.
Drop the use of unique_ptr within the rp_error data type and instead use
std::monostate. Also fix the functions to allow the use of `nullptr` as
the error parameter
* Let GraphQL accept zero or more parameters for analyses
* Handle the general case of analyses using zero or more containers with
a variable ammount of targets
This commit fixes file output `revng.api` in two ways:
* The buffer's size is properly reported in `PipelineC.cpp`
* The function `deserialize_container` in `revng.api.manager` no longer
appends a `\0` to `content`, while avoiding a redundant copy
`DocumentError`s are the inteded way of propagating errors from the
pipeline to the frontend when a location is required to inform the user
of the error whereabouts.
This change fixes the pipeline behavior when producing targets:
* produce and extract now return rp_buffer, which has a start pointer
and size
* the python api `revng.api` will return on produce/extract either str
or bytes depending on the mime type of the container
* the GraphQL api will encode bytes in base64
To keep consistency with the rest of PipelineC, return `nullptr` when
calling `rp_container_extract_one` when the content of the specified
target hasn't been produced
Handle crashes via signal handlers. Switch python's revng.api from
a normal python function to faulthandler, which works also in the
case of harsher interruptions (e.g. SIGABRT).
Alessandro Di Federico