How to do metadata-only typecheck build of a rust_library?

[dtolnay]

It looks like rules_rust unconditionally passes --emit=dep-info,link. This means Bazel builds cannot benefit from the biggest rustc speedup since 1.0.0 (https://blog.rust-lang.org/2017/03/16/Rust-1.16.html#whats-in-1160-stable). 😿

rules_rust/rust/private/rustc.bzl

Line 374 in e64700d

args.add("--emit=dep-info,link")

Is there any idiomatic way to perform non-code-generating builds which type-check only? Equivalent to Cargo's cargo check or cargo rustc --profile=check, rustc's rustc --emit=metadata, or Buck's #check flavored builds (buck build :lib#check; https://buck.build/concept/flavors.html#analysis_http).

[mfarrugi]

We could change the code to react to a flag, eg. ` --compilation_mode` ( https://github.com/bazelbuild/rules_rust/blob/e64700dc9b8b3869bce4f77b78c33cb9d088cc4b/rust/private/rustc.bzl#L370-L374) or turn `rust_library` into a macro that creates a 'check' target in addition to the build target. I am not sure whether either approach is 'idiomatic'. Going a little farther with the latter, rust_library could be changed to only run check until an output artifact is actually needed by a test or binary, but this probably requires redundant calls to rustc and more bazel know-how than I've got :).

…

On Mon, Oct 12, 2020 at 1:25 AM David Tolnay ***@***.***> wrote: It looks like rules_rust unconditionally passes --emit=dep-info,link. This means Bazel builds cannot benefit from the biggest rustc speedup since 1.0.0 ( https://blog.rust-lang.org/2017/03/16/Rust-1.16.html#whats-in-1160-stable). 😿 https://github.com/bazelbuild/rules_rust/blob/e64700dc9b8b3869bce4f77b78c33cb9d088cc4b/rust/private/rustc.bzl#L374 Is there any idiomatic way to perform non-code-generating builds which type-check only? Equivalent to Cargo's cargo check or cargo rustc --profile=check, rustc's rustc --emit=metadata, or Buck's #check flavored builds (buck build :lib#check; https://buck.build/concept/flavors.html#analysis_http). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#428>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6A3QJJJUPR56PXFTALSKKHLHANCNFSM4SMKEBCQ> .

[dtolnay]

or turn rust_library into a macro that creates a 'check' target in addition to the build target.

This sounds bad if it means ... builds will build those both. Would there be a way to not do that? I'd expect a way to run a whole ... build in the "check" compilation mode or the non-check mode.

[mfarrugi]

I don't think a `build ...` would work because any binaries wouldn't have the necessary artifacts produced, same for `test ...`

…

On Mon, Oct 12, 2020 at 1:59 PM David Tolnay ***@***.***> wrote: or turn rust_library into a macro that creates a 'check' target in addition to the build target. This sounds bad if it means ... builds will build those both. Would there be a way to not do that? I'd expect a way run a whole ... build in the "check" compilation mode or the non-check mode. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#428 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6DBTRHRM5ZMGQU2HZTSKM7XXANCNFSM4SMKEBCQ> .

[mfarrugi]

The check targets could be tagged manual to be excluded under ..., but that doesn't let you `check ...`

…

On Mon, Oct 12, 2020 at 2:12 PM Marco Farrugia ***@***.***> wrote: I don't think a `build ...` would work because any binaries wouldn't have the necessary artifacts produced, same for `test ...` On Mon, Oct 12, 2020 at 1:59 PM David Tolnay ***@***.***> wrote: > or turn rust_library into a macro that creates a 'check' target in > addition to the build target. > > This sounds bad if it means ... builds will build those both. Would > there be a way to not do that? I'd expect a way run a whole ... build in > the "check" compilation mode or the non-check mode. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#428 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAROG6DBTRHRM5ZMGQU2HZTSKM7XXANCNFSM4SMKEBCQ> > . >

[dtolnay]

For comparison, the behavior of Buck is that buck build ... will do codegen of any rust_library that is pulled in transitively by any binary included in the build, and do check-only build of any rust_library that is included in the ... but not pulled in by any binary. That seems like the best behavior. How sure are we that there would be no way to reproduce that in Bazel, or that we wouldn't want to?

[mfarrugi]

It sounds doable, but I don't know how off the cuff. What is the use-case for having libraries with no dependents?

…

On Mon, Oct 12, 2020 at 3:38 PM David Tolnay ***@***.***> wrote: For comparison, the behavior of Buck is that buck build ... will do codegen of any rust_library that is pulled in transitively by any binary include in the build, and do check-only build of any rust_library that is included in the ... but *not* pulled in by any binary. That seems like the best behavior. How sure are we that there would be no way to reproduce that in Bazel, or that we wouldn't want to? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#428 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6BEL3EMBIIHRXJXU3TSKNLKXANCNFSM4SMKEBCQ> .

[dtolnay]

What is the use-case for having libraries with no dependents?

Well if I have a library in lib/ which is used by a binary in bin/, and I am iterating on the library today, then bazel build lib/... shouldn't be needing to do LLVM codegen and linking.

This is why cargo check has been so important. It's not that people are making libraries that are never to be used by anything. It's that sometimes people work on the library itself.

[mfarrugi]

Oh sure, but I meant for the ... case. In that scenario, it seems like it would work to have a separate check target.

…

On Mon, Oct 12, 2020 at 8:44 PM David Tolnay ***@***.***> wrote: Well if I have a library in lib/ which is used by a binary in bin/, and I am iterating on the library today, then bazel build lib/... shouldn't be needing to do LLVM codegen and linking. This is why cargo check has been so important. It's not that people are making libraries that are never to be used by anything. It's that sometimes people work on the library itself. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#428 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6A6BP2R5TLK6CP2HCLSKOPH5ANCNFSM4SMKEBCQ> .

[mfarrugi]

I think in the abstract it makes perfect sense for check to be the default action and a link to only happen when a binary/test requires it. I believe it's possible to do, but I'm not sure how lazily actions are evaluated -- can you comment on that @damienmg?

…

On Mon, Oct 12, 2020 at 8:53 PM Marco Farrugia ***@***.***> wrote: Oh sure, but I meant for the ... case. In that scenario, it seems like it would work to have a separate check target. On Mon, Oct 12, 2020 at 8:44 PM David Tolnay ***@***.***> wrote: > Well if I have a library in lib/ which is used by a binary in bin/, and > I am iterating on the library today, then bazel build lib/... shouldn't > be needing to do LLVM codegen and linking. > > This is why cargo check has been so important. It's not that people are > making libraries that are never to be used by anything. It's that sometimes > people work on the library itself. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#428 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAROG6A6BP2R5TLK6CP2HCLSKOPH5ANCNFSM4SMKEBCQ> > . >

[dtolnay]

Oh sure, but I meant for the ... case. In that scenario, it seems like it would work to have a separate check target.

For the ... case, I'll share one use case from https://github.com/dtolnay/cxx -- in that repo we have two ways to plug cxx's C++ code generator into a build depending on your build system: one based on a CLI command which would be called e.g. from genrule/run_binary in Buck/Bazel, and one based on a library which would be called from a Cargo build script. I develop locally mainly with Bazel and when doing bazel build ... locally or in CI I want the whole repo typechecked including my library (which I maintain a Bazel target for but is called only from Cargo-only build.rs).