Switch public/private dependencies to a non-blocking feature gate

[epage]

#13307 updates our documentation to distinguish blocking and non-blocking feature gates. Currently, public dependencies use a blocking feature gate and should be switched to a non-blocking feature gate.

When discussing this as a team, we tried to balance

• Avoiding MSRV bumps for using the feature, allowing earlier adoption
• How long this feature has until it is stabilized to make much of a difference for MSRVs

Due to some outstanding rustc bugs, the timeline for stabilization is out of our hands and so we feel moving forward with switching to non-blocking gating is worth it.

Parts of this change include

• Switching the cargo-features to a -Z
• Warning if public is used without -Z and setting it to false
  • We should also warn if the data type changes but that is less likely to happen and could possibly be skipped
• Ensuring the published version of the package does not have public

[epage]

@linyihai in case you didn't see this. If not interested at this time, thats fine.

[linyihai]

@linyihai in case you didn't see this. If not interested at this time, thats fine.

I didn't know I can make a hand. Thanks for you mention.

@rustbot claim

[linyihai]

before I deep into this issue, I had glanced the code roughly. I still have some question.

Switching the cargo-features to a -Z

Firstly, I can refer to PR #13296 to add the -Zpublic-dependency.

The question is whether I replace cargo-features with -Zpublic-depenedncy or not, that means I will

• delete the code Feature::public_dependency() and where use it.
• some test case need to delete cargo-features = ["public-dependency"] in their Cargo.toml, add -Zpublic-dependency in the command

Ensuring the published version of the package does not have public

This is a little vague to me. Do you mean check the code in cargo-publish subcommand?

#13307 updates our documentation to distinguish blocking and non-blocking feature gates.

Besides, it would be great if there were examples like this in the past.

@epage Please give me some guidance, thanks you a lot.

[linyihai]

Warning if public is used without -Z and setting it to false

I think your intention is only warning when run cargo add --public and cargo add --no-public without the -Zpublic-dependency.
if no -Zpublic-dependency, we should warning people and ingore --public and --no-public.

Or has nothing to do with cargo add

[epage]

The question is whether I replace cargo-features with -Zpublic-depenedncy or not, that means I will

Yes, delete the old feature and add the -Z.

People are using this, so maybe we should offer a transition period? Unsure.

Ensuring the published version of the package does not have public

This is a little vague to me. Do you mean check the code in cargo-publish subcommand?

Intentionally so as the way to solve it is less important. I would expect a test that shows that the published or packaged Cargo.toml does not have a public field even when the source does.

Most likely, in prepare_for_publish, you will just set public = None on dependencies.

Warning if public is used without -Z and setting it to false

This has nothing to do with cargo add (though maybe we'll switch --public from using -Zunstable-options to this new -Z). This is in read_manifest_from_str that we should check the field and, if needed, disable it and warn.

[linyihai]

Ensuring the published version of the package does not have public

I will address this by next PR.