Skip to content

Consider prioritising crate search directories #2223

Closed
@brson

Description

@brson

The way crates are resolved now is by searching all known library paths for libraries with matching metadata. If there is exactly one match then it is used. If there are multiple matches then it's an error. This creates occasional situations where there are (for good reason) multiple crates in different directories with the exact same name, causing compilation to fail.

The most obvious example is when somebody installs the same crate to ./.cargo and to ~/.cargo, making it unusable. One possible scheme is to break the paths up into 'priority groups' and if there are multiple matches with the exact same metadata then the higher priority one wins. If there are muliple matches with different metadata then, even if they are different priorities, it's still an error.

Priority groups from lowest to highest:

  • sysroot target libs - where core/std, rustc, etc live
  • sysroot cargo libs - if such a thing exists
  • user cargo libs - in ~/.cargo
  • local cargo libs - in ./.cargo
  • all user provided search paths

Most of these groups consist of a single path, except for 'all user provided search paths', i.e. the -L flag. If a user explicitly says where to look for crates then there really shouldn't be dupes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linking into static, shared libraries and binariesC-enhancementCategory: An issue proposing an enhancement or a PR with one.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions