Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo: fix inconsistent dashes in lib.name #12640

Closed
wants to merge 1 commit into from

Commits on Sep 7, 2023

  1. cargo: allow dashes in lib.name

    Change the cargo TOML parser to allow dashes in `lib.name`.
    
    Cargo currently refuses explicit library names if they contain a dash.
    However, if no library name is specified, the package-name will be used,
    which itself can contain dashes. This leads to packages with `lib.name`
    containing dashes, if their package-name contains dashes.
    
    Drop this requirement and allow explicit `lib.name` configurations to
    contain dashes.
    
    The current ecosystem clearly allows `lib.name` to contain dashes,
    given that `cargo metadata` already reports such names for any package
    with a dash. It looks like an oversight that any explicit configuration
    is not allowed to include dashes.
    
    All consumers of `lib.name` already use `Target.crate_name()` rather
    than `Target.name()` if a sanitized name is required. Therefore, they
    already replace dashes with underscores.
    
    Last but not least, the current documentation is simply wrong in stating
    that `lib.name` defaults to the package-name with dashes replaced by
    underscores. Cargo never replaces dashes for `lib.name`, and `cargo
    metadata` and friends already happily show `lib.name` with dashes. Cargo
    merely replaces dashes with underscores to retrieve the crate-name of a
    target, which is then used as stem for library artifacts.
    dvdhrm committed Sep 7, 2023
    Configuration menu
    Copy the full SHA
    27dda17 View commit details
    Browse the repository at this point in the history