Adding preprocessor flags requires a lot of typing in the CMake
command-line (-DCMAKE_C_FLAGS=-DOPENSSL_SMALL
-DCMAKE_CXX_FLAGS=-DOPENSSL_SMALL).
Change-Id: Ieafc4155d656306c1f22746f780faa5c1d3e27be
Reviewed-on: https://boringssl-review.googlesource.com/26784
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Also remove the -Wtautological-constant-compare logic. I believe Clang
has since removed that problematic warning from -Wall and that check was
causing problems when we were embedded as a subproject in a project that
didn't set CMP0025.
(In that case, by the time our build file ran, the compiler had already
been detected and the damage done. This unfortunately means the next
Clang version check will hit the same issue, but let's deal with that
when we get there.)
Change-Id: Iea5f262899b74c5b84f707f4cf4ac4b3540c4acb
Reviewed-on: https://boringssl-review.googlesource.com/26375
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is a reland 9d1f96606c, which should
hopefuly be fine after afd1cd959e. Though
I've also gone ahead and gotten the latest versions of things.
(android_tools and clang updated.)
In particular, get the new NDK. Unfortunately, the new clang picks up
an unfortunate change for clang-cl that we now must work around.
http://llvm.org/viewvc/llvm-project?view=revision&revision=319116
Bug: 109
Change-Id: If19b09c585957fefaffa8c3197a50189402a555a
Reviewed-on: https://boringssl-review.googlesource.com/25025
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts commit 9d1f96606c.
Reason for revert: aarch64 bots are breaking for some reason.
Original change's description:
> Update tools.
>
> In particular, get the new NDK. Unfortunately, the new clang picks up
> an unfortunate change for clang-cl that we now must work around.
>
> http://llvm.org/viewvc/llvm-project?view=revision&revision=319116
>
> Bug: 109
> Change-Id: I091ca7160683e70cd79b5c2b7a4267fea258ec17
> Reviewed-on: https://boringssl-review.googlesource.com/24644
> Reviewed-by: Steven Valdez <svaldez@google.com>
> Commit-Queue: David Benjamin <davidben@google.com>
> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
TBR=davidben@google.com,svaldez@google.com
Change-Id: I98960f295987857c4e42c312059b6d5934bb5e43
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 109
Reviewed-on: https://boringssl-review.googlesource.com/24747
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
CMake targets are visible globally but gtest_main has boringssl-specific
behavior that isn't appropriate for general use.
This change makes it possible to use boringssl and abseil-cpp in the
same project (since abseil-cpp expects gtest_main to exist and be useful
for its own tests).
Change-Id: Icc81c11b8bb4b1e21cea7c9fa725b6c082bd5369
Reviewed-on: https://boringssl-review.googlesource.com/24604
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The one in the NDK works just fine. In particular, this means one can
pass -DCMAKE_ASM_FLAGS="-march=armv8-a" and test the ARMv8 assembler
warnings.
Additionally, make the workaround put the flags in the other order, so
-march is user-overridable.
Change-Id: I278ddd17ab688f83ee01f2aca4ff32307f5b0a2d
Reviewed-on: https://boringssl-review.googlesource.com/24164
Reviewed-by: Adam Langley <agl@google.com>
This is a recent Clang warning, but it's far too aggressive. The earlier
unsigned long silliness was worth fixing, but it otherwise complains on
32-bit platforms with:
if (some_size_t > 0xffffffff) {
...
}
which is unreasonable as, on 64-bit platforms, this check is meaningful
and requiring the programmer add ifdefs is error-prone. This matches
Chromium in https://crbug.com/767059.
Bug: chromium:767059
Change-Id: I0bb0f3a4b60f222e9d1b3c569471fbcf5518caed
Reviewed-on: https://boringssl-review.googlesource.com/23845
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This change doesn't actually introduce any Fiat code yet. It sets up the
directory structure to make the diffs in the next change clearer.
Change-Id: I38a21fb36b18a08b0907f9d37b7ef5d7d3137ede
Reviewed-on: https://boringssl-review.googlesource.com/22624
Reviewed-by: David Benjamin <davidben@google.com>
Per the comment, it's no longer necessary. macOS i386 does not exist,
but apparently iOS i386 does! We can probably just remove it altogether,
but our cmake_minimum_required is nominally 2.8, so I just put the
version check in.
Bug: 210
Change-Id: I6e0617a3f292a218b2465eee85bd4814bd0e55c7
Reviewed-on: https://boringssl-review.googlesource.com/22304
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If you specify any --target which refers to a x86_64-apple-darwin
triple, or a more specific variant derived from it, specifying
-stdlib=libc++ is required, otherwise clang falls back to libstdc++
which didn't include c++11, and fails to compile in very obscure ways
(simply failing to find any c++11 symbols).
Change-Id: I58025cea91eaa0c16d9b5831f9965889b75bbc31
Reviewed-on: https://boringssl-review.googlesource.com/21984
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It spuriously complains about pointer math on function arguments which
are arrays.
Change-Id: I23b3494740196d5d46ce525a32dd43782e77f0ce
Reviewed-on: https://boringssl-review.googlesource.com/21404
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This matches the Chromium build. There are some build errors when using
the newer toolchain's headers. This might resolve it? clang-cl
apparently claims VS2013 by default and Microsoft's headers are
sensitive to this.
Change-Id: Ib849e33d8a28649d981ea73972f568fd81e534a1
Reviewed-on: https://boringssl-review.googlesource.com/21244
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Our build logic needed to revised and and clang implements more warnings
than MSVC, so GTest needed more fixes.
Bug: 200
Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842
Reviewed-on: https://boringssl-review.googlesource.com/21204
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Chromium builds with this warning on. This lets us notice problems (of
which there were only one) sooner. I'll try to align the other warnings
in a follow-up.
Change-Id: Id0960b782733b799e1c3e82f89c2aaba0bdd6833
Reviewed-on: https://boringssl-review.googlesource.com/21164
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Fixes failed compile with [-Werror=implicit-fallthrough=], which is
default on gcc-7.x on distributions like fedora.
Enabling no implicit fallthrough for more than just clang as well to
catch this going forward.
Change-Id: I6cd880dac70ec126bd7812e2d9e5ff804d32cadd
Signed-off-by: Vincent Batts <vbatts@redhat.com>
Reviewed-on: https://boringssl-review.googlesource.com/20564
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Someone tried to build us with Ubuntu's MinGW. This is too old to be
supported (the tests rather badly fail to build), but some of the fixes
will likely be useful for eventually building Clang for Windows
standalone too.
Change-Id: I6d279a0da1346b4e0813de51df3373b7412de33a
Reviewed-on: https://boringssl-review.googlesource.com/19364
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I'm not sure why these aren't on by default, but Chromium does this too.
Colors are nice.
Change-Id: I7d7bf006014e9f40ec2f48290ad8fe7a70c1cfce
Reviewed-on: https://boringssl-review.googlesource.com/18704
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In particular, this removes -fno-rtti, which allows the OSS-Fuzz folks
to run with -fsanitize=vptr. See
https://github.com/google/oss-fuzz/issues/741.
(-fsanitize=vptr isn't especially useful right now as we're just
starting with C++ support, but perhaps it'll be more useful in the
future.)
Change-Id: Ie8944a3e637ebc8dc28c03d331923a7528d7d328
Reviewed-on: https://boringssl-review.googlesource.com/18484
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Short-term, we will need to use these macros and build without RTTI when
defining any virtual base class. Long-term, it would be good to remove
these constraints, but it will require some downstream work.
Bug: 132
Change-Id: I3bc65bb12d7653978612b7d1bf06f772a2f3b1cd
Reviewed-on: https://boringssl-review.googlesource.com/18344
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This serves two purposes:
1. Make sure we don't accidentally write "throw" or "catch" in our code.
2. If a C project statically links to our libssl.a, they'll use gcc
rather than g++ as the linker which does not pull in the C++ runtime.
-fno-exceptions cuts out the C++ runtime dependency. (Though we will
need to give up on this should we attempt to allow a runtime
dependency in the future.)
Bug: 132
Change-Id: I9fc81f034833ec9ed38b98d98df7b45c32cfa30c
Reviewed-on: https://boringssl-review.googlesource.com/18084
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This will catch failures standalone before they reach consumers.
Change-Id: I1957df92e02ef7b4c609cd85420535c94ae3a04c
Reviewed-on: https://boringssl-review.googlesource.com/18005
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Iefe4790094e2b2c6f9ef0833c00ab37707b7b19a
Reviewed-on: https://boringssl-review.googlesource.com/17805
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Although Microsoft does not support building with /Wall, starting
VS2017, they provide a way to suppress warnings only in STL code. This
lets us keep some warnings active on our code while disabling them in
the STL.
https://blogs.msdn.microsoft.com/vcblog/2017/02/06/stl-fixes-in-vs-2017-rtm/
We currently still support VS2015, so we can't switch most of our
suppressions to this, but anything which applies only to VS2017 and up
will work.
Change-Id: I5f6d621dd1dbc060e09bded776d1714785a63147
Reviewed-on: https://boringssl-review.googlesource.com/17245
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Most importantly, this version of delocate works for ppc64le. It should
also work for x86-64, but will need significant testing to make sure
that it covers all the cases that the previous delocate.go covered.
It's less stringtastic than the old code, however the parser isn't as
nice as I would have liked. I thought that the reason we put up with
AT&T syntax with Intel is so that assembly syntax could be somewhat
consistent across platforms. At least for ppc64le, that does not appear
to be the case.
Change-Id: Ic7e3c6acc3803d19f2c3ff5620c5e39703d74212
Reviewed-on: https://boringssl-review.googlesource.com/16464
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This introduces machinery to start embedding the test data files into
the crypto_test binary. Figuring out every CI's test data story is more
trouble than is worth it. The GTest FileTest runner is considerably
different from the old one:
- It returns void and expects failures to use the GTest EXPECT_* and
ASSERT_* macros, rather than ExpectBytesEqual. This is more monkey
work to convert, but ultimately less work to add new tests. I think
it's also valuable for our FileTest and normal test patterns to align
as much as possible. The line number is emitted via SCOPED_TRACE.
- I've intentionally omitted the Error attribute handling, since that
doesn't work very well with the new callback. This means evp_test.cc
will take a little more work to convert, but this is again to keep our
two test patterns aligned.
- The callback takes a std::function rather than a C-style void pointer.
This means we can go nuts with lambdas. It also places the path first
so clang-format doesn't go nuts.
BUG=129
Change-Id: I0d1920a342b00e64043e3ea05f5f5af57bfe77b3
Reviewed-on: https://boringssl-review.googlesource.com/16507
Reviewed-by: Adam Langley <agl@google.com>
Due to issues with CMake enable_language, we have to delay setting
CMAKE_ASM_FLAGS until after enable_language(ASM) has been called.
We also need to remove the '.file' macro from x86gas.pl to prevent the
filenames from being overridden from those provided by the build
system.
Change-Id: I436f57ec45e4751714af49e1211a0d7810e4e56a
Reviewed-on: https://boringssl-review.googlesource.com/16127
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The bots will need to get libFuzzer externally. As usual, borrow
Chromium's copy.
Change-Id: I5ed879bbc76188838adcf9d51855e76c481ace5b
Reviewed-on: https://boringssl-review.googlesource.com/16146
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This works better with util/generate_build_files.py.
Change-Id: Icb55dc74e0a004aca3e09978640455b66f0473ff
Reviewed-on: https://boringssl-review.googlesource.com/15648
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The built-in CMake support seems to basically work, though it believes
you want to build a fat binary which doesn't work with how we build
perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at
all, wrap all the generated assembly files in ifdefs, and convince the
build to emit more than one. Probably not worth bothering for now.)
We still, of course, need to actually test the assembly on iOS before
this can be shipped anywhere.
BUG=48
Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832
Reviewed-on: https://boringssl-review.googlesource.com/14645
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This would have caught
https://boringssl-review.googlesource.com/c/12400/ and similar classes
of errors with using CBB. A follow-up change will update the builders
to use -DASAN=1 for ASan.
Change-Id: I37817cb1d6bfd5c82ff0b0afaecc8bbbf506bb92
Reviewed-on: https://boringssl-review.googlesource.com/14025
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
TEST_P didn't work without fixing the suppression, so I went ahead and
fixed it across the entire project.
BUG=129
Change-Id: I5fe417f720040b627acfb3ed2063afdc85dfa908
Reviewed-on: https://boringssl-review.googlesource.com/13824
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
CMake's language is a little dumb about string interpolation. Set it to
"generic", which is the value OPENSSL_NO_ASM uses.
Change-Id: Id98a0309e24465f10bcd7dab4a2000d1038edac0
Reviewed-on: https://boringssl-review.googlesource.com/13261
Reviewed-by: Kenny Root <kroot@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
For now, this is the laziest conversion possible. The intent is to just
get the build setup ready so that we can get everything working in our
consumers. The intended end state is:
- The standalone build produces three test targets, one per library:
{crypto,ssl,decrepit}_tests.
- Each FOO_test is made up of:
FOO/**/*_test.cc
crypto/test/gtest_main.cc
test_support
- generate_build_files.py emits variables crypto_test_sources and
ssl_test_sources. These variables are populated with FindCFiles,
looking for *_test.cc.
- The consuming file assembles those variables into the two test targets
(plus decrepit) from there. This avoids having generate_build_files.py
emit actual build rules.
- Our standalone builders, Chromium, and Android just run the top-level
test targets using whatever GTest-based reporting story they have.
In transition, we start by converting one of two tests in each library
to populate the three test targets. Those are added to all_tests.json
and all_tests.go hacked to handle them transparently. This keeps our
standalone builder working.
generate_build_files.py, to start with, populates the new source lists
manually and subtracts them out of the old machinery. We emit both for
the time being. When this change rolls in, we'll write all the build
glue needed to build the GTest-based tests and add it to consumers'
continuous builders.
Next, we'll subsume a file-based test and get the consumers working with
that. (I.e. make sure the GTest targets can depend on a data file.)
Once that's all done, we'll be sure all this will work. At that point,
we start subsuming the remaining tests into the GTest targets and,
asynchronously, rewriting tests to use GTest properly rather than
cursory conversion here.
When all non-GTest tests are gone, the old generate_build_files.py hooks
will be removed, consumers updated to not depend on them, and standalone
builders converted to not rely on all_tests.go, which can then be
removed. (Unless bits end up being needed as a malloc test driver. I'm
thinking we'll want to do something with --gtest_filter.)
As part of this CL, I've bumped the CMake requirements (for
target_include_directories) and added a few suppressions for warnings
that GTest doesn't pass.
BUG=129
Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a
Reviewed-on: https://boringssl-review.googlesource.com/13232
Reviewed-by: Adam Langley <agl@google.com>
Get us a little closer to productionizing the coverage generation, which
will require taking all the logic out of the coverage script.
Change-Id: If410cc198a888ee87a84b1c2d532322682d3c44e
Reviewed-on: https://boringssl-review.googlesource.com/13043
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This only works with Clang, and MSAN seems to have a false-positive for
me in libstdc++, but it can be helpful to test with these
Change-Id: I068edabcda69c9239ee4f0247f5d8f873dea77bb
Reviewed-on: https://boringssl-review.googlesource.com/12940
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change contains a C implementation of SHA-1 for POWER using
AltiVec. It is almost as fast as the scalar-only assembly implementation
for POWER/POWERPC family in OpenSSL but it is easier to maintain and it
allows error checking with tools like ASAN.
This is tested only for ppc64le. It may nor may not work for other
platforms in the POWER/POWERPC familiy.
Before:
SHA-1 @ 16 bytes: ~30 MB/s
SHA-1 @ 8K: ~140 MB/s
After:
SHA-1 @ 16 bytes: ~70 MB/s
SHA-1 @ 8K: ~480 MB/s
Change-Id: I790352e86d9c0cc4e1e57d11c5a0aa5b0780ca6b
Reviewed-on: https://boringssl-review.googlesource.com/12203
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
TLS 1.3 adds a number of places with extensions blocks that don't easily
fit into our ClientHello/EncryptedExtensions callbacks. Between
HelloRetryRequest, ServerHello, draft 18 going nuts with Certificate,
and NewSessionTicket when we do 0-RTT, this passes the "abstract things
that are repeated three times" sniff test.
For now, it rejects unknown extensions, but it will probably grow an
allow_unknown parameter for NewSessionTicket.
This involves disabling some MSVC warnings, but they're invalid as of
C99 which we otherwise require. See
https://connect.microsoft.com/VisualStudio/feedback/details/1230248/remove-c99-related-warnings-or-make-them-off-by-default
Change-Id: Iea8bf8ab216270c081dd63e79aaad9ec73b3b550
Reviewed-on: https://boringssl-review.googlesource.com/12233
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Fuzzer mode explores the handshake, but at the cost of losing coverage
on the record layer. Add a separate build flag and client/server
corpora for this mode.
Note this requires tweaks in consumers' fuzzer build definitions.
BUG=111
Change-Id: I1026dc7301645e165a761068a1daad6eedc9271e
Reviewed-on: https://boringssl-review.googlesource.com/12108
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We run with a few more arguments, we may as well pass them in.
Change-Id: Icd7196fc50983f77d500b96e0cc4f9bc583671bf
Reviewed-on: https://boringssl-review.googlesource.com/11603
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
