This allows this type to meet the requirements of e.g.
std::ranges::range, which is necessary for it to work with the
std::span range constructor, or the "non-legacy" constructor for
Chromium's base::span.
Bug: none
Without this check decoding the footer in Table::Open() can read
uninitialized bytes from a buffer allocated on the stack if the file
was unexpectedly short.
In practice this is probably fine since this function validates a magic
number but MSan complains about branching on uninitialized data.
PiperOrigin-RevId: 525271012
This PR temporarily removes a package that is currently broken on
GitHub's Ubuntu 22.04 installation. This is the most expedient way to
make the CI green again, so we can test any other changes we may want to
land.
PiperOrigin-RevId: 520206940
As allowed by the documentation for Env::Schedule(), ChromiumEnv may
execute functions on multiple threads and guarantees no sequencing.
EnvTest.RunMany assumed that functions ran in order, is the case for the
stock PosixEnv and WindowsEnv implementations. This change updates the
test to not assume sequential execution.
There are a couple differences between ChromiumEnv and
PosixEnv/WindowsEnv which cause test failures that are fixed (or at
least patched over) in this change:
* NewSequentialFile() and NewRandomAccessFile() return Status::IOError
rather than Status::NotFound when a file is not found, due to
https://crbug.com/760362. This means a few tests need to expect a
different error result.
* GetChildren() never returns the '.' or '..' entries.
* As allowed by the documentation for Env::Schedule(), ChromiumEnv may
execute functions on multiple threads and guarantees no sequencing.
EnvTest.RunMany assumed that functions ran in order. The test has been
updated.
Structs with user-declared constructors are no longer considered
aggregates. Just remove the constructor declaration where applicable.
Bug: chromium:1284275
This gives some flexibility to embedders.
Currently, embedders have to build a binary for each test file.
After this CL, embedders can still choose to have a binary for each test
file, by linking each test file with a googletest target that includes
main() (usually "gtest_main"). Embedders can also choose to build a
single binary for almost all test files, and link with a googletest
target that includes main(). The latter is more convenient for projects
that have very few test binaries, like Chromium.
PiperOrigin-RevId: 419470798
Peter Kasting
leveldb Team
Victor Costan
Reilly Grant
Sanjay Ghemawat
Victor Costan
Christopher Jeffrey
xindubawukong
Dimitris Apostolou
Shawn Zhong