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-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.
|
|
|
|
*/
|
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(DSLType type, skstd::string_view name, DSLExpression initialValue);
|
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
|
|
|
DSLVarBase(DSLType type, DSLExpression initialValue);
|
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,
|
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
|
|
|
DSLExpression initialValue);
|
2021-03-05 19:23:48 +00:00
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLVarBase(const DSLModifiers& modifiers, DSLType type, DSLExpression initialValue);
|
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() {
|
|
|
|
return DSLExpression(*this).x();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression y() {
|
|
|
|
return DSLExpression(*this).y();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression z() {
|
|
|
|
return DSLExpression(*this).z();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression w() {
|
|
|
|
return DSLExpression(*this).w();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression r() {
|
|
|
|
return DSLExpression(*this).r();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression g() {
|
|
|
|
return DSLExpression(*this).g();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression b() {
|
|
|
|
return DSLExpression(*this).b();
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLExpression a() {
|
|
|
|
return DSLExpression(*this).a();
|
|
|
|
}
|
|
|
|
|
2021-06-23 17:51:55 +00:00
|
|
|
DSLExpression field(skstd::string_view name) {
|
2021-02-11 20:18:31 +00:00
|
|
|
return DSLExpression(*this).field(name);
|
|
|
|
}
|
|
|
|
|
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-01-13 15:38:59 +00:00
|
|
|
return ++DSLExpression(*this);
|
|
|
|
}
|
|
|
|
|
2021-02-26 01:50:32 +00:00
|
|
|
DSLPossibleExpression operator++(int) {
|
2021-01-13 15:38:59 +00:00
|
|
|
return DSLExpression(*this)++;
|
|
|
|
}
|
|
|
|
|
2021-02-26 01:50:32 +00:00
|
|
|
DSLPossibleExpression operator--() {
|
|
|
|
return --DSLExpression(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
DSLPossibleExpression operator--(int) {
|
|
|
|
return DSLExpression(*this)--;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
bool fDeclared = false;
|
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",
|
|
|
|
DSLExpression initialValue = DSLExpression())
|
|
|
|
: INHERITED(type, name, std::move(initialValue)) {}
|
|
|
|
|
|
|
|
DSLVar(DSLType type, const char* name, DSLExpression initialValue = DSLExpression())
|
|
|
|
: DSLVar(type, skstd::string_view(name), std::move(initialValue)) {}
|
|
|
|
|
|
|
|
DSLVar(DSLType type, DSLExpression initialValue)
|
|
|
|
: INHERITED(type, std::move(initialValue)) {}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLVar(const DSLModifiers& modifiers, DSLType type, skstd::string_view name = "var",
|
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
|
|
|
DSLExpression initialValue = DSLExpression())
|
|
|
|
: INHERITED(modifiers, type, name, std::move(initialValue)) {}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLVar(const DSLModifiers& modifiers, DSLType type, const char* name,
|
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
|
|
|
DSLExpression initialValue = DSLExpression())
|
|
|
|
: DSLVar(modifiers, type, skstd::string_view(name), std::move(initialValue)) {}
|
|
|
|
|
|
|
|
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",
|
|
|
|
DSLExpression initialValue = DSLExpression())
|
|
|
|
: INHERITED(type, name, std::move(initialValue)) {}
|
|
|
|
|
|
|
|
DSLGlobalVar(DSLType type, const char* name, DSLExpression initialValue = DSLExpression())
|
|
|
|
: DSLGlobalVar(type, skstd::string_view(name), std::move(initialValue)) {}
|
|
|
|
|
|
|
|
DSLGlobalVar(DSLType type, DSLExpression initialValue)
|
|
|
|
: INHERITED(type, std::move(initialValue)) {}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLGlobalVar(const DSLModifiers& modifiers, DSLType type, skstd::string_view name = "var",
|
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
|
|
|
DSLExpression initialValue = DSLExpression())
|
|
|
|
: INHERITED(modifiers, type, name, std::move(initialValue)) {}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLGlobalVar(const DSLModifiers& modifiers, DSLType type, const char* name,
|
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
|
|
|
DSLExpression initialValue = DSLExpression())
|
|
|
|
: DSLGlobalVar(modifiers, type, skstd::string_view(name), std::move(initialValue)) {}
|
|
|
|
|
|
|
|
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));
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
using INHERITED = DSLVarBase;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A function parameter.
|
|
|
|
*/
|
|
|
|
class DSLParameter : public DSLVarBase {
|
|
|
|
public:
|
|
|
|
DSLParameter() = default;
|
|
|
|
|
|
|
|
DSLParameter(DSLType type, skstd::string_view name = "var")
|
|
|
|
: INHERITED(type, name, DSLExpression()) {}
|
|
|
|
|
|
|
|
DSLParameter(DSLType type, const char* name)
|
|
|
|
: DSLParameter(type, skstd::string_view(name)) {}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLParameter(const DSLModifiers& modifiers, DSLType type, skstd::string_view name = "var")
|
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
|
|
|
: INHERITED(modifiers, type, name, DSLExpression()) {}
|
|
|
|
|
2021-08-05 14:19:11 +00:00
|
|
|
DSLParameter(const DSLModifiers& modifiers, DSLType type, const char* name)
|
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(modifiers, type, skstd::string_view(name)) {}
|
|
|
|
|
|
|
|
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
|