Previously, the for statement's "increment/test" expressions were
executed without moving the trace-line back up to the for statement.
When stepping through code, we will now explicitly step to the next/test
line on each loop iteration.
Change-Id: I5d9f005a42150670cec77218323cf932ee1cbdb0
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469180
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This writes an entry to the trace buffer every time a slot value is
changed.
Change-Id: Iac3912be71ad654f70a7158e306e0643086c6cb0
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469179
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will be used to populate a trace buffer for the SkSL debugger.
See http://go/sksl-tracing for details and rationale.
Change-Id: I4c218c65ff01c339cf460e97e41566860a694720
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/468436
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Much like http://review.skia.org/467759, this CL defensively guards
against programs which consume more space than is reasonable. Globals
exist outside of functions, so they wouldn't be caught by the stack size
checks.
Change-Id: I035f27d57bc329508820a729a1e367ecaadfe156
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467760
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Functions that declare variables totaling more than 100,000 slots will
now generate an error.
This is only a partial mitigation to the problem, as a sophisticated
attack could still chain/nest multiple functions together to consume
extremely large amounts of stack. However, this mitigation is still more
sophisticated than our peers; both WebGL and glslang are susceptible to
similar problems, and in the general case (ES3+ with full flow control)
it's intractable.
Change-Id: I153c75267c017a23f59fe9e59f6e391197ee6101
Bug: oss-fuzz:40304, oss-fuzz:40694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467759
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer triggered this error in a strange way that involves parsing a
TK_INVALID token. The fuzzer's original input used \xFF bytes in the
shader text to do this. I replaced these with the ` character since it
behaved the same, but allows our test inputs to remain basic ASCII.
The root problem is that `cast_expression`, part of no-op arithmetic
simplification, can now fail because expressions like `int(4000000000)`
no longer get past Constructor::Convert. Previously we had assumed
`cast_expression` could never return null; now we check its result for
null before using it.
Change-Id: I7335395bab0daf1f788b0c7c154904b2372ae13f
Bug: oss-fuzz:40660
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467316
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Updated ReturnsValueOnEveryPathES3 to remove overlap with the ES2 tests,
and fixed some broken cases. Disabled the ReturnValueOnEveryPathES3 test
on Intel + Windows because switch statements on Intel + Windows are
pretty broken.
Change-Id: Id93e8af1ef7bf11fd74ef12a464c77d56cc032a0
Bug: skia:11209, skia:12465
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467078
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
It's possible to write code containing errors that are only apparent
once the inliner runs. For instance, a function which takes a short and
returns its negative it is valid for most inputs, but undefined for
-32768 (because +32768 does not fit in a short). A function which takes
floats and casts them to ints is valid for many inputs, but not valid if
you pass in 5 billion.
This CL restructures our out-of-range integer error detection to report
errors cleanly in these cases instead of asserting. It also refactors
the range checking code to be usable in situations where we don't yet
have a Literal expression.
Change-Id: I98f0be63bf9afbbf1ab90233fa86d380cfae42b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/466439
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I01d82447658c7acc5fe9eb230eb7020b49fa6c4f
Bug: skia:12498
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/466447
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I7512491f55c10118f0ab058500f6ce9b5b8545cd
Bug: oss-fuzz:40557
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/466296
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This will hopefully improve performance on lower-end GPUs.
Change-Id: I9c2ee6dc31acd08bec0bfb5f59edc3cf90163f9e
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465078
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Ic30c48dce0cb0072f07defcdb0b9e60b94f50818
Bug: oss-fuzz:40479
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465392
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer discovered that SkSL could create an out-of-range int literal
by casting from a floating point literal. We were only doing range
checks when the starting literal was an integer. Since we now assert
when an out-of-range int literal is created (as of
http://review.skia.org/464124), the fuzzer can detect this error.
Change-Id: Ie66f60ddbe7b4fbe5b648c17292c59a4ba079716
Bug: oss-fuzz:40456
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465385
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This guards against unexpected results when dfdy is used in complex
expressions. In practice, I'm not aware of this causing any trouble.
Change-Id: Ia476e57936969d248273856a94d5c403b47c29b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465379
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This guards against unexpected results when dfdy is used in complex
expressions. In practice, I'm not aware of this causing any trouble.
Change-Id: I639bef465d7907049d79681a49f9be67b4c435a6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465378
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 9fc189f1cb.
Reason for revert: shader compile failure on AndroidOne-GPU-Mali400MP2 devices
Original change's description:
> Wrap 'u_rtFlip.y * dfdy()' in parentheses.
>
> This guards against unexpected results when dfdy is used in complex
> expressions. In practice, I'm not aware of this causing any trouble.
>
> Change-Id: I58d4762871481fdb4c173b570e4d5d6edf657af7
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465077
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: Idfaa9316d657717d5ee7117837c9cc9c3d4ee189
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465377
Auto-Submit: Greg Daniel <egdaniel@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This guards against unexpected results when dfdy is used in complex
expressions. In practice, I'm not aware of this causing any trouble.
Change-Id: I58d4762871481fdb4c173b570e4d5d6edf657af7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465077
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
A recent CL (http://review.skia.org/464121) made it an error to coerce a
literal value to a type that cannot hold the value. The fuzzer found a
case where we assumed type-coercion of a literal would always succeed,
and failed to null-check the result. We now null-check the result.
Change-Id: Id97c6016e56c20ef724028f71bbf4688dde3c064
Bug: oss-fuzz:40428
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464919
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Yesterday's negation-related changes (http://review.skia.org/464123)
exposed a flaw that the fuzzer was able to exploit. We were previously
able to assume that `simplify_negation` would always return a non-null
expression; in some cases, that is no longer true.
Change-Id: Ia585232b0e35fafe0c642384a59ef94ce743ffd5
Bug: oss-fuzz:40427
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464916
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
With this change, we no longer have any SkSL tests which are able to
make a Literal integer that overflows its type. Literal::MakeInt now
asserts that its value is within bounds. I look forward to the fuzzer's
inevitable attempts to trigger these assertions.
Change-Id: I7b15e862caaf65984d33f5d72d2c1de816d1d292
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464124
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This was mistakenly using dFdx in some portions (copy-paste error).
Change-Id: Ifb159b3c44185d9166c10725b24002a28a0895b2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464381
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, we would create a Literal with the negated value even if it
was outside the type's minimum/maximum values. Error reporting would
happen elsewhere, if at all (e.g. during assignment or coercion).
Change-Id: I020a93daf2b0f5741fb805a58a690489d7578dab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464123
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, we would create SkSL literals of ints that didn't fit into
an int. This change causes a few errors to report differently. (In
particular, we no longer create global variables containing values that
wouldn't fit in that variable, so those symbols are invalid later.)
Change-Id: I29d219e853126ea78dd2d2a6d8a69b23ef2b06b8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464121
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This was causing errors in UBSAN when compiling some of our existing
SkSL tests.
Change-Id: I66f22607094df77d47ff70948a139c77feae8624
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464118
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These are not very interesting right now, because the in and out types
boil down to the same thing (int/int, float/float). When half-
precision types are enabled, these helpers will be more useful. They
will return an array which casts each element from int-to-short or
float-to-half (or vice versa).
Change-Id: Ida716ddd27d370ba33fd23f17a1b07fa5a201e40
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463337
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The inverse, outerProduct and matrixCompMult polyfill functions in Metal
were written assuming that all float matrices would use the `float`
type. They now use a template so that `half` matrices will work too.
Change-Id: I7696c8ad1e4aaffbd71c56b9245485e74cd96c5a
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463338
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
At this point, it seems like this was a mis-diagnosis of the underlying
issue around dual-source blending (and its interaction with other blend
state).
Change-Id: I11af0c9b70c32e14c353848db3d6adbfe5f08225
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/462176
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
After reporting the error, we convert the reserved word to an identifier
as this led to the best error reporting. (This avoids double error
reporting or strange cascading errors.)
Change-Id: I67209bc342fe794287baeaaaf34fa77afd4ac26b
Bug: skia:12560
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/462096
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I894bfa01e7cf58f140423554d0200b6c66beef35
Bug: oss-fuzz:39998
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459883
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is supported in GLSL ES3. (Strangely, vector operator! isn't.)
Previously, this was flagged as an error: http://review.skia.org/459885
Change-Id: I2c4299159fff58fefe8bd131c8d317cd82974a62
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459886
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
At present, we only detect four errors here. We should detect six.
Change-Id: I226854ab930a273695c42cf2f7bdb1d5cd97e50b
Bug: oss-fuzz:39998
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459882
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
See http://review.skia.org/460037 for an example of the existing
behavior. Const variables are constant-expressions and should be allowed
here.
Change-Id: I41383d79668785f270b7825485e9f6fa56c553c1
Bug: skia:12549
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/460036
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We now detect attribute, varying, precision and invariant as reserved.
Change-Id: I8c90655a70b1bad31bf6143c3fdcb2ce582320b1
Bug: skia:12484
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459479
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
`samplerCube` is a type which we don't support at all. It has been added
to the reserved-word list.
`textureCube` was in our list of built-in types, but was not actually
used in any way; it wasn't actually added to the root or private symbol
tables, and was totally unreferenced by the code. It's been deleted.
Change-Id: I4f79ce5d40ac6ebdb2a7067fa60cc79e316b01b6
Bug: skia:12484
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459123
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit eb68973c2f.
Reason for revert: ES2 conformance test checks this
Original change's description:
> Disallow matrix ctors which overflow a column.
>
> The GLSL spec allows matrix constructors containing vectors that would
> split between multiple columns of the matrix. However, in practice, this
> does not actually work well on a lot of GPUs!
>
> - "cast not allowed", "internal error":
> Tegra 3
> Quadro P400
> GTX 660
> GTX 960
> - Compiles, but generates wrong result:
> RadeonR9M470X
> RadeonHD7770
>
> Since this isn't a pattern we expect to see in user code, we now report
> it as an error at compile time. mat2(vec4) is treated as an exceptional
> case and still allowed.
>
> Change-Id: Id6925984a2d1ec948aec4defcc790a197a96cf86
> Bug: skia:12443
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449518
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:12443
Change-Id: I5a32744c88b9b830ad657488824c8c7dd0b0a652
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458056
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Previously, in public code, private types didn't exist anywhere in the
symbol table chain, and those names were free for the taking. Now, we
register them as invalid types in the public symbol table. This prevents
them from being used as variable names, and gives a more explicit error
if you try to use them as a type.
Change-Id: I9a943bf923639b72cbf36b1acf4b4fbe70982786
Bug: skia:12538
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459119
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
GLSL treats builtin types and user-defined types differently; `int` and
`float` are keywords and cannot be used to name variables. However, it's
fine for a user type like `struct xyz` to be hidden by a variable
`int xyz` or even `xyz xyz` (i.e., a variable of type `struct xyz` named
`xyz`).
We now honor that distinction and include tests for it. This will fix
several ES2 conformance tests (local_struct_variable_hides_struct_type,
local_int_variable_hides_struct_type, etc.).
Change-Id: I7a45c70707087f9f355ce5b06b032fed16683f3e
Bug: skia:12527
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458721
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This fixes GLSL ES2 conformance test `array`.
Change-Id: I6ebee9253e1e8c394d9ddb6899e3a0940b7a38ef
Bug: skia:12495
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458718
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkSL treated these two functions as distinct, even though they are not:
void func(in float x);
void func(float x);
The `in` modifier on a function parameter is the default state, making
these two prototypes functionally identical. We now strip off an `in`
modifier on a function definition. This gives us three potential states
for each param: nothing (meaning `in`), `out`, and `inout`.
Change-Id: Id2acb53ecaca98f86a7f6a83e0b9a375f9abe2b8
Bug: skia:12525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458257
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer has found that it can get timeouts in SkVM by nesting loops
very very deeply, then at the bottom of the chain, making an inside-out
loop that runs for zero iterations. This has a calculated unrolled-size
of zero, but SkVM would still think hard about unrolling the (ultimately
empty) outer loops.
SkSL now optimizes away unrollable loops that run for zero iteratinons,
as well as empty unrollable loops. This should eliminate the fuzzer's
troublesome construct entirely.
Change-Id: Ic3ef7b7a6a9fc7ee7fb13eb7bd7f34c9bff57448
Bug: oss-fuzz:39661
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456469
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
The fuzzer has been poking various holes in DSL by intentionally
creating illegal types (e.g. private or not ES2-compatible), then
finding ways to use those types, e.g. constructors or swizzles.
Previously we were mitigating those by calling `reportIllegalTypes` at
the locations where the type was used. Now, we detect the illegal type
usage at the source, and return a poison DSLType. This prevents the
illegal type from leaking out at all, and stops the problem at its
source. It also allows us to remove calls to `reportIllegalTypes`
sprinkled through the code, as those are now redundant.
Change-Id: Id50b50f72849111d80f76e4fdc2cb6094d3009bd
Bug: oss-fuzz:39597
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455999
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
These weren't used anywhere in our test suite.
Change-Id: I35e8607ad2dbddf8f403668bd2b2636a8964d304
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455777
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
`Type::isPrivate` now works properly even on structs and arrays, so we
don't need two separate methods anymore.
Change-Id: Ic3e16e1315ebb0c8cec575f109af7e472a11ac8c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455660
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is a reland of 36f53ec7e1
Original change's description:
> Disallow constructors of ES3 types in ES2 code.
>
> The fuzzer found that we constructed TypeReferences without first
> checking for disallowed tyoes. (In fact, TypeReference creation had no
> error checking at all; it didn't even have Convert/Make functions.)
>
> Added proper Convert/Make to TypeReference, and used those calls to
> report errors or cause assertions if trying to make a TypeReference to a
> type that the program did not support.
>
> (While tracking down this bug, I added strict-ES2 type assertions to our
> constructor IR nodes as well. This helped pinpoint the error and seem
> reasonable to leave in, just in case.)
>
> Change-Id: I896b68ae9d3d9e1f30d7eba9fa594617ab851c74
> Bug: oss-fuzz:39540
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455498
> Commit-Queue: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: oss-fuzz:39540
Change-Id: Id8e323c22b18726214613b6061c08873048b7c69
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455617
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This turns out to work fine, but we didn't cover it in any test case.
Change-Id: I98c40dc023bc9f0739beeb6e4163cde087a0be99
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455499
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 36f53ec7e1.
Reason for revert: breaks DS3Types test
Original change's description:
> Disallow constructors of ES3 types in ES2 code.
>
> The fuzzer found that we constructed TypeReferences without first
> checking for disallowed tyoes. (In fact, TypeReference creation had no
> error checking at all; it didn't even have Convert/Make functions.)
>
> Added proper Convert/Make to TypeReference, and used those calls to
> report errors or cause assertions if trying to make a TypeReference to a
> type that the program did not support.
>
> (While tracking down this bug, I added strict-ES2 type assertions to our
> constructor IR nodes as well. This helped pinpoint the error and seem
> reasonable to leave in, just in case.)
>
> Change-Id: I896b68ae9d3d9e1f30d7eba9fa594617ab851c74
> Bug: oss-fuzz:39540
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455498
> Commit-Queue: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: oss-fuzz:39540
Change-Id: I1dc3ccca477fcb9fe3f39cfe8af1fd54dcb18d6b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455616
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
The fuzzer found that we constructed TypeReferences without first
checking for disallowed tyoes. (In fact, TypeReference creation had no
error checking at all; it didn't even have Convert/Make functions.)
Added proper Convert/Make to TypeReference, and used those calls to
report errors or cause assertions if trying to make a TypeReference to a
type that the program did not support.
(While tracking down this bug, I added strict-ES2 type assertions to our
constructor IR nodes as well. This helped pinpoint the error and seem
reasonable to leave in, just in case.)
Change-Id: I896b68ae9d3d9e1f30d7eba9fa594617ab851c74
Bug: oss-fuzz:39540
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455498
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
All of these lines are errors but most of them are currently not
detected by our strict-ES2 checks. This is fixed in a followup CL.
Change-Id: Ifeba9aba3ce3f1bddd1c701dfc4622505e424ea7
Bug: oss-fuzz:39540
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455497
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
