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.

See https://github.com/google/leveldb/issues/1081

PiperOrigin-RevId: 499519182

PiperOrigin-RevId: 461725664

PiperOrigin-RevId: 461722304

PiperOrigin-RevId: 461695246

PiperOrigin-RevId: 461612590

This replaces a usage of fprintf to stderr

PiperOrigin-RevId: 454620969

PiperOrigin-RevId: 447466466

Structs with user-declared constructors are no longer considered
aggregates.  Just remove the constructor declaration where applicable.

Bug: chromium:1284275

PiperOrigin-RevId: 422409116

* Align CONTRIBUTING.md with the google/new-project template.
* Explain the support story for the CMake config.

PiperOrigin-RevId: 421120645

PiperOrigin-RevId: 420787858

PiperOrigin-RevId: 420783873

PiperOrigin-RevId: 420783487

PiperOrigin-RevId: 420782536

PiperOrigin-RevId: 420781374

PiperOrigin-RevId: 420781095

PiperOrigin-RevId: 420778907

PiperOrigin-RevId: 420662938

PiperOrigin-RevId: 420662891

PiperOrigin-RevId: 420645727

PiperOrigin-RevId: 420645080

PiperOrigin-RevId: 420644954

PiperOrigin-RevId: 420541137

PiperOrigin-RevId: 420534594

PiperOrigin-RevId: 420533763

PiperOrigin-RevId: 420532625

PiperOrigin-RevId: 420517390

PiperOrigin-RevId: 420504266

PiperOrigin-RevId: 420403341

PiperOrigin-RevId: 420399272

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

The benchmark in db/db_test.cc is extracted to its own file,
benchmarks/db_bench_log.cc.

PiperOrigin-RevId: 418713499

PiperOrigin-RevId: 417853172

PiperOrigin-RevId: 412997201

PiperOrigin-RevId: 412965575

I recently encountered a problem with this because Windows doesn't allow
files to be deleted when there's open handles to them.

Other files opened by leveldb are not affected because by and large they
are using CreateFileA, which does not allow inheritance when
lpSecurityAttributes is null (ref:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea)

However, fopen() _does_ allow inheritance, and it needs to be expressly
disabled.
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-160

PiperOrigin-RevId: 395824737

Fix typo of comment of FindLargestKey function

PiperOrigin-RevId: 394542401