This is motivated by D63591, where we realized that there isn't a really
good way of telling whether a DataExtractor is reading actual data, or
is it just returning default values because it reached the end of the
buffer.
This (WIP) patch tries to resolve this issues that by providing a kind of anew "Cursor" class. A Cursor
streaming api on top of the data extractor. It is inspired by theobject encapsulates two things:
std::iostreams api, where one can also blindly read from a stream- the current position/offset in the DataExtractor
(receiving default values in case of errors), and then check for any
erros in bulk once the parse has finished.- an error object
To achieve this, I introduce a new class (DataStream), whichStoring the error object inside the Cursor enables one to use the same
encapsulates three things:pattern as the std::{io}stream API, where one can blindly perform a
- the DataExtractor we are reading fromsequence of reads and only check for errors once at the end of the
- the current position within that extractoroperation. Similarly to the stream API, as soon as we encounter one
error, all of the subsequent operations are skipped (return default
values) too, even if the would suceed with clear error state. Unlike the
std::stream API (but in line with other llvm APIs), we force the error
state to be checked through usage of llvm::Error.
- an error flag
Please let me know what you think.