Clang 10 added a new check we and libjpeg-turbo fail.
We need to investigate these failures, but I don't
want that to stop us rolling clang_win.
Bug: skia:9731
Change-Id: Ifdbb16ea0e2bacd30547d4a82a839563a9496d9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/260948
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
I've landed fixes for most of these,
leaving -Wclass-memaccess as a TODO.
Bug: skia:9674
Change-Id: Ifb951bc66e022b48ff4b66e4555d3fe3c7ef5aaf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/257501
Reviewed-by: Ben Wagner aka dogben <benjaminwagner@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I2619784eca0f7a4dd66f2db0104cb746d9266b4e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/244369
Commit-Queue: John Rosasco <rosasco@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
With this change C++17 language features can be used in code that does
not need to be be included in client code (not in public headers or
the files they transitively include).
We haven't investigated the c++17ness of the standard libraries in use
by clients so proceed with caution on library features.
One thing discovered along the way: throw() in C++17 is now equivalent
to noexcept(true). Moreover, the noexcept-ness of a function is part of
its type in C++17. This means that if a header declares a function with
throw() and it is included in a cpp compiled with C++17 file it will have
a different type than if it is compiled in a file compiled with C++14 (or
earlier) and you can get linker errors. Here is a change we had to make
as a result of this:
https://skia.googlesource.com/skia.git/+/4d0fe38f29388ef0aa6893d1d4fc237e758dd11f%5E%21/#F0
Change-Id: I996f2237fdd6b49e2e4cc8d3ff6db9dd536eafd8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/235022
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
With XCode 11 there is no more /usr/include directory. This
does not affect the XCode compilers, but does make goma compiler
break. This finds the system includes the same way that the iOS
builds currently do.
The gn_to_bp.py tool runs gn with target_os == mac, but host_os != mac.
In that case, the xcrun tool can not run, so make xcode_sysroot = "". This will
allow the xcode compilers to work when using the android.bp to build things.
TESTED:
builds on mac with and without goma
Change-Id: I9de6797c32760c59e62fe5ac505a3404e5eaf8e9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249537
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
We've failed to get these bots to report where issues happen
any more finely than the name of the executable, which makes
them a real pain to fix when they go red.
We don't expect we'll be able to run cleanly in this mode for
long without bots enforcing it, so remove support from GN too.
Change-Id: Ie86f0cbf2f5f859ac2ddb869da7e5b8d31b33fa0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/237195
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I127c979670c3dc7dac2e35908a795afbdefca8f6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234902
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
If you just use the right compiler driver wrapper, recent NDKs automate
lots of the stuff we used to have to do ourselves.
Simplifying further, bump baseline ndk_api from 16 (Jellybean) on 32-bit
machines and 21 (Lollipop) on 64-bit to 21 across the board. This makes
using libc++ a lot easier, as it hooks into a bunch of APIs that were
added in 18 and 21. There's probably some way to work around this, but
the easiest thing is to just roll up.
Tested building {x86,arm}x{32,64} from a Linux host,
and running { arm}x{32,64}.
Kind of flailing around in later CLs trying to get linking not to hang
on Windows. I figure it's got something to do with lld?
Cq-Include-Trybots: skia.primary:Build-Win-Clang-arm64-Release-Android
Change-Id: I340b06fb9d372281146679d932417aaba3196045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225506
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Something's trying to link libc++.so by default,
so ask it to link libc++.a with -static-libstdc++.
Either way, the linker can't find libc++ without
adding another library directory path.
I think both changes should be harmlessly ignored
before r20.
Change-Id: I5b67e1dcb8b40548dae5a8300151e4392ae551f9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225436
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
-dead_strip works just fine there without those flags,
and they interfere with embedded bitcode.
Change-Id: If3766d245334fd9fa275e90fe67216ababafcecb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222450
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will ensure that the headers from the dependencies will have
precedent over system headers, thus preventing situations where system
headers will block dependency headers and prevent compilation.
Change-Id: I0d480a6d3898f2da99cf2706c5335aaac05b4e4d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220276
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Start out with spinlock. I tried to be more extensive, but some
of our abstractions confused the analysis. Will expand further
in following CLs.
Change-Id: I3e320c957d8ef427065a2b7e7d2187b7c6b0aef1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/213060
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Most external users complain about -Werror,
and I've heard anecdotally that devs find it annoying too.
This turns it off by default, but keeps it on the bots.
Change-Id: I6e87c92215261ebf6e961f816177386d5d58f28e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209787
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Nothing too tricky...
1) tell clang-cl to --target=arm64-windows
2) work around minor libpng issue temporarily
Change-Id: I4f0d792438610268821b67b92caf08fd78dcec4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/208882
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These changes let us build a non-official component build on Windows,
using either MSVC or clang
Change-Id: Ia3279aa19e007e70ff28925ff70a0bfe8144d96f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/207307
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I've been setting this in extra_cflags for a couple years...
maybe it's time everyone gets color in their warnings.
Change-Id: I1fed38a521fe9331b60fbb0688d39b5188a86aca
Reviewed-on: https://skia-review.googlesource.com/c/196360
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Just a few strays.
Change-Id: Ib209bc8dd228850b837b850dce14967a2112593e
Reviewed-on: https://skia-review.googlesource.com/c/191161
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
a54104803d..52d861bd49
git log a54104803d72..52d861bd49cc --date=short --no-merges --format='%ad %ae %s'
2019-02-02 syoussefi@chromium.org Disable -Wextra-semi-stmt
2019-02-02 ianelliott@google.com Implement EGL_ANDROID_recordable for Vulkan back-end.
2019-02-01 jonahr@google.com Fix unnecessary copy of for loop variables in ANGLE
2019-02-01 syoussefi@chromium.org Use env variable to select default backend
2019-02-01 jmadill@chromium.org Enable -Wextra-semi and -Wextra-semi-stmt.
2019-02-01 syoussefi@chromium.org Initial support for compiler AST validation
2019-02-01 jmadill@chromium.org Roll glslang.
2019-02-01 ckulakowski@opera.com Fix for linking of non-component angle_unittests
Created with:
gclient setdep -r third_party/externals/angle2@52d861bd49cc
The AutoRoll server is located here: https://autoroll.skia.org/r/angle-skia-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.
CQ_INCLUDE_TRYBOTS=skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia.primary:Perf-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-ShuttleC-GPU-GTX960-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-ShuttleC-GPU-GTX960-x86_64-Debug-All-ANGLE
TBR=borenet@google.com
Change-Id: I008df064f6301658404c371cf47a5656d8c11621
Reviewed-on: https://skia-review.googlesource.com/c/188852
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
This enables four different options in the compiler, described
below. I also added enough masks to satisfy RTCc when running
all GMs in both 8888 and gl configs.
---
/RTCc - Detects when a value is assigned to a smaller data
type and results in data loss. This happens even when casting.
Masking is required to suppress this.
/RTCs - Various stack-related checks, including uninitialized
data (by initializing locals to a non-zero value), array bounds
checking, and stack pointer corruption that can occur with a
calling convention mismatch.
/RTCu - Reports when a variable is used without having been
initialized. Mostly redundant with compile-time checks.
/guard:cf - This is more of a security option, that computes
all possible targets for indirect calls at compile time, and
verifies that those are the only targets reached at compile
time. Also generates similar logic around switch statements
that turn into jump tables.
Bug: skia:
Change-Id: I7b527af8fd67dec0b6556f38bcd0efc3fd505856
Reviewed-on: https://skia-review.googlesource.com/c/188625
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: I09c2312c3678bdb1c48b427f446cb5865acb92a2
Reviewed-on: https://skia-review.googlesource.com/c/177074
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Might open up some neat options like LTO builds.
If nothing it's nice to use each whole toolchain consistently.
Move around some bonus quotes a bit.
LLD doesn't understand /DEBUG:FASTLINK.
Change-Id: I27e3c97acea6980c5bd006394aebb1e103007edd
Reviewed-on: https://skia-review.googlesource.com/c/175981
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I9ba1caa4862bdf9ffc9c0e637bd69cce91fd8468
Reviewed-on: https://skia-review.googlesource.com/c/168740
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is a reland of 166dbd3135
Since last attempt,
- update SkPath::Direction docs
- kIllegal is not an advanced blend mode
Original change's description:
> make enum santizer fatal
>
> This enum sanitizer checks that all the values of the enum we use fall
> within the range of the enumerated values.
>
> The main thing this helps point out is that the size of enum types in
> C++ need only be large enough to hold the largest declared value; larger
> values are undefined. In practice, most enums are implemented as ints
> for compatibility with C, so while this hasn't pointed out anything
> egregiously broken, the sanitizer has found a couple possibly dangerous
> situations in our codebase.
>
> For most types using values outside the enum range, we can just
> explicitly size them to int. This makes their de facto size de jure.
>
> But we need to actually make GrBlendEquation and GrBlendCoeff not store
> values outside their enumerated range. They're packed into bitfields
> that really can't represent those (negative) values. So for these I've
> added new kIllegal values to the enums, forcing us to deal with our
> once-silent illegal values a bit more explicitly.
>
> Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
> Reviewed-on: https://skia-review.googlesource.com/c/168484
> Reviewed-by: Brian Osman <brianosman@google.com>
Cq-Include-Trybots: skia.primary:Housekeeper-PerCommit-Bookmaker,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-All-Android
Change-Id: Id93b80bbeae11872542c9b76715e3c3cb10609fd
Reviewed-on: https://skia-review.googlesource.com/c/168582
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 166dbd3135.
Reason for revert: illegal is not advanced, docs
Original change's description:
> make enum santizer fatal
>
> This enum sanitizer checks that all the values of the enum we use fall
> within the range of the enumerated values.
>
> The main thing this helps point out is that the size of enum types in
> C++ need only be large enough to hold the largest declared value; larger
> values are undefined. In practice, most enums are implemented as ints
> for compatibility with C, so while this hasn't pointed out anything
> egregiously broken, the sanitizer has found a couple possibly dangerous
> situations in our codebase.
>
> For most types using values outside the enum range, we can just
> explicitly size them to int. This makes their de facto size de jure.
>
> But we need to actually make GrBlendEquation and GrBlendCoeff not store
> values outside their enumerated range. They're packed into bitfields
> that really can't represent those (negative) values. So for these I've
> added new kIllegal values to the enums, forcing us to deal with our
> once-silent illegal values a bit more explicitly.
>
> Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
> Reviewed-on: https://skia-review.googlesource.com/c/168484
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@chromium.org,mtklein@google.com,brianosman@google.com
Change-Id: I691c08092340a6273e442c0f098b844f7d0363ba
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/168581
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This enum sanitizer checks that all the values of the enum we use fall
within the range of the enumerated values.
The main thing this helps point out is that the size of enum types in
C++ need only be large enough to hold the largest declared value; larger
values are undefined. In practice, most enums are implemented as ints
for compatibility with C, so while this hasn't pointed out anything
egregiously broken, the sanitizer has found a couple possibly dangerous
situations in our codebase.
For most types using values outside the enum range, we can just
explicitly size them to int. This makes their de facto size de jure.
But we need to actually make GrBlendEquation and GrBlendCoeff not store
values outside their enumerated range. They're packed into bitfields
that really can't represent those (negative) values. So for these I've
added new kIllegal values to the enums, forcing us to deal with our
once-silent illegal values a bit more explicitly.
Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
Reviewed-on: https://skia-review.googlesource.com/c/168484
Reviewed-by: Brian Osman <brianosman@google.com>
This is a reland of c766370d86
Original change's description:
> always optimize third_party code
>
> Change-Id: I5b2244460a4760e9336640f597d0f74c374a0d04
> Reviewed-on: https://skia-review.googlesource.com/155641
> Commit-Queue: Mike Klein <mtklein@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Auto-Submit: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I63e7f9ca852fc99728d7a01d9987b3506115d266
Reviewed-on: https://skia-review.googlesource.com/155760
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit c766370d86.
Reason for revert: speculative -- trying to fix Debian breaks (pdf?)
Original change's description:
> always optimize third_party code
>
> Change-Id: I5b2244460a4760e9336640f597d0f74c374a0d04
> Reviewed-on: https://skia-review.googlesource.com/155641
> Commit-Queue: Mike Klein <mtklein@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Auto-Submit: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,brianosman@google.com
Change-Id: I5467c95f9487c31e6f538f13579e490cdaeeee2e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/155607
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: I5b2244460a4760e9336640f597d0f74c374a0d04
Reviewed-on: https://skia-review.googlesource.com/155641
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Without this, debug clang builds on windows have very little debug info.
Fix is based on Chromium's handling of this (they have several tactics,
depending on linker, etc...)
https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?l=2194
Change-Id: Ib1b3aa4cdf4e2daa762d994bea94dc3c691cf359
Reviewed-on: https://skia-review.googlesource.com/154540
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
People using is_official_build don't really want to see warnings.
They're for devs, not users.
The somewhat odd update to gn/BUILDCONFIG.gn keeps command
line flag precedence (later == more important) unchanged.
Change-Id: I1a04a35f066b7408021d474535f0dbf4928e21d3
Reviewed-on: https://skia-review.googlesource.com/151380
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We're close enough that it's easier to use "undefined"
to turn on all supported UBSAN sanitizers and then
keep a couple in fyi_sanitizers as a blacklist.
I'm going to try to fix "enum" next too, so hopefully
that won't be in there too long.
I did a little flag cleanup too. -fno-omit-frame-pointer
was harmlessly in there twice for Android builds.
Change-Id: I8216fb0685423b2ff56db2e2be5bbeb4b48f932f
Reviewed-on: https://skia-review.googlesource.com/146760
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Change-Id: Ibfead1121f22277297e16196b37e6e86dc2d2166
Reviewed-on: https://skia-review.googlesource.com/146649
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This sanitizer checks for overaligned reads and writes,
or put another way, use of underaligned pointers.
This usually happens when you cast, e.g. char* to int*
without checking that the char* is 4-byte aligned. Each
of the changes under src/ fixes something just like that.
The unusual setup for tools/xsan.blacklist is there to
force a rebuild whenever tools/xsan.blacklist changes.
I spent a good few minutes debugging rebuilds not happening
this morning, perhaps from some strange ccache interaction.
Align SkTextBlobs as void* (today they're just 4-byte) so the
SkTextBlob::RunRecords we put after them in SkTextBlobBuilder
buffers are properly aligned (for the SkTypeface* inside).
There's no obvious error in void SkRRect::computeType(),
but one bot seems to have seen some sort of issue with
SK_AT_SCOPE_EXIT(SkASSERT(this->isValid()));
I can't reproduce it locally, so I'm just going to unroll it.
Change-Id: I904d94f65f695e1b626b684c32216a4930b72b0c
Reviewed-on: https://skia-review.googlesource.com/146104
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
build debug on linux for gdb
Building with this define enables additional
checks for standard library functions when
running gdb, and allows printing std::string.
R=halcanary@google.com
Bug: skia:
Change-Id: I7f2dc12336f9239443328f13264be7a6b285c4b5
Reviewed-on: https://skia-review.googlesource.com/140786
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-on: https://skia-review.googlesource.com/141083
Commit-Queue: Cary Clark <caryclark@skia.org>
This reverts commit 3c3db72e69.
Reason for revert: I suspect this is breaking the Build-Debian9-Clang-arm-Debug-Chromebook_GLES bot
Original change's description:
> build debug on linux for gdb
>
> Building with this define enables additional
> checks for standard library functions when
> running gdb, and allows printing std::string.
>
> R=halcanary@google.com
>
> Bug: skia:
> Change-Id: Ib71c179d8cbacbcd7f17a1c85f912072918e6be8
> Reviewed-on: https://skia-review.googlesource.com/140786
> Commit-Queue: Cary Clark <caryclark@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,halcanary@google.com,caryclark@google.com
Change-Id: I56ae1c6c02032e6445f5585de51c48423d283636
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/140840
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Building with this define enables additional
checks for standard library functions when
running gdb, and allows printing std::string.
R=halcanary@google.com
Bug: skia:
Change-Id: Ib71c179d8cbacbcd7f17a1c85f912072918e6be8
Reviewed-on: https://skia-review.googlesource.com/140786
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: I4bbf3e5e6d9d4e11e968a0bc88ce43444047a382
Reviewed-on: https://skia-review.googlesource.com/130903
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
I know SkRasterPipelineBlitter will add back offsets
to the mask pointer to make these fMaskPtr.pixels safe.
SkImageInfo wasn't making out-of-bounds pointers, but was moving
between two in-bounds pointers by subtracting large (negative)
size_t. Switching to explicit negate and add quiets this down.
Bug: chromium:836282
Change-Id: Ia65e380ec41dbfedce0659106830fbacb1a5cf4a
Reviewed-on: https://skia-review.googlesource.com/131147
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: Ic5efe371b6365913a47d833c698958cc842d16ae
Reviewed-on: https://skia-review.googlesource.com/128685
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
