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

PiperOrigin-RevId: 388341429

Xcode (drives macOS image) : 12.2 => 12.5
Clang                      : 10 => 12
GCC                        : 10 => 11
PiperOrigin-RevId: 375582717

Roll third-party dependencies.

key across multiple files.

As reported in Github issue #339, it is incorrect to split the
same user key across multiple compacted files since it causes
tombstones/newer-versions to be dropped, thereby exposing obsolete
data. There was a fix for #339, but it ended up not fully fixing
the problem. (It checked for boundary problems in the first level
being compacted, but not the second). This problem was revealed
by Github issue 887.

We now adjust boundaries to avoid splitting user keys in both the
first level and the second level.

PiperOrigin-RevId: 374921082

Use function instead of original expression.