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

Underscores in names of the targets and crates #3085

Closed
matklad opened this issue Sep 12, 2016 · 4 comments
Closed

Underscores in names of the targets and crates #3085

matklad opened this issue Sep 12, 2016 · 4 comments
Labels
A-cli Area: Command-line interface, option parsing, etc. C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-run S-propose-close Status: A team member has nominated this for closing, pending further input from the team

Comments

@matklad
Copy link
Member

matklad commented Sep 12, 2016

Currently crate names are normalized by turning all the - into _. This however does not happen with target names and you can get

cargo run --example tutorial_02

error: no example target named `tutorial_02`

Did you mean `tutorial-02`?

Is this the intended, or should we treat tutorial_02 and tutorial-02 as the same target? I think that either behavior is OK, but I want this to be an explicit decision and not a random artifact of the current implementation.

Downstream issue: intellij-rust/intellij-rust#664

@alexcrichton
Copy link
Member

This is currently intended, but I don't think that there's any real reason Cargo should make this distinction. I'd be fine relaxing Cargo's parsing and just interpreting these two as the same name!

@cyplo
Copy link

cyplo commented Apr 14, 2017

Would that be a good candidate for help-wanted ?

@carols10cents carols10cents added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-run labels Sep 26, 2017
@ehuss ehuss added the A-cli Area: Command-line interface, option parsing, etc. label Apr 27, 2020
@epage
Copy link
Contributor

epage commented Oct 11, 2023

Making target names - / _ insensitive would be a breaking change because you can have targets differ by those. Its a minor case, so maybe we'd be fine breaking it. We could also say "change separators when no ambiguity".

However, do people run into this interactively (the downstream issue for this was about a bug in an IDE doing this for users)? Without this being an end-user usability problem, working through these questions does not seem worth it to me. I'm going to propose to the cargo team that we close this.

@epage epage added the S-propose-close Status: A team member has nominated this for closing, pending further input from the team label Oct 11, 2023
@weihanglo
Copy link
Member

Given that is a breaking change as aforementioned, I second closing this. If there is any issue of it, don't hesitate and talk to us. Thank you.

@weihanglo weihanglo closed this as not planned Won't fix, can't repro, duplicate, stale Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: Command-line interface, option parsing, etc. C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-run S-propose-close Status: A team member has nominated this for closing, pending further input from the team
Projects
None yet
Development

No branches or pull requests

7 participants