Skip to content

[naga] Warn, rather than error, on unreachable statements #7554

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

Closed

Conversation

andyleiserson
Copy link
Contributor

@andyleiserson andyleiserson commented Apr 16, 2025

Earlier versions of WGSL specified that unreachable code was an error, but that is no longer the case. This PR removes the error but retains a warning on unreachable statements. #7718 is an alternative that removes the associated logic entirely, not generating an error or warning.

Fixes #7536

I have added a mechanism to collect warnings during validation. Mostly to make them accessible to the tests, I add an API on Validator to retrieve the diagnostics. However, even with the warning that the diagnostics are not stable, I'm not sure if we really want this to be a public API. Another possibility is changing the tests to unit tests so they can retrieve the diagnostics without having a public API.

I also made some changes in the Span module to support boxed errors for the diagnostics. It would be better to just use Vec<ValidationError> for the diagnostics, but the difficulty with that is that creating a ValidationError from a FunctionError requires knowing the function name (not too bad) and the Handle for the function (harder), which aren't readily available at the point where the diagnostic is generated, because in error cases the conversion to a ValidationError happens as the error propagates upwards.

Testing
Added tests in the validation suite and added/updated tests in wgsl_errors.

Squash or Rebase? Squash

Checklist

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • If this contains user-facing changes, add a CHANGELOG.md entry.

@ErichDonGubler
Copy link
Member

I haven't taken a deep look at this, and I'm not sure I'll be the primary reviewer, but: We might usefully make this use Severity::report_diag, so warnings can eventually get rolled into the effort to migrate it to satisfy #6458.

@andyleiserson
Copy link
Contributor Author

I haven't taken a deep look at this, and I'm not sure I'll be the primary reviewer, but: We might usefully make this use Severity::report_diag, so warnings can eventually get rolled into the effort to migrate it to satisfy #6458.

Like this? 😀

Severity::Warning.report_diag(

(In the long term, hardcoding Severity::Warning is not great, but it seemed non-trivial to plumb a diagnostic context to this check so I didn't tackle that right now.)

@ErichDonGubler ErichDonGubler self-assigned this Apr 17, 2025
Copy link
Member

@teoxoy teoxoy left a comment

Choose a reason for hiding this comment

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

I have 2 high level questions/concerns:

  • Is there a strong reason to warn instead of allowing unreachable statements?
  • I think we need to update our uniformity analysis to accommodate the change. The spec PR updated the uniformity rules.

@ErichDonGubler ErichDonGubler removed their assignment May 21, 2025
@andyleiserson
Copy link
Contributor Author

Is there a strong reason to warn instead of allowing unreachable statements?

I made it a warning because it seems like a useful diagnostic to emit, and we already had the code, so it seemed preferable to keep rather than remove it and possibly add it back later. But I wouldn't say that's a strong reason -- there are lots of things that could be better about our diagnostics, and the only immediate need is that we stop treating it as an error.

I agree that changes to the uniformity analysis are needed -- however there are other problems with the uniformity analysis as well (#4369), and it's not actually the same code that's changed here. Maybe that's an argument that it's better to remove the diagnostic for now, and in the future generate it from the uniformity analysis implementation.

@teoxoy
Copy link
Member

teoxoy commented May 22, 2025

I made it a warning because it seems like a useful diagnostic to emit, and we already had the code, so it seemed preferable to keep rather than remove it and possibly add it back later. But I wouldn't say that's a strong reason -- there are lots of things that could be better about our diagnostics, and the only immediate need is that we stop treating it as an error.

I was mainly asking since I thought we wouldn't need to warn in general but looking at the spec it seems there are a few cases in which we must warn.

I agree that changes to the uniformity analysis are needed -- however there are other problems with the uniformity analysis as well (#4369), and it's not actually the same code that's changed here. Maybe that's an argument that it's better to remove the diagnostic for now, and in the future generate it from the uniformity analysis implementation.

I was worried that by removing this restriction it would make our existing uniformity analysis less strict but after thinking more about it I don't think it can, it can only make it more strict since the unreachable statements will participate in the analysis. I never looked at uniformity analysis in depth to confidently say that this is the case though. @jimblandy do you see any issues with lifting this restriction, in terms of how it effects our existing uniformity analysis?

@jimblandy
Copy link
Member

It would be better to just use Vec<ValidationError> for the diagnostics, but the difficulty with that is that creating a ValidationError from a FunctionError requires knowing the function name (not too bad) and the Handle for the function (harder), which aren't readily available at the point where the diagnostic is generated, because in error cases the conversion to a ValidationError happens as the error propagates upwards.

You're talking about the case where we want to generate a diagnostic, but continue processing, right? If we're doing that at all, presumably we have passed in some sort of "sink" value that is responsible for accumulating the diagnostics as we go. It seems to me that that sink should probably carry in the contextual information that the callers had.

@jimblandy
Copy link
Member

In today's maintainer's meeting, Teo helped me understand his question. Making more code visible to uniformity analysis cannot make invalid code valid, as the uniformity analysis only accumulates constraints. So this change (or something like it) should be safe from that point of view.

@teoxoy
Copy link
Member

teoxoy commented May 28, 2025

Since we went with #7718 I think we can close this one.

@teoxoy teoxoy closed this May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"Instructions after return" is reported incorrectly
4 participants