Change-Id: Ifb47c6be05bffad4a42030f4375dcbe0fe313ae0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293656
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
I was hoping this might fix the issues I'm seeing in the dependent CL.
It doesn't, but it's probably worth rolling every few months anyway.
Change-Id: I6d748d9e1a5bf908df78e989a624f2dccb1bd189
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293604
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is an Android request for our public headers,
much like warning about unused parameters. See bug.
In general I've made two kinds of source changes:
1) more commonly, explicitly cast to the type which
is being implicitly cast to at head;
2) less commonly, flip signedness of a value we're
storing to match how it's used more smoothly.
Much of this is self inflicted inconsistent use of size_t, unsigned,
int, int32_t, uint32_t, etc. SkTArray is particularly tricky because
of its std::vector half-compatibility. E.g. resize() takes size_t,
but operator[] takes int. ¯\_(ツ)_/¯
Bug: skia:9847
Change-Id: I64626a529e1662b3d3020bc03d477fc641eda544
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293436
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We don't have any way to test these, and we do have to
go a little out of our way to maintain these builds.
Change-Id: Ie191ee26753b719f6ee22264d63fbe4252e69bd5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/290840
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
- Lots of skstd::foo is now std::foo since C++14.
- Get rid of SK_WHEN(cond,T); std::enable_if_t<cond,T> is pithy enough.
- Move SkBitmaskEnum.h contents into sknonstd.
Change-Id: Ie5dc459405b1ff55e5b3ac57e70df7edd7cf38c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/286315
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I2d19c4f0ff1439dcd923a3064eb3ba78432a5113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281043
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This reverts commit e990fcc4b0.
Reason for revert: Build-Win-Clang-x86_64-Release-Shared
Original change's description:
> Enable deprecated-copy-dtor warning.
>
> In C++11 a user declared destructor still requires the compiler to
> implicitly default the copy constructor and copy assignment operator,
> but this is deprecated. Note that a user declared destructor suppresses
> the move constructor and move assignment operator; a user declared
> destructor exists if any '~Foo' method declaration appears inside
> 'class Foo' (even if defaulted); if the copy and move operations are the
> same then copy operations that take 'const Foo&' will do fine double
> duty as move operations.
>
> Clang seems to have an issue with this warning, in that it does not
> appear to distinguish between compiler defaulted and user defaulted
> destructors. As a result, it does not always warn when it should.
> There may yet be places in the code where a move operation is desired
> but may be suppressed because the implicitly defaulted moves are not
> declared because a destructor has been declared.
>
> This wraps dawn and shaderc configs in 'third_party' so that their
> headers will be included through '-isystem' in order to avoid the
> warnings generated by including their headers.
>
> Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,bungeman@google.com
Change-Id: Icd6a2487637d21fcf7c4c7ab7cba7a8adfda5afd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280836
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
In C++11 a user declared destructor still requires the compiler to
implicitly default the copy constructor and copy assignment operator,
but this is deprecated. Note that a user declared destructor suppresses
the move constructor and move assignment operator; a user declared
destructor exists if any '~Foo' method declaration appears inside
'class Foo' (even if defaulted); if the copy and move operations are the
same then copy operations that take 'const Foo&' will do fine double
duty as move operations.
Clang seems to have an issue with this warning, in that it does not
appear to distinguish between compiler defaulted and user defaulted
destructors. As a result, it does not always warn when it should.
There may yet be places in the code where a move operation is desired
but may be suppressed because the implicitly defaulted moves are not
declared because a destructor has been declared.
This wraps dawn and shaderc configs in 'third_party' so that their
headers will be included through '-isystem' in order to avoid the
warnings generated by including their headers.
Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
GCC 9 warns about this pessimizing-move. It isn't clear why clang isn't
as well.
GCC 9 has a working redundant-move diagnostic. Clang has an old (C++11
style) redundant-move diagnostic which only warns when moving a
parameter. The GCC warning conflicts with Clang's
return-std-move-in-c++11, which we want to keep until we can drop
support for older compilers. So just disable redundant-move warnings
until we can remove return-std-move-in-c++11.
This change allows us to compile without warnings on gcc 9.3.0.
Change-Id: If21fcfb2944ce49e27fc84d40805752895ae68cf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279958
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
It wants a blank line before a comment, even though the comment isn't a
break.
Change-Id: I6a2988719942e5e72142b8484182c128392a4be8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279842
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Ben Wagner <bungeman@google.com>
Unfortunately in clang 'deprecated' is both a set of warnings (at least
one of which we don't want) and a group of warnings (most of which we do
want). Leave the top level disabled, but re-enable all the warnings in
the group.
Most of the code changes are for the deprecated-copy diagnostic. In
C++11 implementing a copy constructor xor copy assignment operator
the default implementation of the other is still required to be the
default but is deprecated (the compiler can warn against doing this).
The idea is that if there was a need for a non-default copy constructor
or copy assignment operator then both should be implemented explicitly,
since it is unlikely that the default will do what is expected.
Note that the deprecated-copy-dtor has not yet been enabled as there
will need to be a lot more work to enable this diagnostic. Similar to
deprecated-copy, in C++11 when implementing a destructor the copy
constructor and copy assignment operator are still defaulted if not
declared, but this is also deprecated. The idea here is that if some
special handling is needed to destroy the object there is probably some
need to do something non-trivial when copying the object (or copying
should be disallowed).
Also, there are still some deprecated-declarations to clean up on
Android and Mac.
Change-Id: I5fc4b62713220e6f7d3724fd7342b4c8c74a3c67
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278916
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This was a convenience for Cary to not have to use extra_cflags,
and iterferes with using prebuilt C++ code by breaking the ABI.
Change-Id: I9e14ec04106a0abf9b55e5803242c2eb226d6e3f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276445
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
AFAIK, we can replace a lot of preprocessor tests now that we have
[[attributes]] and compilers are supposed to ignore unknown attributes.
Let's see if it works. If this sticks I'll get the rest in a big CL.
-Wattributes and MSVC warning C5030 are kind of annoying as errors,
so turn them off. This does not bode well for rolling into clients.
Change-Id: I88b150bab746c5510ff94f604096bf0ee0c9f96a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271886
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Doesn't seem to trigger.
Change-Id: I481b90a4e7fa0a4badc9acff9df1ec232a62417d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271680
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This CL has a complicated back story, but it's concrete change is
simple, just turning the warning on and converting a bunch of
return foo;
to
return std::move(foo);
These changes are exclusively in places where RVO and NRVO do not apply,
so it should not conflict with warnings like -Wpessimizing-move.
Since C++11, when you return a named local and its type doesn't match
the declared return type exactly, there's an implicit std::move()
wrapped around the value (what I'm making explicit here) so the move
constructor gets an opportunity to take precedence over the copy
constructor. You can read about this implicit move here under the
section "automatic move from local variables and parameters":
https://en.cppreference.com/w/cpp/language/return#Notes.
This situation comes up for us with smart pointers: a function declares
its return type as std::unique_ptr<Base> or sk_sp<Base>, and we return a
std::unique_ptr<Impl> or sk_sp<Impl>. Those types don't match exactly,
so RVO and NRVO don't come into play. They've always been going through
move constructors, and that's not changed here, just made explicit.
There was apparently once a bug in the C++11 standard and compilers
implementing that which made these copy instead of move, and then this
sort of code would do a little unnecessary ref/unref dance for sk_sp,
and would entirely fail to compile for uncopyable std::unique_ptr.
These explicit moves ostensibly will make our code more compatible with
those older compilers.
That compatibility alone is, I think, a terrible reason to land this CL.
Like, actively bad. But... to balance that out, I think the explicit
std::move()s here actually help remind us that RVO/NRVO are not in play,
and remind us we're going to call the move constructor. So that C++11
standard bug becomes kind of useful for us, in that Clang added this
warning to catch it, and its fix improves readability.
So really read this all as, "warn about implicit std::move() on return".
In the end I think it's just about readability. I don't really hold any
hope out that we'll become compatible with those older compilers.
Bug: skia:9909
Change-Id: Id596e9261188b6f10e759906af6c95fe303f6ffe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271601
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Apply -fsanitize-recover=pointer-overflow to third_party code only.
I'm trying to keep Skia behaving the same, avoiding illegal nullptr+k:
- Add null check in SkJSON fast string path.
- Add null check (first alloc) and some comments to SkArenaAlloc.
- March an int index instead dst pointer in SkBase64.
Bug: skia:9731
Change-Id: I646635558ea63ded846b746f2a1f0b4f1e1eacff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268109
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
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>
