Skip to content
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

Merged
merged 162 commits into from
Nov 15, 2024
Merged

Conversation

Sway007
Copy link
Member

@Sway007 Sway007 commented Oct 17, 2024

Please check if the PR fulfills these requirements

  • The commit message follows our guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

related editor issue galacean/editor#2877

  1. ShaderLab compiler ignore Editor module like below
Shader "Unlit" {
 ...
  Editor {
            Properties {
              /**
               * @language zh
               * 主颜色
              */

              /**
              * @language en
              * Main Color
              */
              material_BaseColor("Main Color", Color) = (0, 0, 0, 1);
              material_AlphaCutoff("Alpha Cutoff", Range(0, 1, 0.01)) = 0;
              material_BaseTexture("Texture", Texture2D);
            }

            Macros {
              Header("Conditional Macors") {
                MATERIAL_HAS_BASETEXTURE("Base Texture");
                MATERIAL_IS_ALPHA_CUTOFF("Alpha Cutoff");
              }
            }

            UIScript "${params.uiScriptPath}";
          }
 ...
}
  1. Fix RenderQueueType variable assignment bug in ShaderLab
// renderQueueType is a variable evaluea
RenderQueueType = renderQueueType;
  1. Remove duplicate code skip process.

Editor block code skip process is performed in ShaderContentParser and PpParser

Summary by CodeRabbit

Release Notes

  • New Features

    • Introduced the GS_Editor keyword to enhance shader processing capabilities.
    • Added new mappings for the Editor keyword in the keyword mapping system.
  • Bug Fixes

    • Improved error handling during shader parsing, ensuring robust logging and management of parsing errors.
    • Updated error reporting mechanisms to enhance clarity and consistency across various components.
  • Tests

    • Expanded test suite with additional shader validation tests to ensure accuracy in shader processing and error handling.
    • Adjusted expectations for error handling in the release version of shader parsing.
  • Documentation

    • Updated method signatures to reflect changes in error handling return types for better clarity.

Copy link

@coderabbitai coderabbitai bot left a 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 of this in static context

Using this in a static context can be confusing. Consider using the class name PpParser 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 improvements

The change correctly implements the Editor module skipping. Consider these minor improvements:

  1. Use includes() instead of indexOf() !== -1 for better readability
  2. 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

📥 Commits

Reviewing files that changed from the base of the PR and between 5badefe and fa6b2de.

📒 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)

Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between fa6b2de and 671df03.

📒 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

Comment on lines 582 to 589
return promise.then((item) => {
let resource = item;
if (key) {
const paths = this._parseQueryPath(key);
resource = this._getResolveResource(item, paths);
}
return isClone ? resource.clone() : resource;
});
Copy link

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:

  1. Invalid keys that result in undefined resources
  2. 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.

Suggested change
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type error

Copy link

@coderabbitai coderabbitai bot left a 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 casts

The explicit as GSError casts appear unnecessary since ShaderLabUtils.createGSError should already return a GSError 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 consistency

Both 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: Replace this with class name in static context

Using this in static methods can be confusing. Consider replacing this._errors.push() with ShaderContentParser._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

📥 Commits

Reviewing files that changed from the base of the PR and between caa9c01 and 1027705.

📒 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:

  1. Using Error as the return type to match both verbose and non-verbose modes
  2. 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 the errors array for debugging
  • In release mode, errors are thrown immediately, ensuring they're not silently ignored
  • ShaderLabUtils.createGSError() handles both modes appropriately by returning either GSError or standard Error
🏁 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: ⚠️ Potential issue

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:

  1. Documentation of the new behavior
  2. Verification that downstream code can handle invalid/variable render queue types
  3. 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:

  1. The engine has a well-defined enum RenderQueueType with three values: Opaque, AlphaTest, and Transparent
  2. The render pipeline (BasicRenderPipeline.ts) properly handles all three queue types with dedicated queues and processing
  3. The RenderState class has a default fallback to RenderQueueType.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

Comment on lines +123 to +125
this.sematicAnalyzer.errors.push(<GSError>error);
// #endif
return null;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

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

Copy link

@coderabbitai coderabbitai bot left a 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, using this 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

📥 Commits

Reviewing files that changed from the base of the PR and between e57f2aa and 0c8d1d6.

📒 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)

Comment on lines 655 to 661
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: "" });
Copy link

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.

Suggested change
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)

Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 0c8d1d6 and 9de0104.

📒 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:

  1. Error handling for malformed blocks
  2. Test coverage
  3. 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)

Copy link

@coderabbitai coderabbitai bot left a 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:

  1. Updating documentation to reflect the new Editor block handling behavior
  2. Adding comprehensive test cases covering various Editor block scenarios
  3. 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

📥 Commits

Reviewing files that changed from the base of the PR and between 9de0104 and eeb1188.

📒 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:

  1. EditorProperties and EditorMacros blocks are now handled by the standard parsing flow in ShaderContentParser.ts through the EKeyword enum cases
  2. Test shaders (demo.shader, waterfull.shader, template.shader) contain Editor blocks that are properly structured and parsed
  3. The parser treats Editor blocks like other global statements by using _addGlobalStatement and scanPairedText 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

Comment on lines +108 to +110
// #if _VERBOSE
this._errors.push(error);
// #endif
Copy link

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.

  1. Replace this with the class name to improve clarity in static context.
  2. 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.

Suggested change
// #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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high priority High priority issue shader Shader related functions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants