Use the same feature name validation rule from Cargo

[Rustin170506]

Split from #7379

• This PR allowed . in the feature name. I added some unit tests and integration tests for it.
• This PR also updated the feature name validation rules from Cargo.

The summary:

category	Cargo	crates.io before change	crates.io after change
Normal feature name	1. can only start with most letters, _, or 0 to 9 2. can only contain numbers, +, -, _, ., or most letters	can only contain numbers, +, -, _, or most letters	1. can only start with most letters, _, or 0 to 9 2. can only contain numbers, +, -, _, ., or most letters

[Rustin170506]

🔢 Self-check

[Rustin170506]

🔢 Self-check again

[Rustin170506]

This PR is ready for review.
Could you please take a look? Thanks! 💚 💙 💜 💛 ❤️

[Turbo87]

unfortunately this PR still mixes the refactoring of the error messages with the change of the validation rules. reviewing commit-by-commit does not help because 2765157 does both at the same time too. this makes it significantly harder to see which change belongs to the error message refactoring and which change belongs to the validation rules change.

[Rustin170506]

unfortunately this PR still mixes the refactoring of the error messages with the change of the validation rules.

I have to change the error because now we support the Unicode character in the feature name. I don't see any benefits to keeping that unclear error message.

commit-by-commit does not help because 2765157 does both at the same time too. this makes it significantly harder to see which change belongs to the error message refactoring and which change belongs to the validation rules change.

It's just two functions with about 50 line changes. And I just copied it from the Cargo repo. I think it's a waste of time, so I'm closing my PR.

[Turbo87]

I have to change the error because now we support the Unicode character in the feature name. I don't see any benefits to keeping that unclear error message.

I'm not saying "don't do it". I'm just saying do one after the other. If adding support for the unicode character requires us to refactor our error handling then refactor the error handling first, commit that, and then implement the behavior change on top. This makes it significantly easier to review and less likely to introduce unintentional bugs.

[Rustin170506]

I'm not saying "don't do it". I'm just saying do one after the other. If adding support for the unicode character requires us to refactor our error handling then refactor the error handling first, commit that, and then implement the behavior change on top. This makes it significantly easier to review and less likely to introduce unintentional bugs.

I can get your point. If this is a new feature or a really big change to the rules. I think it makes sense. But you asking me to split 30 lines of code which I copied from Cargo into two commits. I don't think it makes sense. It is wasting our time.

I have spent a bunch of time making sure I can help the reviewing process. And I keep receiving negative feedback from my pull request. You just keep asking to change every line code in your approach. Nobody can 100% follow your code style to write code. It's just 30 lines of code. And I didn't break any tests and also added a lot of tests to check it. so I am so frustrated to move forward with this PR. So I decided to close it.

[Rustin170506]

Thank you for taking the time to review it.

[Rustin170506]

Let me try it agian:(

[Rustin170506]

@Turbo87 2ae50e5 This commit is only for the validation rules changes. I hope this helps.

[bors]

☔ The latest upstream changes (presumably #7206) made this pull request unmergeable. Please resolve the merge conflicts.

[Turbo87]

Rebased to fix the lockfile merge conflict. I have a couple more suggestions on how to improve the code, but those can be added afterwards as well.