2021-01-11 20:42:44 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2020 Google LLC
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef SKSL_DSL_VAR
|
|
|
|
#define SKSL_DSL_VAR
|
|
|
|
|
2021-03-04 19:30:25 +00:00
|
|
|
#include "include/sksl/DSLExpression.h"
|
|
|
|
#include "include/sksl/DSLModifiers.h"
|
2021-03-25 21:49:08 +00:00
|
|
|
#include "include/sksl/DSLType.h"
|
2021-01-11 20:42:44 +00:00
|
|
|
|
|
|
|
namespace SkSL {
|
|
|
|
|
2021-09-09 18:31:31 +00:00
|
|
|
class Expression;
|
2021-05-18 14:12:58 +00:00
|
|
|
class IRGenerator;
|
2021-07-07 13:41:17 +00:00
|
|
|
class SPIRVCodeGenerator;
|
2021-01-11 20:42:44 +00:00
|
|
|
class Variable;
|
2021-03-25 21:49:08 +00:00
|
|
|
enum class VariableStorage : int8_t;
|
2021-01-11 20:42:44 +00:00
|
|
|
|
|
|
|
namespace dsl {
|
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
class DSLVarBase {
|
2021-01-11 20:42:44 +00:00
|
|
|
public:
|
2021-04-26 13:35:10 +00:00
|
|
|
/**
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
* Creates an empty, unpopulated var. Can be replaced with a real var later via `swap`.
|
2021-04-26 13:35:10 +00:00
|
|
|
*/
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
DSLVarBase() : fType(kVoid_Type), fDeclared(true) {}
|
2021-04-26 13:35:10 +00:00
|
|
|
|
2021-01-11 20:42:44 +00:00
|
|
|
/**
|
|
|
|
* Constructs a new variable with the specified type and name. The name is used (in mangled
|
|
|
|
* form) in the resulting shader code; it is not otherwise important. Since mangling prevents
|
|
|
|
* name conflicts and the variable's name is only important when debugging shaders, the name
|
|
|
|
* parameter is optional.
|
|
|
|
*/
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLVarBase(DSLType type, skstd::string_view name, DSLExpression initialValue, PositionInfo pos);
|
2021-06-23 17:51:55 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLVarBase(DSLType type, DSLExpression initialValue, PositionInfo pos);
|
2021-01-11 20:42:44 +00:00
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLVarBase(const DSLModifiers& modifiers, DSLType type, skstd::string_view name,
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue, PositionInfo pos);
|
2021-03-05 19:23:48 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLVarBase(const DSLModifiers& modifiers, DSLType type, DSLExpression initialValue,
|
|
|
|
PositionInfo pos);
|
2021-03-05 19:23:48 +00:00
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
DSLVarBase(DSLVarBase&&) = default;
|
2021-06-23 17:51:55 +00:00
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
virtual ~DSLVarBase();
|
2021-03-04 19:30:25 +00:00
|
|
|
|
2021-06-23 17:51:55 +00:00
|
|
|
skstd::string_view name() const {
|
2021-04-16 18:54:43 +00:00
|
|
|
return fName;
|
|
|
|
}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
const DSLModifiers& modifiers() const {
|
2021-06-23 14:27:09 +00:00
|
|
|
return fModifiers;
|
|
|
|
}
|
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
virtual VariableStorage storage() const = 0;
|
2021-04-26 13:35:10 +00:00
|
|
|
|
2021-01-26 19:31:29 +00:00
|
|
|
DSLExpression x() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).x();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression y() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).y();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression z() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).z();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression w() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).w();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression r() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).r();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression g() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).g();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression b() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).b();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression a() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).a();
|
2021-01-26 19:31:29 +00:00
|
|
|
}
|
|
|
|
|
2021-06-23 17:51:55 +00:00
|
|
|
DSLExpression field(skstd::string_view name) {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo()).field(name);
|
2021-02-11 20:18:31 +00:00
|
|
|
}
|
|
|
|
|
2021-02-26 01:50:32 +00:00
|
|
|
DSLPossibleExpression operator[](DSLExpression&& index);
|
2021-01-26 15:07:01 +00:00
|
|
|
|
2021-02-26 01:50:32 +00:00
|
|
|
DSLPossibleExpression operator++() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return ++DSLExpression(*this, PositionInfo());
|
2021-01-13 15:38:59 +00:00
|
|
|
}
|
|
|
|
|
2021-02-26 01:50:32 +00:00
|
|
|
DSLPossibleExpression operator++(int) {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo())++;
|
2021-01-13 15:38:59 +00:00
|
|
|
}
|
|
|
|
|
2021-02-26 01:50:32 +00:00
|
|
|
DSLPossibleExpression operator--() {
|
2021-09-27 14:39:18 +00:00
|
|
|
return --DSLExpression(*this, PositionInfo());
|
2021-02-26 01:50:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DSLPossibleExpression operator--(int) {
|
2021-09-27 14:39:18 +00:00
|
|
|
return DSLExpression(*this, PositionInfo())--;
|
2021-02-26 01:50:32 +00:00
|
|
|
}
|
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
protected:
|
|
|
|
DSLPossibleExpression assign(DSLExpression other);
|
|
|
|
|
|
|
|
void swap(DSLVarBase& other);
|
2021-01-11 20:42:44 +00:00
|
|
|
|
2021-03-25 21:49:08 +00:00
|
|
|
DSLModifiers fModifiers;
|
|
|
|
// We only need to keep track of the type here so that we can create the SkSL::Variable. For
|
|
|
|
// predefined variables this field is unnecessary, so we don't bother tracking it and just set
|
|
|
|
// it to kVoid; in other words, you shouldn't generally be relying on this field to be correct.
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
// If you need to determine the variable's type, look at DSLWriter::Var(...)->type() instead.
|
2021-03-25 21:49:08 +00:00
|
|
|
DSLType fType;
|
2021-04-26 13:35:10 +00:00
|
|
|
int fUniformHandle = -1;
|
2021-01-22 20:18:25 +00:00
|
|
|
std::unique_ptr<SkSL::Statement> fDeclaration;
|
2021-03-25 21:49:08 +00:00
|
|
|
const SkSL::Variable* fVar = nullptr;
|
2021-06-23 17:51:55 +00:00
|
|
|
skstd::string_view fRawName; // for error reporting
|
|
|
|
skstd::string_view fName;
|
2021-03-25 21:49:08 +00:00
|
|
|
DSLExpression fInitialValue;
|
2021-08-29 18:31:19 +00:00
|
|
|
// true if we have attempted to create the SkSL var
|
|
|
|
bool fInitialized = false;
|
2021-03-25 21:49:08 +00:00
|
|
|
bool fDeclared = false;
|
2021-08-31 11:40:24 +00:00
|
|
|
PositionInfo fPosition;
|
2021-01-11 20:42:44 +00:00
|
|
|
|
2021-01-22 20:18:25 +00:00
|
|
|
friend class DSLCore;
|
2021-01-11 20:42:44 +00:00
|
|
|
friend class DSLExpression;
|
2021-03-16 20:37:29 +00:00
|
|
|
friend class DSLFunction;
|
2021-01-13 15:38:59 +00:00
|
|
|
friend class DSLWriter;
|
2021-05-18 14:12:58 +00:00
|
|
|
friend class ::SkSL::IRGenerator;
|
2021-07-07 13:41:17 +00:00
|
|
|
friend class ::SkSL::SPIRVCodeGenerator;
|
2021-01-11 20:42:44 +00:00
|
|
|
};
|
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
/**
|
|
|
|
* A local variable.
|
|
|
|
*/
|
|
|
|
class DSLVar : public DSLVarBase {
|
|
|
|
public:
|
|
|
|
DSLVar() = default;
|
|
|
|
|
|
|
|
DSLVar(DSLType type, skstd::string_view name = "var",
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue = DSLExpression(),
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(type, name, std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLVar(DSLType type, const char* name, DSLExpression initialValue = DSLExpression(),
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: DSLVar(type, skstd::string_view(name), std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLVar(DSLType type, DSLExpression initialValue, PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(type, std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLVar(const DSLModifiers& modifiers, DSLType type, skstd::string_view name = "var",
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue = DSLExpression(), PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(modifiers, type, name, std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLVar(const DSLModifiers& modifiers, DSLType type, const char* name,
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue = DSLExpression(), PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: DSLVar(modifiers, type, skstd::string_view(name), std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
|
|
|
DSLVar(DSLVar&&) = default;
|
|
|
|
|
|
|
|
VariableStorage storage() const override;
|
|
|
|
|
|
|
|
void swap(DSLVar& other);
|
|
|
|
|
|
|
|
DSLPossibleExpression operator=(DSLExpression expr);
|
|
|
|
|
|
|
|
DSLPossibleExpression operator=(DSLVar& param) {
|
|
|
|
return this->operator=(DSLExpression(param));
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class Param>
|
|
|
|
DSLPossibleExpression operator=(Param& param) {
|
|
|
|
return this->operator=(DSLExpression(param));
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
using INHERITED = DSLVarBase;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A global variable.
|
|
|
|
*/
|
|
|
|
class DSLGlobalVar : public DSLVarBase {
|
|
|
|
public:
|
|
|
|
DSLGlobalVar() = default;
|
|
|
|
|
|
|
|
DSLGlobalVar(DSLType type, skstd::string_view name = "var",
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue = DSLExpression(), PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(type, name, std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLGlobalVar(DSLType type, const char* name, DSLExpression initialValue = DSLExpression(),
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: DSLGlobalVar(type, skstd::string_view(name), std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLGlobalVar(DSLType type, DSLExpression initialValue,
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(type, std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLGlobalVar(const DSLModifiers& modifiers, DSLType type, skstd::string_view name = "var",
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue = DSLExpression(), PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(modifiers, type, name, std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLGlobalVar(const DSLModifiers& modifiers, DSLType type, const char* name,
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLExpression initialValue = DSLExpression(), PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: DSLGlobalVar(modifiers, type, skstd::string_view(name), std::move(initialValue), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
|
|
|
DSLGlobalVar(const char* name);
|
|
|
|
|
|
|
|
DSLGlobalVar(DSLGlobalVar&&) = default;
|
|
|
|
|
|
|
|
VariableStorage storage() const override;
|
|
|
|
|
|
|
|
void swap(DSLGlobalVar& other);
|
|
|
|
|
|
|
|
DSLPossibleExpression operator=(DSLExpression expr);
|
|
|
|
|
|
|
|
DSLPossibleExpression operator=(DSLGlobalVar& param) {
|
|
|
|
return this->operator=(DSLExpression(param));
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class Param>
|
|
|
|
DSLPossibleExpression operator=(Param& param) {
|
|
|
|
return this->operator=(DSLExpression(param));
|
|
|
|
}
|
|
|
|
|
2021-09-09 18:31:31 +00:00
|
|
|
/**
|
|
|
|
* Implements the following method calls:
|
|
|
|
* half4 shader::eval(float2 coords);
|
|
|
|
* half4 colorFilter::eval(half4 input);
|
|
|
|
*/
|
2021-10-04 19:35:59 +00:00
|
|
|
DSLExpression eval(DSLExpression x, PositionInfo pos = PositionInfo::Capture());
|
2021-09-09 18:31:31 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Implements the following method call:
|
|
|
|
* half4 blender::eval(half4 src, half4 dst);
|
|
|
|
*/
|
2021-10-04 19:35:59 +00:00
|
|
|
DSLExpression eval(DSLExpression x, DSLExpression y,
|
|
|
|
PositionInfo pos = PositionInfo::Capture());
|
2021-09-09 18:31:31 +00:00
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
private:
|
2021-10-04 19:35:59 +00:00
|
|
|
DSLExpression eval(ExpressionArray args, PositionInfo pos);
|
|
|
|
|
2021-09-09 18:31:31 +00:00
|
|
|
std::unique_ptr<SkSL::Expression> methodCall(skstd::string_view methodName, PositionInfo pos);
|
|
|
|
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
using INHERITED = DSLVarBase;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A function parameter.
|
|
|
|
*/
|
|
|
|
class DSLParameter : public DSLVarBase {
|
|
|
|
public:
|
|
|
|
DSLParameter() = default;
|
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLParameter(DSLType type, skstd::string_view name = "var",
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(type, name, DSLExpression(), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLParameter(DSLType type, const char* name, PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: DSLParameter(type, skstd::string_view(name), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLParameter(const DSLModifiers& modifiers, DSLType type, skstd::string_view name = "var",
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: INHERITED(modifiers, type, name, DSLExpression(), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
2021-08-31 11:40:24 +00:00
|
|
|
DSLParameter(const DSLModifiers& modifiers, DSLType type, const char* name,
|
|
|
|
PositionInfo pos = PositionInfo::Capture())
|
|
|
|
: DSLParameter(modifiers, type, skstd::string_view(name), pos) {}
|
Broke DSLVar into separate subclasses
Previously, DSLVar represented local, global, and parameter variables.
This splits it into three separate subclasses.
In addition to just being a cleaner API in general, this also addresses
an issue we ran into with the upcoming DSLParser: previously, a global
DSLVar's storage was not set correctly until DeclareGlobal was called,
so an AddToSymbolTable call prior to DeclareGlobal would create the
SkSL variable with the wrong storage, causing spurious errors on
global-only modifiers. But holding off on the AddToSymbolTable tends to
break constructs like "int x = 0, y = x", so improving the API seemed
like the best way to address it.
Now that we have greater type safety around variables, we can
potentially avoid having to call AddToSymbolTable for DSLVar and
DSLGlobalVar altogether, since we know they are both supposed to end up
in the symbol table, but that isn't something I want to change in this
CL.
Change-Id: I5f390a7384ce0af6a2131d84f97fc5e5b318063f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/428576
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
2021-07-15 14:35:54 +00:00
|
|
|
|
|
|
|
DSLParameter(DSLParameter&&) = default;
|
|
|
|
|
|
|
|
VariableStorage storage() const override;
|
|
|
|
|
|
|
|
void swap(DSLParameter& other);
|
|
|
|
|
|
|
|
DSLPossibleExpression operator=(DSLExpression expr);
|
|
|
|
|
|
|
|
DSLPossibleExpression operator=(DSLParameter& param) {
|
|
|
|
return this->operator=(DSLExpression(param));
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class Param>
|
|
|
|
DSLPossibleExpression operator=(Param& param) {
|
|
|
|
return this->operator=(DSLExpression(param));
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
using INHERITED = DSLVarBase;
|
|
|
|
};
|
|
|
|
|
2021-01-11 20:42:44 +00:00
|
|
|
} // namespace dsl
|
|
|
|
|
|
|
|
} // namespace SkSL
|
|
|
|
|
|
|
|
|
|
|
|
#endif
|