You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow supplied Clippy symbol source when building the driver without network access #2131
dylint_driver's build script obtains Clippy's symbol list by discovering a revision from RUSTUP_TOOLCHAIN, acquiring the rust-clippy repository, and reading clippy_utils/src/sym.rs.
This prevents a build without network access from using an already supplied, matching Clippy source tree. cargo --offline does not control the build script's Git acquisition.
The driver still needs the exact symbol list, in the same order as the Clippy version used by the lint libraries. Omitting the symbols or using a fixed Clippy dependency would not be a general fix.
Could the build script accept an explicit path to the matching clippy_utils/src/sym.rs? For example, a DYLINT_CLIPPY_SYM_RS build-time environment variable could select a caller-supplied source file and reuse the existing symbol parser. If unset, the current toolchain lookup would remain the default. Cargo should track both the variable and the selected file, and a missing or malformed explicit input should fail without falling back to network acquisition.
This is separate from #2105: clearing inherited Git variables fixes the Git-hook failure, but does not provide a build input that avoids the repository acquisition itself.
Could the build script accept an explicit path to the matching clippy_utils/src/sym.rs? For example, a DYLINT_CLIPPY_SYM_RS build-time environment variable could select a caller-supplied source file and reuse the existing symbol parser.
For your use case, is it necessary that just clippy_utils/src/sym.rs be what exists offline? Could it instead be the whole repo?
There are at least two reasons I would prefer the latter approach:
clippy_repository is called from a few locations besides driver/build/extra_symbols.rs. Being able to specify a path to the whole repo would help those other locations.
clippy_utils/src/sym.rs by itself does not contain version information. So it would be easy to build a driver with the wrong version of clippy_utils/src/sym.rs.
The only downside I can see is that it could be harder to move a whole repo to a separate network (i.e., moving just a text file could be easier). Does this apply to your use case?
If you are agreeable to the whole-repo approach, would you mind updating #2132? Maybe call the environment variable DYLINT_CLIPPY_REPO?
6. @EricLiu2000 For the purpose of reviewing #2132, is the following an issue you are also facing, not just lack of network access?
> A custom compiler toolchain name also cannot identify the matching Clippy revision through the dated-nightly lookup.
sorry, that was unnecessary to mention. this is not an issue and the PR does not change this behavior. we should keep this focused on the clippy repo support as a minimal change, I'll update the description.
Activity
smoelius commentedon Oct 15, 2026
For your use case, is it necessary that just
clippy_utils/src/sym.rsbe what exists offline? Could it instead be the whole repo?There are at least two reasons I would prefer the latter approach:
clippy_repositoryis called from a few locations besidesdriver/build/extra_symbols.rs. Being able to specify a path to the whole repo would help those other locations.clippy_utils/src/sym.rsby itself does not contain version information. So it would be easy to build a driver with the wrong version ofclippy_utils/src/sym.rs.The only downside I can see is that it could be harder to move a whole repo to a separate network (i.e., moving just a text file could be easier). Does this apply to your use case?
If you are agreeable to the whole-repo approach, would you mind updating #2132? Maybe call the environment variable
DYLINT_CLIPPY_REPO?EricLiu2000 commentedon Oct 16, 2026
Thanks for the quick response! I've revised the PR to use the whole-repo approach as you suggested, instead of just
sym.rs.smoelius commentedon Oct 16, 2026
Thanks, @EricLiu2000. I will try to review this over the weekend.
smoelius commentedon Oct 24, 2026
@EricLiu2000 For the purpose of reviewing #2132, is the following an issue you are also facing, not just lack of network access?
EricLiu2000 commentedon Oct 25, 2026
sorry, that was unnecessary to mention. this is not an issue and the PR does not change this behavior. we should keep this focused on the clippy repo support as a minimal change, I'll update the description.