Validation deps for Rust Clippy?

[Łukasz Anforowicz]

Hello @gn-dev,

In a document here, I've tried to explore what options there may be for "eagerly" invoking Rust Clippy during incremental Chromium builds.  It seems that one option may be adding GN support for ninja validation deps - a new kind of a dependency edge mentioned in a slide of @agrieve's Google-internal presentation here, and publicly documented in (a bit sparse) ninja docs here.

Are there any previous thoughts or design documents about implementing validation deps support in GN?  Should I just try implementing it (how hard can it be 😱).

Am I possibly missing any other options?

Thanks,

Lukasz

[Dirk Pranke]

I have not read the linked docs yet in any detail, and I can't access the Google-internal presentation, so I am withholding full blessing until I can do so -- or give up on the idea of getting around to it :) -- but it seems like a reasonable thing to explore. 

I don't recall any previous (public) discussions on this idea, nor any Google-internal discussions w/ me from when I was there.

(a) I would, however, largely defer to Andrew on this if he's thought about this a bunch

(b) I feel like it would be good if there was a way to bypass the validations if you wanted to do so, e.g., a `ninja --skip-validations` flag or something. I don't immediately see any such flag, nor do I remember any discussion about this on the ninja list. Do you know if there were discussions of such a thing somewhere?

-- Dirk

[Neri Marschik]

Hi there. @philwo mentioned this thread to me.
Out of curiosity I was playing around with the Ninja validations feature and GN. Siso already had support for it so I tried to get it to work. I don't have a good grasp on GN yet, but it seems to be working.
The code is here: https://gn-review.git.corp.google.com/c/gn/+/20860

Maybe this could be used to convert the clippy actions into validation checks?

Neri

[Łukasz Anforowicz]

On Thu, Jan 22, 2026 at 9:25 PM Neri Marschik <ner...@google.com> wrote:

Hi there. @philwo mentioned this thread to me.
Out of curiosity I was playing around with the Ninja validations feature and GN. Siso already had support for it so I tried to get it to work. I don't have a good grasp on GN yet, but it seems to be working.
The code is here: https://gn-review.git.corp.google.com/c/gn/+/20860

Maybe this could be used to convert the clippy actions into validation checks?

Very nice!  If this CL lands, I will definitely use it for Clippy. 

[Aaron Wood]

OOoh, this is very nice.  We (Fuchsia) would likely also use it for clippy)

How are these scheduled in Ninja (sorry, I haven't dug into the code).  Does the validation target run before the dependents of the validated target run?  Or are the validations just scheduled to run in the same build?

To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

[Tyler Mandry]

+1, this would definitely be useful in the Fuchsia build. You may be interested in seeing how we handled clippy and rustdoc targets there, along with the metadata. (Thanks to +Ethan Williams for helping me dig this up.)

https://cs.opensource.google/fuchsia/fuchsia/+/main:build/rust/rust_auxiliary.gni;l=77-118;drc=58399b469dcdaa61844f0691ca424887b9e2711f

The build targets look like this:

#     in-tree rustc_library                   third_party rust_library
#     ---------------------                   ------------------------
# <:foo> (group)                          <:foo> (alias)
# ├───<:foo.actual> (rust_library)        ╰───<:foo-v0_1_0> (rust_library)
# ╰───<:foo.aux> (group)                      ╰───<:foo.aux.deps> (group)
#     ├───<:foo.clippy>
#     ╰───<:foo.rustdoc>

The biggest downside of this setup is that it adds dependency edges where they don't need to be; dependent libraries need to wait for rustdoc and clippy to complete before they can build. I think validation deps would solve that.

[Andrew Grieve]

Yeah, not much to add here. Validations would be great! 

[Aaron Wood]

So, I'm experimenting with this in the Fuchsia build, and I'm seeing something odd with the number of clippy actions we have in the build:  it dropped by about 2/3 (from 2003 to 785) on a clean build.

Our build graph contains templates that set up the following:

group(foo_target) {
    public_deps = [ foo.actual, foo.aux]
}
rust_library(foo.actual) {...}
group(foo.aux) {
  data_deps = [ foo.clippy ]
}
action(foo.clippy) {...}

And then this was changed to be:

group(foo_target) {
    public_deps = [ foo.actual ]
    validations = [ foo.aux]
}
rust_library(foo.actual) {...}
group(foo.aux) {
  data_deps = [ foo.clippy ]
}
action(foo.clippy) {...}

I also tried

group(foo_target) {
    public_deps = [ foo.actual, foo.aux]
}
rust_library(foo.actual) {...}
group(foo.aux) {
  validations = [ foo.clippy ]
}
action(foo.clippy) {...}

And in this case, all clippy actions were dropped from the resultant build.  So it looks like there's some interactions here between the groups and the validations? (the use of data_deps I could see definitely being an issue).

[Neri Marschik]

Thanks for sharing this Aaron! It differs from the patterns I discovered in the Chrome codebase. I'll look at it today.

Unrelated to the issue, but let me answer your prior question again so it's on this thread, too.

How are these scheduled in Ninja (sorry, I haven't dug into the code).  Does the validation target run before the dependents of the validated target run?  Or are the validations just scheduled to run in the same build? 

 Both Siso and Ninja treat validations as top level targets, i.e. They don't block follow up targets of the action they are validating. They are added to the build graph even if the target that specifies the validations is up-to-date. 

[Aaron Wood]

On Thu, Jan 29, 2026 at 4:56 PM Neri Marschik <ner...@google.com> wrote:

Thanks for sharing this Aaron! It differs from the patterns I discovered in the Chrome codebase. I'll look at it today.

I _think_ this has to do with how the validations are found for a given target.  I'm not the most familiar with the ninja-writer side of things, most of my GN dev experience has been in the parser/builder and in the rust-project emitting code.  But I'm guessing that the validations have to be very close (in terms of dependency-graph distances) to the binaries, in order to be found, and that the dependency type (dep, public_dep, data, etc.) matter as well.

I'm going to spend some time today looking to see what targets are being dropped from the build (and maybe will see if I can work on a smaller portion of the graph to make the data set more manageable).

 

Unrelated to the issue, but let me answer your prior question again so it's on this thread, too.

How are these scheduled in Ninja (sorry, I haven't dug into the code).  Does the validation target run before the dependents of the validated target run?  Or are the validations just scheduled to run in the same build? 

 Both Siso and Ninja treat validations as top level targets, i.e. They don't block follow up targets of the action they are validating. They are added to the build graph even if the target that specifies the validations is up-to-date. 

Thanks, once I figured that out from the Ninja docs, it make a LOT more sense!