Clarify warning for using features or default-features in patch

[joshtriplett]

When attempting to substitute a local version of a dependency, since the
patch section uses syntax similar to a dependency (and the
documentation even says "The syntax is similar to the [dependencies]
section", it's natural to assume that other things from [dependencies]
also work, such as features or default-features. Attempting to use
them produces this warning:

patch for crate-name-here uses the features mechanism.
default-features and features will not take effect because the patch dependency does not support this mechanism

The phrasing "the patch dependency does not support this mechanism"
makes it seem at first glance like patch just doesn't support this at
all. But the actual problem is that the user needs to move the
features/default-features keys to an entry in dependencies
instead.

Modify the message, to make this more obvious.

Modify the corresponding warning for replace as well.

Update tests accordingly.

---

Discovered while trying to help @benwis debug an issue.

[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

[epage]

I think a key piece of information is still missing: that the features will be ignored (if I understand correctly).

What do you think of:

Suggested change

	"patch for `{}` attempts to declare features. \
	The `features` and `default-features` keys need to appear in a `dependencies` entry, not the `patch` entry.",
	"ignoring features in patch for `{}`. \
	Patch-specific `features` and `default-features` are unsupported; instead set these in the `dependencies` entry.",

[epage]

imo I think I'd also do this as:

shell().warn("ignoring features in patch for `{}`");
shell().note("patch-specific `features` and `default-features` are unsupported; instead set these in the `dependencies` entry");

[joshtriplett]

@epage I'd like to put the recommendation first, if possible. What about:

Suggested change

	"patch for `{}` attempts to declare features. \
	The `features` and `default-features` keys need to appear in a `dependencies` entry, not the `patch` entry.",
	"patch for `{}` attempts to declare features. \
	The `features` and `default-features` keys need to appear in a `dependencies` entry; they will be ignored in a `patch` entry.",

[epage]

That feels odd to me as this is a warning and should lead with what the warning is about. I see that being like rustc saying

error: consider introducing a named lifetime parameter

note: missing lifetime specifier

I do want to change my suggestion though after thinking more about why these are ignored:

shell().warn("unused fields in patch for `{}`: {}");
shell().note("configure {} in the `dependencies` entry");

[joshtriplett]

The warning that this leads with is patch for `{}` attempts to declare features.

But 👍 for the warn+note version you just gave:

shell().warn("unused fields in patch for `{}`: {}");
shell().note("configure {} in the `dependencies` entry");

[bors]

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

[ehuss]

@joshtriplett Sorry for the delay. It looks like you maybe wanted to change it to the warn()/note() suggested above? Is that something you can do?

[joshtriplett]

@ehuss Yes, though I expect it'll be a little while before I get to updating it. Anyone who wants to take this one over should feel free to do so.