Simplify checking feature syntax

[Eh2406]

What does this PR try to resolve?

Similar to #14089, in my PubGrub work I had to try to understand the build_feature_map code that determines if the name refers to a feature or an optional dependency. There were a couple of little things I wanted to clean up while I was staring at the code. Specifically:

• there was a lot of vertical space taken up with arguments to bail that could be in line at the format string.
• some match statements were used where a named helper method would be clearer.
• split_once could replace a find ... split_at dance.
• in dep_map we were constructing a full Vec<Dependency>, when we only cared about whether there was any dependency and whether any of the dependencies were optional.

How should we test and review this PR?

It's an internal re-factor, and the tests still pass.

Additional information

If you're having questions about this code while you're reviewing, this would be a perfect opportunity for better naming and comments. Please ask questions.

@epage: After this PR I am likely to copy this code into my pubgrub tester. Are there other users who might be interested in looking at a cargo.toml or an index entry and determining what feature names are available and what dependencies they enable? If so maybe this function should be moved to one of the new stable-ish reusable libraries.

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ehuss]

Looks good, just some bikeshedding on the name.

[ehuss]

I think this might be a confusing name, since FeatureValue::Feature is not necessarily a dependency name. For example:

[features]
foo = ["bar"]
bar = []

Here the FeatureValue::Feature("bar") is not a dependency name.

I realize this is refactoring code that was already using dep_name, but the original was somewhat abusing the nomenclature.

I would go with feature_or_dep_name to make it clearer it can be either. What do you think?

[ehuss]

Here name seems ambiguous to me. It could be a "feature name" or a "dependency name". I might go with something like explicit_dep_name or something like that.

Also, can you add a docstring to say exactly what it does?

[epage]

cargo add and `cargo-information do their own feature activation work.

[Eh2406]

@ehuss tweak names as requested.

@epage are you saying that other projects would or would not find making this method public useful?

[epage]

I've not checked the function logic to see if it would work (mostly out for the next couple weeks) so I was just noting potential applications, one being in Cargo.

[ehuss]

Thanks!

@bors r+

[bors]

📌 Commit 85f6d2d has been approved by ehuss

It is now in the queue for this repository.

[bors]

⌛ Testing commit 85f6d2d with merge fb05646...

[bors]

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing fb05646 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing fb05646 to master...

[bors]

👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request.