SkSL errors now identify the specific range of code they are describing,
rather than just the line number.
Change-Id: Ifabb3148476f9b4cd8e532f23e5b38e1cf33a87e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528039
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
It's undefined behavior to cast a double to an int64 if the double is
out of range. Our SkSL error tests managed to trigger UBSAN on the tree,
pinpointing the issue (which we had already written up a bug for).
Change-Id: Ia06896732223ff310f2c175efcbeb96ba5786fa8
Bug: skia:12863
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505678
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, when attempting to cast a huge value to an int, SkSL would
report an error, then return the IR for
`ScalarCast(Int, FloatLiteral(huge-value))` . Now, to minimize the blast
radius of the error, we report the error but return `IntLiteral(0)`.
We've already reported an error, so there's no need to preserve the
value, and zero is less likely to produce follow-up errors.
(A similar approach is used here and worked well: https://osscs.corp.google.com/skia/skia/+/main:src/sksl/ir/SkSLConstructorCompoundCast.cpp;l=57-59)
Change-Id: Ie8e8d48380cb963466d1f47d123d64e3301cf87c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499563
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
SkSL is somehow interpreting a large positive value as a negative one.
Change-Id: I299e0bf389a9fcbfe697741bd33a54df07748753
Bug: skia:12863
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499556
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@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: 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>
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>
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>
Several fuzzer issues, and one Chromium issue that's blocking the roll.
Bug: chromium:1246795
Bug: skia:12423
Change-Id: I00370b74569b447e543d9a1f22c588eb493063da
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/445960
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Change-Id: Id894eb70273454716eb33c85dff2056333e90cdd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/445281
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
The fuzzer noticed insufficient guards in IndexExpression::Convert when
converting an array size from an IntLiteral to a SKSL_INT. We had code
in IRGenerator which did this properly, so I moved our array-size
conversion logic into SkSLType and had IndexExpression share it.
Also, a variety of tests around similar error conditions were added.
Change-Id: I51529dea25f9029f81ae236511610069d66be29f
Bug: oss-fuzz:37462
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441236
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
