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

[naga] Add a review checklist. #6906

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions naga/REVIEW-CHECKLIST.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Naga Review Checklist

This is a collection of notes on things to watch out for when
reviewing pull requests submitted to Naga.

Unfortunately, there are a few parts of Naga where certain knowledge,
requirements, or concerns are spread out across several areas of the
code. This makes mistakes easier, as it is more likely for a
contributor to fix one spot, but neglect others.

Ideally, one fixes this kind of problem by refactoring the code so
that requirements are easier to identify with local reasoning. We do
this regularly. But when such projects are too large to undertake
immediately, we can use review checklists as a temporary workaround
to ensure that all the different spots do get addressed.
Comment on lines +10 to +15
Copy link
Member

Choose a reason for hiding this comment

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

question: This sounds like an (unwritten) backlog of specific things you had in mind. Do you have issue links for these "projects"? I think that would help a reader gauge the applicability of this paragraph as it ages.


Some of these points are also just coding style issues. Such problems
are probably better to address with comments in the code, or effective
use of Rust (exhaustive match checking, for example).

## General

If your change iterates over a collection, did you ensure the order of
iteration was deterministic? Using `HashMap` and `HashSet` is fine, as
long as you don't iterate over it.

## IR changes

If your change adds or removes `Handle`s from the IR:
Copy link
Member

Choose a reason for hiding this comment

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

style: Prettier would add a newline between this paragraph and the list following it. Might be nice for avoiding churn, but no blocking here.

Copy link
Member

Choose a reason for hiding this comment

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

This also applies to a couple of other places here.

- Did you update handle validation in `valid::handles`?
- Did you update the compactor in `compact`?
- Did you update `back::pipeline_constants::adjust_expr`?

If your change adds a new operation:
- Did you update the typifier in `proc::typifier`?
- Did you update the validator in `valid::expression`?
- If the operation can be used in constant expressions, did you
update the constant evaluator in `proc::constant_evaluator`?

## Backend changes

- If your change introduces any new identifiers, how did you ensure
they won't conflict with the users' identifiers? (This is usually
not relevant to the SPIR-V backend.)
- Did you use the `Namer` generate a fresh identifier?
- Did you register the identifier as a reserved word with the the `Namer`?
- Did you use a reserved prefix registered with the `Namer`?

## WGSL Extensions

If you added a new feature to WGSL that is not covered by of the WebGPU specification:

- Did you add a `Capability` flag for it?
- Did you document the feature fully in that flag's doc comment?
- Did you ensure the validator rejects programs that use the feature?
Comment on lines +21 to +55
Copy link
Member

Choose a reason for hiding this comment

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

question: I'm concerned about this staying up-to-date, because both contributors and reviewers need to mind this content manually. How will this be achieved?

Loading