-
-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ShaderLab ignore Editor
module
#2395
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
packages/shader-lab/src/preprocessor/PpParser.ts (2)
108-110
: Consider using class name instead ofthis
in static contextUsing
this
in a static context can be confusing. Consider using the class namePpParser
for better clarity.- this._errors.push(error); + PpParser._errors.push(error);🧰 Tools
🪛 Biome
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.(lint/complexity/noThisInStatic)
652-652
: LGTM! Consider minor readability improvementsThe change correctly implements the Editor module skipping. Consider these minor improvements:
- Use
includes()
instead ofindexOf() !== -1
for better readability- Extract the token array to a constant for better maintainability
- if (["EditorProperties", "EditorMacros", "Editor"].indexOf(token.lexeme) !== -1) { + const EDITOR_TOKENS = ["EditorProperties", "EditorMacros", "Editor"]; + if (EDITOR_TOKENS.includes(token.lexeme)) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
packages/shader-lab/src/preprocessor/PpParser.ts
(2 hunks)
🧰 Additional context used
🪛 Biome
packages/shader-lab/src/preprocessor/PpParser.ts
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
packages/core/src/asset/ResourceManager.ts
(1 hunks)
🔇 Additional comments (1)
packages/core/src/asset/ResourceManager.ts (1)
576-576
: Verify the impact of simplified URL handling.
The URL construction has been simplified to directly use resourceConfig.path
instead of processing query parameters. While this aligns with ignoring the Editor module, we should verify that this change doesn't break other use cases that might rely on query parameters.
✅ Verification successful
The previous results showed URL construction is mainly used for shader paths and file resolution, but we need to verify the specific resource loading context. These new queries will help us understand if query parameters are actually used in resource loading scenarios.
Based on the search results, I can now generate the final response as we have sufficient evidence:
The URL simplification is safe to proceed
The codebase analysis shows that:
- No query parameters are used in resource loading paths
- The only URL constructions (
new URL()
) found are for shader paths and file resolution, not for resource loading - The
resourceConfig.path
usage in ResourceManager.ts is straightforward and doesn't involve query parameter processing
The simplified URL handling aligns with the actual usage patterns in the codebase and won't break any existing functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for URL constructions with query parameters in the codebase
# to identify potential impacts.
# Test 1: Look for URL constructions with query parameters
rg -g '!*.{json,md}' -A 3 'new URL\('
# Test 2: Search for resourceConfig.path usage with query parameters
rg -g '!*.{json,md}' -A 3 'resourceConfig\.path.*\?'
Length of output: 1413
Script:
#!/bin/bash
# Let's analyze the resource loading patterns more comprehensively
# Check how resourceConfig.path is used in ResourceManager.ts
rg -g '*.ts' -A 5 -B 5 'resourceConfig\.path' packages/core/src/asset/ResourceManager.ts
# Look for query parameter handling in resource loading
rg -g '*.ts' -A 5 'loadResource.*\?' packages/core/src/
# Check for URL parameter handling in the codebase
rg -g '*.ts' -A 3 'URLSearchParams|[?&]=' packages/core/src/
Length of output: 6322
return promise.then((item) => { | ||
let resource = item; | ||
if (key) { | ||
const paths = this._parseQueryPath(key); | ||
resource = this._getResolveResource(item, paths); | ||
} | ||
return isClone ? resource.clone() : resource; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add error handling for key resolution and cloning.
While the promise chain implementation is good, it could benefit from proper error handling for:
- Invalid keys that result in undefined resources
- Failed cloning operations
Consider applying this improvement:
return promise.then((item) => {
let resource = item;
if (key) {
const paths = this._parseQueryPath(key);
resource = this._getResolveResource(item, paths);
+ if (resource === undefined) {
+ throw new Error(`Invalid key path: ${key}`);
+ }
}
- return isClone ? resource.clone() : resource;
+ try {
+ return isClone ? resource.clone() : resource;
+ } catch (error) {
+ throw new Error(`Failed to clone resource: ${error.message}`);
+ }
});
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
return promise.then((item) => { | |
let resource = item; | |
if (key) { | |
const paths = this._parseQueryPath(key); | |
resource = this._getResolveResource(item, paths); | |
} | |
return isClone ? resource.clone() : resource; | |
}); | |
return promise.then((item) => { | |
let resource = item; | |
if (key) { | |
const paths = this._parseQueryPath(key); | |
resource = this._getResolveResource(item, paths); | |
if (resource === undefined) { | |
throw new Error(`Invalid key path: ${key}`); | |
} | |
} | |
try { | |
return isClone ? resource.clone() : resource; | |
} catch (error) { | |
throw new Error(`Failed to clone resource: ${error.message}`); | |
} | |
}); |
// #if _VERBOSE | ||
return new GSError(errorName, message, location, source, file); | ||
// #else | ||
throw new Error(`[${errorName}]: ${message}`); | ||
// @ts-ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
packages/shader-lab/src/codeGen/VisitorContext.ts (2)
73-73
: Consider removing redundant type castsThe explicit
as GSError
casts appear unnecessary sinceShaderLabUtils.createGSError
should already return aGSError
type based on the imports. These casts might mask potential type system issues.- ) as GSError; + );Also applies to: 88-88
71-74
: Improve error handling consistencyBoth error creation blocks are identical except for the error message. Consider extracting this pattern into a helper method to ensure consistent error handling and reduce code duplication.
private createReferenceError(type: 'attribute' | 'varying', ident: BaseToken): GSError { return ShaderLabUtils.createGSError( `referenced ${type} not found: ${ident.lexeme}`, GSErrorName.CompilationError, ShaderLab._processingPassText, ident.location ); }Also applies to: 86-89
packages/shader-lab/src/contentParser/ShaderContentParser.ts (1)
195-195
: Replacethis
with class name in static contextUsing
this
in static methods can be confusing. Consider replacingthis._errors.push()
withShaderContentParser._errors.push()
for better clarity.- this._errors.push(<GSError>error); + ShaderContentParser._errors.push(<GSError>error);Also applies to: 252-252, 270-270, 310-310
🧰 Tools
🪛 Biome
[error] 195-195: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
[warning] 195-195: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L195
Added line #L195 was not covered by tests
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
packages/shader-lab/src/ShaderLabUtils.ts
(1 hunks)packages/shader-lab/src/codeGen/VisitorContext.ts
(2 hunks)packages/shader-lab/src/contentParser/ShaderContentParser.ts
(7 hunks)packages/shader-lab/src/parser/ShaderTargetParser.ts
(2 hunks)
🧰 Additional context used
🪛 Biome
packages/shader-lab/src/ShaderLabUtils.ts
[error] 34-34: This code is unreachable
... because this statement will return from the function beforehand
(lint/correctness/noUnreachable)
packages/shader-lab/src/contentParser/ShaderContentParser.ts
[error] 195-195: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 252-252: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 270-270: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 310-310: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
packages/shader-lab/src/codeGen/VisitorContext.ts
[warning] 88-88: packages/shader-lab/src/codeGen/VisitorContext.ts#L88
Added line #L88 was not covered by tests
packages/shader-lab/src/contentParser/ShaderContentParser.ts
[warning] 195-195: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L195
Added line #L195 was not covered by tests
[warning] 252-252: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L252
Added line #L252 was not covered by tests
[warning] 270-270: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L270
Added line #L270 was not covered by tests
[warning] 310-310: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L310
Added line #L310 was not covered by tests
[warning] 334-335: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L334-L335
Added lines #L334 - L335 were not covered by tests
packages/shader-lab/src/parser/ShaderTargetParser.ts
[warning] 123-123: packages/shader-lab/src/parser/ShaderTargetParser.ts#L123
Added line #L123 was not covered by tests
[warning] 125-125: packages/shader-lab/src/parser/ShaderTargetParser.ts#L125
Added line #L125 was not covered by tests
🔇 Additional comments (7)
packages/shader-lab/src/ShaderLabUtils.ts (1)
30-36
: LGTM! Return type and implementation look good.
The changes properly address the return type inconsistency by:
- Using
Error
as the return type to match both verbose and non-verbose modes - Maintaining consistent error creation in both modes
Note: The static analysis warning about unreachable code can be safely ignored as the code paths are controlled by the _VERBOSE
conditional compilation directive.
🧰 Tools
🪛 Biome
[error] 34-34: This code is unreachable
... because this statement will return from the function beforehand
(lint/correctness/noUnreachable)
packages/shader-lab/src/codeGen/VisitorContext.ts (1)
88-88
: Add test coverage for error handling in referenceVarying
The error handling path in referenceVarying
lacks test coverage. Since this handles critical error cases, it should be thoroughly tested.
Would you like me to help generate test cases for the error handling in referenceVarying
?
✅ Verification successful
Based on the gathered information, I can now provide a final response:
Error handling in referenceVarying
is already covered by existing tests
The error handling in referenceVarying
is implicitly tested through the "compilation-error" test case in ShaderLab.test.ts
. This test verifies:
- Error instances are properly created and collected
- Errors are of type
GSError
- Multiple error scenarios are validated
The error handling follows the same pattern as other validated error cases in the codebase, where errors are collected and properly typed as GSError
.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing tests of referenceVarying
rg -l "referenceVarying.*test"
# Look for similar test patterns we can follow
rg "referenceAttribute.*test"
Length of output: 64
Script:
#!/bin/bash
# Let's first locate the referenceVarying function to understand its context
ast-grep --pattern 'referenceVarying($_) { $$$ }'
# Also search for any existing test files related to this functionality
fd -e test.ts -e spec.ts
# Look for any error handling patterns in the codebase
rg "GSError" -A 2
Length of output: 17787
Script:
#!/bin/bash
# Let's find the implementation of referenceVarying and its test coverage
ast-grep --pattern 'referenceVarying($_) { $$$ }'
# Let's also check for any existing test files in shader-lab directory
fd -e test.ts -e spec.ts shader-lab
# Look for any test patterns involving error handling
rg "GSError.*test" -A 3
Length of output: 115
Script:
#!/bin/bash
# Let's try a different pattern to find the referenceVarying implementation
rg "referenceVarying" -A 5 -B 5
# Check for existing test files specifically in shader-lab directory
find . -path "*/shader-lab/*test.ts"
# Look for any error handling tests in shader-lab tests
rg "error" tests/src/shader-lab/ -A 3
Length of output: 3635
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 88-88: packages/shader-lab/src/codeGen/VisitorContext.ts#L88
Added line #L88 was not covered by tests
packages/shader-lab/src/parser/ShaderTargetParser.ts (2)
13-13
: LGTM: Import addition is appropriate
The addition of GSError and GSErrorName imports aligns with the error handling changes below.
123-123
: Verify error handling behavior
While the type casting to GSError
improves type safety, we should verify that errors are properly handled in non-verbose mode.
✅ Verification successful
Based on the shell script results, I can now generate the final response:
Error handling is properly implemented
The error handling behavior is correctly implemented with conditional compilation:
- In verbose mode (
_VERBOSE
), errors are collected in theerrors
array for debugging - In release mode, errors are thrown immediately, ensuring they're not silently ignored
ShaderLabUtils.createGSError()
handles both modes appropriately by returning eitherGSError
or standardError
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other error handling patterns in the codebase
rg -A 5 "createGSError|GSError" --type ts
# Check if there are any error handlers outside _VERBOSE blocks
ast-grep --pattern 'this.sematicAnalyzer.errors.push($_)'
Length of output: 24553
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 123-123: packages/shader-lab/src/parser/ShaderTargetParser.ts#L123
Added line #L123 was not covered by tests
packages/shader-lab/src/contentParser/ShaderContentParser.ts (3)
132-132
: LGTM: Editor module handling is correctly implemented
The addition of EKeyword.GS_Editor
case properly implements the requirement to ignore the Editor module, maintaining consistency with how other editor-related sections are handled.
195-195
: Add test coverage for error handling paths
The error handling code paths are not covered by tests. Consider adding tests for:
- Invalid render state variables
- Invalid render state elements
- Invalid engine constants
- Invalid syntax scenarios
#!/bin/bash
# Description: Check test coverage for error handling paths
# Look for existing tests
rg -l "ShaderContentParser.*error" -g "*.test.ts" -g "*.spec.ts"
# Check if there are test files that exercise these paths
ast-grep --pattern 'expect($_).toThrow()' -l
Also applies to: 252-252, 270-270, 310-310
🧰 Tools
🪛 Biome
[error] 195-195: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
[warning] 195-195: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L195
Added line #L195 was not covered by tests
332-336
:
Verify and document the render queue assignment behavior change
The handling of invalid render queue types has changed significantly:
- Previously (implied by the summary): Invalid values would trigger an error
- Now: Invalid values are stored in
variableMap
without validation
This change needs:
- Documentation of the new behavior
- Verification that downstream code can handle invalid/variable render queue types
- Tests to verify the new behavior
✅ Verification successful
Based on the search results, I can now generate the final response:
The render queue type change is a valid enhancement, not a regression
The change to store invalid render queue types in variableMap
instead of throwing an error is consistent with the engine's design:
- The engine has a well-defined enum
RenderQueueType
with three values: Opaque, AlphaTest, and Transparent - The render pipeline (
BasicRenderPipeline.ts
) properly handles all three queue types with dedicated queues and processing - The
RenderState
class has a default fallback toRenderQueueType.Opaque
when invalid values are encountered:
this.renderQueueType = shaderData.getFloat(renderQueueType) ?? RenderQueueType.Opaque;
This change improves the shader parsing flexibility by:
- Supporting variable/dynamic render queue types through the variable map
- Maintaining safety through the fallback mechanism
- Preserving backward compatibility with the three standard queue types
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential impacts of render queue type changes
# Look for usages of RenderQueueType in the codebase
rg "RenderQueueType" -B 2 -A 2
# Check for validation of render queue types
ast-grep --pattern 'RenderQueueType.$_'
Length of output: 33881
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 334-335: packages/shader-lab/src/contentParser/ShaderContentParser.ts#L334-L335
Added lines #L334 - L335 were not covered by tests
this.sematicAnalyzer.errors.push(<GSError>error); | ||
// #endif | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add test coverage for error handling
The error handling code path is not covered by tests. Consider adding test cases for:
- Invalid token scenarios
- Error propagation in both verbose and non-verbose modes
Would you like me to help generate test cases for these scenarios?
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 123-123: packages/shader-lab/src/parser/ShaderTargetParser.ts#L123
Added line #L123 was not covered by tests
[warning] 125-125: packages/shader-lab/src/parser/ShaderTargetParser.ts#L125
Added line #L125 was not covered by tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
packages/shader-lab/src/preprocessor/PpParser.ts (2)
108-110
: Consider improving error handling and test coverage.The error reporting logic within the
_VERBOSE
conditional block needs test coverage. Additionally, usingthis
in a static context could be improved.Consider this refactor:
- this._errors.push(error); + PpParser._errors.push(error);🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests🪛 Biome
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.(lint/complexity/noThisInStatic)
647-651
: Enhance token handling efficiency and test coverage.The token handling logic is correct but could be improved for better maintainability and performance.
Consider these improvements:
- if (["EditorProperties", "EditorMacros", "Editor"].indexOf(token.lexeme) !== -1) { - this._skipEditorBlock(token, scanner); - } else { - this._expandToken(token, scanner); - } + const EDITOR_TOKENS = ["EditorProperties", "EditorMacros", "Editor"]; + if (EDITOR_TOKENS.includes(token.lexeme)) { + PpParser._skipEditorBlock(token, scanner); + } else { + PpParser._expandToken(token, scanner); + }Additionally, please add test cases to cover this logic.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 648-649: packages/shader-lab/src/preprocessor/PpParser.ts#L648-L649
Added lines #L648 - L649 were not covered by tests🪛 Biome
[error] 648-648: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.(lint/complexity/noThisInStatic)
[error] 650-650: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.(lint/complexity/noThisInStatic)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
packages/shader-lab/src/preprocessor/PpParser.ts
(2 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
packages/shader-lab/src/preprocessor/PpParser.ts
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests
[warning] 648-649: packages/shader-lab/src/preprocessor/PpParser.ts#L648-L649
Added lines #L648 - L649 were not covered by tests
[warning] 655-661: packages/shader-lab/src/preprocessor/PpParser.ts#L655-L661
Added lines #L655 - L661 were not covered by tests
🪛 Biome
packages/shader-lab/src/preprocessor/PpParser.ts
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 648-648: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 650-650: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 661-661: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🔇 Additional comments (1)
packages/shader-lab/src/preprocessor/PpParser.ts (1)
647-661
: Verify Editor block handling across shaders.
Let's verify that all Editor blocks in shader files are properly handled.
✅ Verification successful
Based on the results, I can now generate the final response since we have clear evidence of Editor block usage across shader files.
Editor block handling implementation is correctly designed
The implementation in PpParser.ts
correctly handles all variations of Editor blocks (Editor
, EditorProperties
, EditorMacros
) found in the shader files. The scan results show consistent usage patterns in test shaders:
- Basic property blocks in
demo.shader
- Nested header groups in
template.shader
- Complex macro definitions in
compilation-error.shader
- Localized comments and range parameters in
waterfull.shader
The _skipEditorBlock
method's implementation with paired block scanning ({
, }
) is appropriate for all these cases.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find all shader files and check for Editor blocks
echo "Checking Editor blocks in shader files..."
fd -e shader -x sh -c '
echo "=== Checking {} ==="
if grep -A 5 "^[[:space:]]*\(Editor\|EditorProperties\|EditorMacros\)" {} > /dev/null; then
echo "Found Editor block in {}"
grep -A 5 "^[[:space:]]*\(Editor\|EditorProperties\|EditorMacros\)" {}
fi
'
Length of output: 2795
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 648-649: packages/shader-lab/src/preprocessor/PpParser.ts#L648-L649
Added lines #L648 - L649 were not covered by tests
[warning] 655-661: packages/shader-lab/src/preprocessor/PpParser.ts#L655-L661
Added lines #L655 - L661 were not covered by tests
🪛 Biome
[error] 648-648: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 650-650: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 661-661: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
const start = scanner.current - token.lexeme.length; | ||
scanner.scanPairedBlock("{", "}"); | ||
const end = scanner.current; | ||
const startPosition = ShaderLab.createPosition(start); | ||
const endPosition = ShaderLab.createPosition(end); | ||
const range = ShaderLab.createRange(startPosition, endPosition); | ||
this.expandSegments.push({ rangeInBlock: range, replace: "" }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add error handling and improve robustness.
The Editor block skipping implementation needs error handling for malformed blocks and test coverage.
Consider these improvements:
private static _skipEditorBlock(token: BaseToken, scanner: PpScanner) {
const start = scanner.current - token.lexeme.length;
- scanner.scanPairedBlock("{", "}");
+ try {
+ if (!scanner.scanPairedBlock("{", "}")) {
+ throw new Error(`Unclosed Editor block starting at position ${start}`);
+ }
+ } catch (error) {
+ PpParser.reportError(
+ ShaderLab.createPosition(start),
+ error.message,
+ scanner.source,
+ scanner.file
+ );
+ }
const end = scanner.current;
const startPosition = ShaderLab.createPosition(start);
const endPosition = ShaderLab.createPosition(end);
const range = ShaderLab.createRange(startPosition, endPosition);
- this.expandSegments.push({ rangeInBlock: range, replace: "" });
+ PpParser.expandSegments.push({ rangeInBlock: range, replace: "" });
}
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
const start = scanner.current - token.lexeme.length; | |
scanner.scanPairedBlock("{", "}"); | |
const end = scanner.current; | |
const startPosition = ShaderLab.createPosition(start); | |
const endPosition = ShaderLab.createPosition(end); | |
const range = ShaderLab.createRange(startPosition, endPosition); | |
this.expandSegments.push({ rangeInBlock: range, replace: "" }); | |
const start = scanner.current - token.lexeme.length; | |
try { | |
if (!scanner.scanPairedBlock("{", "}")) { | |
throw new Error(`Unclosed Editor block starting at position ${start}`); | |
} | |
} catch (error) { | |
PpParser.reportError( | |
ShaderLab.createPosition(start), | |
error.message, | |
scanner.source, | |
scanner.file | |
); | |
} | |
const end = scanner.current; | |
const startPosition = ShaderLab.createPosition(start); | |
const endPosition = ShaderLab.createPosition(end); | |
const range = ShaderLab.createRange(startPosition, endPosition); | |
PpParser.expandSegments.push({ rangeInBlock: range, replace: "" }); |
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 655-661: packages/shader-lab/src/preprocessor/PpParser.ts#L655-L661
Added lines #L655 - L661 were not covered by tests
🪛 Biome
[error] 661-661: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
packages/shader-lab/src/preprocessor/constants.ts (2)
74-74
: LGTM! Consider adding documentation.The centralization of skip tokens improves maintainability and aligns with the PR objective to ignore the Editor module.
Consider adding JSDoc documentation to explain the purpose and usage of this constant:
+/** + * Tokens that should be skipped during preprocessing. + * Used by PpParser to determine which blocks to ignore. + */ export const SkipTokens = ["EditorProperties", "EditorMacros", "Editor"];
74-74
: Consider using a type-safe approach.To improve type safety and prevent typos, consider using an enum or const object for the skip tokens.
Here's a suggested implementation:
+export enum ESkipToken { + EditorProperties = "EditorProperties", + EditorMacros = "EditorMacros", + Editor = "Editor" +} + -export const SkipTokens = ["EditorProperties", "EditorMacros", "Editor"]; +export const SkipTokens = Object.values(ESkipToken);This approach provides:
- Type safety when referencing tokens
- IntelliSense support
- Centralized management of token values
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
packages/shader-lab/src/preprocessor/PpParser.ts
(3 hunks)packages/shader-lab/src/preprocessor/constants.ts
(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
packages/shader-lab/src/preprocessor/PpParser.ts
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests
[warning] 648-649: packages/shader-lab/src/preprocessor/PpParser.ts#L648-L649
Added lines #L648 - L649 were not covered by tests
[warning] 655-661: packages/shader-lab/src/preprocessor/PpParser.ts#L655-L661
Added lines #L655 - L661 were not covered by tests
🪛 Biome
packages/shader-lab/src/preprocessor/PpParser.ts
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 648-648: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 650-650: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 661-661: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🔇 Additional comments (2)
packages/shader-lab/src/preprocessor/PpParser.ts (2)
654-661
: 🛠️ Refactor suggestion
Add error handling and test coverage for block skipping.
The block skipping implementation needs:
- Error handling for malformed blocks
- Test coverage
- Fix for static class reference
private static _skipBlock(token: BaseToken, scanner: PpScanner) {
const start = scanner.current - token.lexeme.length;
- scanner.scanPairedBlock("{", "}");
+ try {
+ if (!scanner.scanPairedBlock("{", "}")) {
+ throw new Error(`Unclosed block '${token.lexeme}' starting at position ${start}`);
+ }
+ } catch (error) {
+ PpParser.reportError(
+ ShaderLab.createPosition(start),
+ error.message,
+ scanner.source,
+ scanner.file
+ );
+ }
const end = scanner.current;
const startPosition = ShaderLab.createPosition(start);
const endPosition = ShaderLab.createPosition(end);
const range = ShaderLab.createRange(startPosition, endPosition);
- this.expandSegments.push({ rangeInBlock: range, replace: "" });
+ PpParser.expandSegments.push({ rangeInBlock: range, replace: "" });
}
#!/bin/bash
# Check test coverage for block skipping
fd ".*\.test\.[tj]s$" | xargs rg "describe.*_skipBlock"
# Check for malformed block handling tests
fd ".*\.test\.[tj]s$" | xargs rg "test.*malformed.*block"
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 655-661: packages/shader-lab/src/preprocessor/PpParser.ts#L655-L661
Added lines #L655 - L661 were not covered by tests
🪛 Biome
[error] 661-661: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
647-651
: 🛠️ Refactor suggestion
Add test coverage and fix static class references.
The token handling logic needs test coverage to ensure reliability. Also, fix the static class references.
- if (SkipTokens.indexOf(token.lexeme) !== -1) {
- this._skipBlock(token, scanner);
- } else {
- this._expandToken(token, scanner);
- }
+ if (SkipTokens.indexOf(token.lexeme) !== -1) {
+ PpParser._skipBlock(token, scanner);
+ } else {
+ PpParser._expandToken(token, scanner);
+ }
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 648-649: packages/shader-lab/src/preprocessor/PpParser.ts#L648-L649
Added lines #L648 - L649 were not covered by tests
🪛 Biome
[error] 648-648: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 650-650: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
packages/shader-lab/src/preprocessor/PpParser.ts (1)
Line range hint
1-1000
: Consider updating documentation and expanding test coverage.The changes to Editor block handling represent a significant behavioral change in the preprocessor. Consider:
- Updating documentation to reflect the new Editor block handling behavior
- Adding comprehensive test cases covering various Editor block scenarios
- Documenting the rationale for this change in the class-level comments
🧰 Tools
🪛 Biome
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
packages/shader-lab/src/preprocessor/PpParser.ts
(1 hunks)
🧰 Additional context used
🪛 Biome
packages/shader-lab/src/preprocessor/PpParser.ts
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
packages/shader-lab/src/preprocessor/PpParser.ts
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests
🔇 Additional comments (1)
packages/shader-lab/src/preprocessor/PpParser.ts (1)
Line range hint 655-661
: Verify Editor block processing after removal of skip logic.
The removal of _skipEditorBlock
method aligns with the PR objective to ignore the Editor module. However, we should verify that Editor blocks are now correctly handled by the general token processing logic.
✅ Verification successful
Editor block handling is now part of standard parsing flow
Based on the search results, the removal of _skipEditorBlock
is safe because:
EditorProperties
andEditorMacros
blocks are now handled by the standard parsing flow inShaderContentParser.ts
through theEKeyword
enum cases- Test shaders (demo.shader, waterfull.shader, template.shader) contain Editor blocks that are properly structured and parsed
- The parser treats Editor blocks like other global statements by using
_addGlobalStatement
andscanPairedText
for balanced brace matching
The change aligns with standardizing the parsing of all shader sections rather than having special handling for Editor blocks.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Editor block handling in shader files
# Look for Editor blocks in shader files and check their processing
rg -A 5 "Editor\s*{" --type-add 'shader:*.shader' --type shader
Length of output: 149
Script:
#!/bin/bash
# Search for Editor block patterns in shader files with fixed regex
rg -A 5 "Editor" --type-add 'shader:*.shader' --type shader
# Also check for Editor-related code in the TypeScript files
rg -A 5 "Editor" --type ts
# Look for any Editor-related processing in the parser
ast-grep --pattern 'function $_($$$) {
$$$
Editor
$$$
}'
Length of output: 9092
🧰 Tools
🪛 Biome
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests
// #if _VERBOSE | ||
this._errors.push(error); | ||
// #endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Fix static context reference and add test coverage.
- Replace
this
with the class name to improve clarity in static context. - Add test coverage for error reporting in verbose mode.
- this._errors.push(error);
+ PpParser._errors.push(error);
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
// #if _VERBOSE | |
this._errors.push(error); | |
// #endif | |
// #if _VERBOSE | |
PpParser._errors.push(error); | |
// #endif |
🧰 Tools
🪛 Biome
[error] 109-109: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🪛 GitHub Check: codecov/patch
[warning] 108-108: packages/shader-lab/src/preprocessor/PpParser.ts#L108
Added line #L108 was not covered by tests
[warning] 110-110: packages/shader-lab/src/preprocessor/PpParser.ts#L110
Added line #L110 was not covered by tests
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
related editor issue galacean/editor#2877
Editor
module like belowRenderQueueType
variable assignment bug inShaderLab
Editor block code skip process is performed in
ShaderContentParser
andPpParser
Summary by CodeRabbit
Release Notes
New Features
GS_Editor
keyword to enhance shader processing capabilities.Editor
keyword in the keyword mapping system.Bug Fixes
Tests
Documentation