cargo: fix inconsistent dashes in lib.name

[dvdhrm]

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.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[dvdhrm]

(update: dropped the test that verifies build-failure for lib.name with explicit dashes (but not implicit ones))

[0xPoe]

Related to #2775

[epage]

@dvdhrm how did you discover the discrepancy?

We discussed this in the cargo team meeting and didn't really see how this discrepancy would affect people and want to better understand the use cases where people are noticing this so we can better evaluate the compatibility aspect to this (we were leaning towards making the code match the docs).

ps As this is a weightier PR, affecting policy and/or compatibility, we recommend starting something like this off as an Issue and not moving forward until it is "needs mentor" (little help) or "accepted" (mentor available). If nothing else, (1) we are much more likely to look for discussions like this among the issues and (2) its not uncommon for there to be multiple PRs for one "topic" and focusing on the issue keeps the discussion in one place, making it easier to follow.

[dvdhrm]

@dvdhrm how did you discover the discrepancy?

We discussed this in the cargo team meeting and didn't really see how this discrepancy would affect people and want to better understand the use cases where people are noticing this so we can better evaluate the compatibility aspect to this (we were leaning towards making the code match the docs).

I am trying to deduce the artifacts a crate produces from its metadata. I was looking at cargo help metadata and trying to understand what packages[].targets[].name actually contains. And then figure out how to deduce the artifact name from it.

We currently take the value, underscorify it, and then use it as stem for the library artifact. I don't think this would break if you decide to do that in cargo, since the 'underscorify' can be safely applied multiple times.

[epage]

If cargo metadata is the only way this is exposed and to make it work with anything else, you have to do a conversion that will still work if we pre-apply it, it seems like we could change this behavior and make cargo match the docs.

[epage]

Closing in favor of #12783