Add Bazel-native Dylint support#116
Conversation
dzbarsky
force-pushed
the
main
branch
2 times, most recently
from
bdc44d9 to
b332517
Compare
Introduce explicit Dylint rules, nightly rustc-dev plumbing, and integration coverage for target-local custom lint configs. Co-authored-by: Codex <noreply@openai.com>
Dylint requires its checked graph, lint libraries, and driver to agree on the same nightly compiler family. Model that family explicitly so rust_dylint can select an exact generated rules_rs toolchain repo rather than any registered nightly toolchain. Keep ordinary toolchain resolution unchanged when no family is requested, and make dylint_toolchain declare the matching Bazel toolchain wrapper for users. Co-authored-by: Codex <noreply@openai.com>
| visibility = ["//visibility:public"], | ||
| ) | ||
|
|
||
| if toolchain_family_setting != None: |
There was a problem hiding this comment.
do we need family on rust-analyzer?
| ) | ||
|
|
||
| native.toolchain( | ||
| name = "{}_{}_to_{}_{}_bootstrap_selected_family".format(exec_triple.system, exec_triple.arch, target_key, version_key), |
There was a problem hiding this comment.
why do we need extra bootstrap toolchains?
| rust_analyzer_toolchain(**rust_analyzer_toolchain_kwargs) | ||
|
|
||
| target_settings = [ | ||
| "@rules_rust//rust/toolchain/channel:" + channel, |
There was a problem hiding this comment.
we already set channel:nightly, right? Can that take the place of all this family plumbing? It's not clear to me what the family is intended to do?
| def _rustc_repository_impl(rctx): | ||
| exec_triple = triple(rctx.attr.triple) | ||
| download_and_extract(rctx, "rustc", "rustc", exec_triple) | ||
| if rctx.attr.rustc_dev_sha256: |
There was a problem hiding this comment.
so one of our design goals was to make all downloads fully parallel and lazy. Perhaps rust_dev can be a separate repository and then we link it into the constructed sysroot? (But we can have a "normal" sysroot and a sysroot-with-dev and select between them based on a build flag or something). That would let crates themselves decide which sysroot they want so dylint could opt into the extra one and that would drive the download fully lazily when dylint crate is built? Does that make sense?
|
Apologies for the delay! Looking into it a bit more, I'm not sure if dylint is widely used enough that we should bless it as a first-class extension here, but perhaps putting it in |
|
Can do! Or rather, I'll try 😄. Perhaps the better play here is to split this up into any needed improvements/adjustments to rules_rs + keep the dylint rule a separate thing outside of rules_rs entirely. I'm certainly open to retaining it in an examples (or experimental?) dir too but I worry it will be a bit "big" for an example. |
Works for me! Probably easier to iterate in a single PR to make sure it works and then split it out before landing? |
3 participants
Introduce explicit Dylint rules, nightly rustc-dev plumbing, and integration coverage for target-local custom lint configs.