Enabling features from [replace] or [patch] doesn't work

[jdm]

If I add a path replacement for an existing dependency in my Cargo.toml, then add a nonexistent feature to it (eg. "js:0.1.3" = {path = "../rust-mozjs", features = ["nonexistent_feature"]}, Cargo does not complain. This implies to me that it's also impossible to enable existing features, since I'm having trouble with that as well.

[alexcrichton]

Was the js crate at version 0.1.3? If the [replace] directive isn't used I don't believe it's checked for validity right now.

[jdm]

It was, yes.

[alexcrichton]

Ok, finally got around to investigating this.

Yes it's true that Cargo today currently ignores features and default-features directives in [replace] sections. The logic currently just hooks into whenever candidates are loaded for a dependency a [replace] section will override any candidates returned to something else. This means that the feature activation logic, which happens in a separate step, ignores the actual [replace] line itself.

This raises an interesting question to me, though. Should we try to read features or default-features of [replace]? How does that interact with features requested by the original dependency edge we're replacing? My first inclination would be that we should reject features and default-features in a [replace] section (not possible today obviously, but we can migrate with a warning). The purpose of replace to me is "replace this node in the graph" rather than "tweak all incoming edges to this node in the dependency graph". Feature activations are properties of an edge, so that's where I think we should ignore features specified in [replace].

Thoughts? @wycats?

[kellda]

Isn't this the same as #3033 ?

[jdm]

This issue is about changing the set of features in a [replace] section. The other is about enabling a feature inside of a [patch] directive that only exists in a local override.

[0xPoe]

@rustbot claim