Permit duplicate macro imports

[jswrenn]

Consider a crate that depends on both serde (without the derive feature) and serde_derive, and imports serde::Serialize (a trait) and serde_derive::Serialize (a macro). Then, imagine some other crate in a build graph depends on serde with the derive feature; they import both the macro and trait simultaneously with use serde::Serialize. If duplicate imports of the same item are always forbidden, these crates cannot co-exist in the same build-graph; the former crate will fail to build, as its first import (which will now also import the Serialize macro) conflicts with its second import.

This build hazard is confusing — the author of the second crate had no idea that their dependence on the derive feature might be problematic for other crates. The author of the first crate can mitigate the hazard by only glob-importing from proc-macro crates, but glob imports run against many's personal preference and tooling affordances (e.g., rust-analyzer's auto-import feature).

We mitigate this hazard across the ecosystem by permitting duplicate imports of macros. We don't limit this exception to proc macros, as it should not be a breaking change to rewrite a proc macro into a by-example macro. Although it would be semantically unproblematic to permit all duplicate imports (not just those of macros), other kinds of imports have not, in practice, posed the same hazard, and there might be cases we'd like to warn-by-default against. For now, we only permit duplicate macro imports.

See https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Allowing.20same-name.20imports.20of.20the.20same.20item/near/516777221

r? @compiler-errors

I'm lang-nominating this because I'm not sure if this carve-out rises to the point of requiring an RFC and for the below open questions.

Open Questions

Permitting All Duplicate Identifiers

So long as two bindings resolve to the same item, it's semantically unproblematic for them to have the same name. This PR currently takes the most conservative approach and only carves out macro imports as a case in which duplicate imports of the same item are accepted. However, the warn-by-default unusued_import lint already effectively nudges against duplicate imports. I think we could permit duplicate imports of the the same item — for all kinds of items — without issue.

[oxalica]

Can we have some tests about how does this incorporate with unused_imports? Eg. for use serde::Serialize; use serde_derive::Serialize;, will it warn on #[derive(Serialize)]? Does the use order matter? What about only using the trait fn f(_: &impl Serialize);?
The latter case, only the first use is unambiguously referenced so it should warn as expected. In the former case, the second use is technically unnecessary but there is a reason to keep it.

[jswrenn]

Not sure how this got closed...

I've updated tests/ui/proc-macro/duplicate.rs to also test for the interaction with unused_imports. I'd forgotten about that lint, and it might resolve my concerns about allowing all duplicate imports (i.e., not just macro) of the same item. I'll add an 'Open Questions' section to the PR text and leave the question to t-lang.

[traviscross]

However, the warn-by-default unusued_import lint already effectively nudges against duplicate imports. I think we could permit duplicate imports of the the same item — for all kinds of items — without issue.

I agree. And working to specify our language has me in the mood to prefer being consistent where possible rather than adding little carve-outs here and there. So I propose that we allow duplicate imports of the same item for all namespaces.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.