WIP: MVP for diagnostic rules
#6148
Conversation
…config. for uniformity analysis errors
ErichDonGubler
added
area: validation
ErichDonGubler
changed the title
diagnostic directives and attributesdiagnostic rules
| while lexer.skip(Token::Separator('.')) { | ||
| let (segment, _span) = lexer.next_ident_with_span()?; | ||
| segments.push(segment); | ||
| } |
There was a problem hiding this comment.
There are, at most, two segments here (called "diagnostic name tokens" upstream, maybe rename?), per spec.:
The name of a triggering rule is either:
a diagnostic_name_token, or
two diagnostic_name_token tokens, separated by a period
'.'(U+002E).
There was a problem hiding this comment.
In WGSL, the idea is:
- If you see a single-component diagnostic rule name, it's an error if the name isn't recognized.
- If you see a double-component diagnostic rule name, it's ignored if the name isn't recognized. This lets you write
clippy.my_picky_lintand have browsers ignore it.
So ultimately joining them into a String might not be what we want. But there's no need to fix that at this stage.
| @@ -2433,4 +2454,43 @@ impl Parser { | |||
| } | |||
| Ok(brace_nesting_level + 1) | |||
| } | |||
|
|
|||
| fn diagnostic_control<'a>(&self, lexer: &mut Lexer<'a>) -> Result<(), Error<'a>> { | |||
| // TODO(maybe): self.push_rule_span(Rule::???, lexer) | |||
There was a problem hiding this comment.
@gfx-rs/naga: It's unclear to me when to use Rule spans. Should they be used for this new functionality? 🤔
There was a problem hiding this comment.
I have always been very unsure what sorts of bugs the WGSL front end's Rule stack makes it easy to detect or fix. In a recursive descent parser, the parser's own Rust call stack indicates what we were in the midst of parsing, and the Rule stack is either identical to that, or misleading.
It does seem like the code uses push_rule_span and pop_rule_span to build spans that cover non-trivial subtrees. But you can do that just as well by calling Lexer::span_from yourself; that's something you see in the code as well.
My personal preference would be to just use Lexer::span_from directly. Logically, it should be easier to debug span problems when there are fewer "players" influencing how they're produced.
This is fine, but one of the reasons this issue is prioritized is that we want to be able to parse the shaders people are trying to run on the web. We can decide whether it's more convenient for us to address that in this PR or in follow-up PRs, but in order to deliver value to WGSL authors, the follow-up PRs may end up being just as urgent as this one. |
|
Overall, the scope and test plan in the OP looks fine to me. |
| lexer.expect(Token::Separator(','))?; | ||
| let (diagnostic_rule_name, diagnostic_rule_name_span) = lexer.capture_span(|lexer| { | ||
| // TODO: ensure that errors are good | ||
| let mut segments = Vec::new(); |
There was a problem hiding this comment.
Maybe use Vec::with_capacity(2)?
There was a problem hiding this comment.
I was actually thinking of replacing this with an ArrayVec, pending tests with stack usage. But yes, failing that, setting capacity would be good.
Speaking as the person who's linked most (all?) concrete failures against bug 1882800 in Bugzilla, the cases I've actually observed are (1) directive usage, by a wide margin, and then (2) as an attribute of a function. I don't think I've observed other application uses except for parse testing, like with the CTS. Thus, I believe making this PR focus on (1) and then following up quickly with (2) should ease most of the pressure we have on this feature. After that point, I believe we can prioritize based on blockers reported by users. |
Okay, sounds like you're way ahead of me. +1 |
Connections
Partialy resolves #5320. Offers a workaround for #3135.
Description
This change implements a meaningful first iteration of support for
diagnostic(…)directives and@diagnostic(…)attributes; to wit:diagnostic(…)rules.derivative_uniformityrule. The current analysis is incorrect, and blocks users in issues like Feature request: disable uniformity analysis on shader creation #3135. This can give them a way forward.Several things are out-of-scope:
@diagnostic(…)attributes. This PR does not attempt to handle all of these cases, to limit the complexity of this PR. These cases should not be necessary up-front to deliver value to WGSL authors. Therefore, parsing will be expanded to allow for these cases in one or more follow-up PRs.diagnostic(warn, …), therefore, will not report a compilation item, as a typical WebGPU user might expect, for warnings in this PR. Instead, we will opt forlog::warn!(…)entries. This will be fixed in a separate PR.warning-level compilation items for unrecognized diagnostic rule names. These will remain an error, for now.Testing
Current test plan:
webgpu:shader,validation,parse,diagnostic:valid_locations:*…:type="directive";___location="module"…:type="attribute";___location="function"webgpu:shader,validation,parse,diagnostic:conflicting_directive:*webgpu:shader,validation,parse,diagnostic:duplicate_attribute_same_location:*webgpu:shader,validation,parse,diagnostic:conflicting_attribute_different_location:*webgpu:shader,validation,parse,diagnostic:diagnostic_scoping:*, specific case TBD.Checklist
cargo fmt.cargo clippy. If applicable, add:--target wasm32-unknown-unknown--target wasm32-unknown-emscriptencargo xtask testto run tests.CHANGELOG.md. See simple instructions inside file.