Skip to content

Add checks for the validation error spans in wgsl_errors #8153

@andyleiserson

Description

@andyleiserson

The wgsl_errors test suite verifies that we detect and report various errors in WGSL source correctly. Some of the tests are checking parse errors. This is done with the check() function, which takes WGSL source and an expected output snapshot, and compares that the output matches the snapshot. Since the snapshot is a rendered version of the error message, checking the snapshot verifies not only what error was raised, but also that the source span associated with the error remains the same.

Other tests are checking for validation errors. These tests use the macros check_validation!, check_one_validation!, or check_extension_validation!. These functions test that the provided WGSL source parses into IR successfully, that module validation raises an error, and that the raised error matches a pattern supplied in the macro arguments. (In the case of check_extension_validation!, it does this, and also checks for a parse error in the case that a necessary enable directive is missing from the source.)

The check_validation! macro delegates to check_one_validation!. The implementations of check_one_validation! and check_extension_validation! immediately call .into_inner() on the WithSpan<ValidationError> returned by module validation. Thus, they verify that the expected validation error is raised (which sometimes includes checking information placed in the error about where it occurred, e.g. some errors include the name of the function where the error was found), but they do not verify that the reported code span for the error is correct. Thus, the accuracy of our code span reporting for validation errors could regress and we would not notice.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: naga processingPasses over IR in the middlearea: testsImprovements or issues with our test suitearea: validationIssues related to validation, diagnostics, and error handlingkind: diagnosticsError message should be bettertype: enhancementNew feature or request

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions