skia2/tests/sksl/errors/Ossfuzz32587.glsl

### Compilation failed:

error: 1: unknown identifier 'x1'
error: 2: expected 'half', but found 'float'
2 errors
Fix fuzzer-discovered error with variable declarations. As soon as a single VarDeclaration is successfully created, its Variable is added to the current symbol table. However, if a variable-declaration line declared several variables in a row, we would stop if ANY of the declarations contained an error and discard the entire statement, but would continue processing the rest of the program. This left us in a position where some Variables existed in the SymbolTable with valid, reachable names, but their corresponding VarDeclaration statement had been thrown away as erroneous. Since Variables point back to VarDeclarations for their initialValues, this gave us a stale pointer. Any future reference to that variable name which could trigger an access to its initialValue would read from this dead pointer. This CL fixes the conversion of VarDeclarations so that we no longer throw away any VarDeclarations associated with a successfully-parsed Variable. Change-Id: If8ec3c160933e48a0e1f36414234b3a849d8978c Bug: oss-fuzz:32587 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389636 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> 2021-03-29 13:38:59 +00:00			`### Compilation failed:`

			`error: 1: unknown identifier 'x1'`
Replace trio of XxxxLiteral types with a single Literal type. Throughout SkSL we've begun using doubles as a convenient way to store any SkSL value (int, float, bool) in a single type. This idea has now been extended to literals. Rather than having three expression kinds for integers, floats and boolean literals, we can have just one. These can be accessed in a type-specific way (`floatValue`, `intValue`, and `boolValue` return the expected type, or assert if it's not the matching type), or in a type-agnostic way (`value` will return a double and works on any type of Literal). This allows us to remove a complex template trick (Literal<T> is gone), removes two redundant Expression types, and and lets us reduce our code size in ConstantFolder, FunctionCall, etc. Most of the conversion process was pretty straightforward: * `IntLiteral::Make` becomes `Literal::MakeInt` * `x.is<IntLiteral>()` becomes `x.isIntLiteral()` * `x.as<IntLiteral>.value()` becomes `x.as<Literal>.intValue()` Change-Id: Ic328533611e4551669c7fc9d7f9c03e34699f3f6 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/447836 Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com> 2021-09-13 17:32:06 +00:00			`error: 2: expected 'half', but found 'float'`
Fix fuzzer-discovered error with variable declarations. As soon as a single VarDeclaration is successfully created, its Variable is added to the current symbol table. However, if a variable-declaration line declared several variables in a row, we would stop if ANY of the declarations contained an error and discard the entire statement, but would continue processing the rest of the program. This left us in a position where some Variables existed in the SymbolTable with valid, reachable names, but their corresponding VarDeclaration statement had been thrown away as erroneous. Since Variables point back to VarDeclarations for their initialValues, this gave us a stale pointer. Any future reference to that variable name which could trigger an access to its initialValue would read from this dead pointer. This CL fixes the conversion of VarDeclarations so that we no longer throw away any VarDeclarations associated with a successfully-parsed Variable. Change-Id: If8ec3c160933e48a0e1f36414234b3a849d8978c Bug: oss-fuzz:32587 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389636 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> 2021-03-29 13:38:59 +00:00			`2 errors`