[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
//===- BinaryStreamRef.cpp - ----------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Support/BinaryStreamRef.h"
|
|
|
|
#include "llvm/Support/BinaryByteStream.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace llvm::support;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
class ArrayRefImpl : public BinaryStream {
|
|
|
|
public:
|
|
|
|
ArrayRefImpl(ArrayRef<uint8_t> Data, endianness Endian) : BBS(Data, Endian) {}
|
|
|
|
|
|
|
|
llvm::support::endianness getEndian() const override {
|
|
|
|
return BBS.getEndian();
|
|
|
|
}
|
|
|
|
Error readBytes(uint32_t Offset, uint32_t Size,
|
|
|
|
ArrayRef<uint8_t> &Buffer) override {
|
|
|
|
return BBS.readBytes(Offset, Size, Buffer);
|
|
|
|
}
|
|
|
|
Error readLongestContiguousChunk(uint32_t Offset,
|
|
|
|
ArrayRef<uint8_t> &Buffer) override {
|
|
|
|
return BBS.readLongestContiguousChunk(Offset, Buffer);
|
|
|
|
}
|
|
|
|
uint32_t getLength() override { return BBS.getLength(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
BinaryByteStream BBS;
|
|
|
|
};
|
|
|
|
|
|
|
|
class MutableArrayRefImpl : public WritableBinaryStream {
|
|
|
|
public:
|
|
|
|
MutableArrayRefImpl(MutableArrayRef<uint8_t> Data, endianness Endian)
|
|
|
|
: BBS(Data, Endian) {}
|
|
|
|
|
|
|
|
// Inherited via WritableBinaryStream
|
|
|
|
llvm::support::endianness getEndian() const override {
|
|
|
|
return BBS.getEndian();
|
|
|
|
}
|
|
|
|
Error readBytes(uint32_t Offset, uint32_t Size,
|
|
|
|
ArrayRef<uint8_t> &Buffer) override {
|
|
|
|
return BBS.readBytes(Offset, Size, Buffer);
|
|
|
|
}
|
|
|
|
Error readLongestContiguousChunk(uint32_t Offset,
|
|
|
|
ArrayRef<uint8_t> &Buffer) override {
|
|
|
|
return BBS.readLongestContiguousChunk(Offset, Buffer);
|
|
|
|
}
|
|
|
|
uint32_t getLength() override { return BBS.getLength(); }
|
|
|
|
|
|
|
|
Error writeBytes(uint32_t Offset, ArrayRef<uint8_t> Data) override {
|
|
|
|
return BBS.writeBytes(Offset, Data);
|
|
|
|
}
|
|
|
|
Error commit() override { return BBS.commit(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
MutableBinaryByteStream BBS;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
BinaryStreamRef::BinaryStreamRef(BinaryStream &Stream)
|
2017-11-28 02:48:37 +08:00
|
|
|
: BinaryStreamRefBase(Stream) {}
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
BinaryStreamRef::BinaryStreamRef(BinaryStream &Stream, uint32_t Offset,
|
2017-11-28 02:48:37 +08:00
|
|
|
Optional<uint32_t> Length)
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
: BinaryStreamRefBase(Stream, Offset, Length) {}
|
|
|
|
BinaryStreamRef::BinaryStreamRef(ArrayRef<uint8_t> Data, endianness Endian)
|
|
|
|
: BinaryStreamRefBase(std::make_shared<ArrayRefImpl>(Data, Endian), 0,
|
|
|
|
Data.size()) {}
|
|
|
|
BinaryStreamRef::BinaryStreamRef(StringRef Data, endianness Endian)
|
|
|
|
: BinaryStreamRef(makeArrayRef(Data.bytes_begin(), Data.bytes_end()),
|
|
|
|
Endian) {}
|
|
|
|
|
|
|
|
Error BinaryStreamRef::readBytes(uint32_t Offset, uint32_t Size,
|
|
|
|
ArrayRef<uint8_t> &Buffer) const {
|
2017-11-28 02:48:37 +08:00
|
|
|
if (auto EC = checkOffsetForRead(Offset, Size))
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
return EC;
|
|
|
|
return BorrowedImpl->readBytes(ViewOffset + Offset, Size, Buffer);
|
|
|
|
}
|
|
|
|
|
|
|
|
Error BinaryStreamRef::readLongestContiguousChunk(
|
|
|
|
uint32_t Offset, ArrayRef<uint8_t> &Buffer) const {
|
2017-11-28 02:48:37 +08:00
|
|
|
if (auto EC = checkOffsetForRead(Offset, 1))
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
return EC;
|
|
|
|
|
|
|
|
if (auto EC =
|
|
|
|
BorrowedImpl->readLongestContiguousChunk(ViewOffset + Offset, Buffer))
|
|
|
|
return EC;
|
|
|
|
// This StreamRef might refer to a smaller window over a larger stream. In
|
|
|
|
// that case we will have read out more bytes than we should return, because
|
|
|
|
// we should not read past the end of the current view.
|
2017-11-28 02:48:37 +08:00
|
|
|
uint32_t MaxLength = getLength() - Offset;
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
if (Buffer.size() > MaxLength)
|
|
|
|
Buffer = Buffer.slice(0, MaxLength);
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
WritableBinaryStreamRef::WritableBinaryStreamRef(WritableBinaryStream &Stream)
|
2017-11-28 02:48:37 +08:00
|
|
|
: BinaryStreamRefBase(Stream) {}
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
|
|
|
|
WritableBinaryStreamRef::WritableBinaryStreamRef(WritableBinaryStream &Stream,
|
|
|
|
uint32_t Offset,
|
2017-11-28 02:48:37 +08:00
|
|
|
Optional<uint32_t> Length)
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
: BinaryStreamRefBase(Stream, Offset, Length) {}
|
|
|
|
|
|
|
|
WritableBinaryStreamRef::WritableBinaryStreamRef(MutableArrayRef<uint8_t> Data,
|
|
|
|
endianness Endian)
|
|
|
|
: BinaryStreamRefBase(std::make_shared<MutableArrayRefImpl>(Data, Endian),
|
|
|
|
0, Data.size()) {}
|
|
|
|
|
|
|
|
|
|
|
|
Error WritableBinaryStreamRef::writeBytes(uint32_t Offset,
|
|
|
|
ArrayRef<uint8_t> Data) const {
|
2017-11-28 02:48:37 +08:00
|
|
|
if (auto EC = checkOffsetForWrite(Offset, Data.size()))
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
return EC;
|
|
|
|
|
|
|
|
return BorrowedImpl->writeBytes(ViewOffset + Offset, Data);
|
|
|
|
}
|
|
|
|
|
|
|
|
WritableBinaryStreamRef::operator BinaryStreamRef() const {
|
|
|
|
return BinaryStreamRef(*BorrowedImpl, ViewOffset, Length);
|
|
|
|
}
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// For buffered streams, commits changes to the backing store.
|
[BinaryStream] Reduce the amount of boiler plate needed to use.
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303294
2017-05-18 04:23:31 +08:00
|
|
|
Error WritableBinaryStreamRef::commit() { return BorrowedImpl->commit(); }
|