Skip to content

Allow supplied Clippy symbol source when building the driver without network access #2131

Open

Description

@EricLiu2000

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.

Activity

  1. smoelius commented on Oct 15, 2026

    @smoelius
    Collaborator

    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?

  2. EricLiu2000 commented on Oct 16, 2026

    @EricLiu2000
    Author

    Thanks for the quick response! I've revised the PR to use the whole-repo approach as you suggested, instead of just sym.rs.

  3. smoelius commented on Oct 16, 2026

    @smoelius
    Collaborator

    Thanks, @EricLiu2000. I will try to review this over the weekend.

  4. smoelius commented on Oct 24, 2026

    @smoelius
    Collaborator

    @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.

  5. EricLiu2000 commented on Oct 25, 2026

    @EricLiu2000
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions