Add #[rustc_confusables] attribute to allow targeted "no method" error suggestions on standard library types

[jieyouxu]

After this PR, the standard library developer can annotate methods on e.g. BTreeSet::push with #[rustc_confusables("insert")]. When the user mistypes btreeset.push(), BTreeSet::insert will be suggested if there are no other candidates to suggest. This PR lays the foundations for contributors to add rustc_confusables annotations to standard library types for targeted suggestions, as specified in #59450, or to address cases such as #108437.

Example

Assume BTreeSet is the standard library type:

// Standard library definition
#![feature(rustc_attrs)]

struct BTreeSet;

impl BTreeSet {
    #[rustc_confusables("push")]
    fn insert(&self) {}
}

// User code
fn main() {
    let x = BTreeSet {};
    x.push();
}

A new suggestion (which has lower precedence than suggestions for misspellings and only is shown when there are no misspellings suggestions) will be added to hint the user maybe they intended to write x.insert() instead:

error[E0599]: no method named `push` found for struct `BTreeSet` in the current scope
  --> test.rs:12:7
   |
3  | struct BTreeSet;
   | --------------- method `push` not found for this struct
...
12 |     x.push();
   |       ^^^^ method not found in `BTreeSet`
   |
help: you might have meant to use `insert`
   |
12 |     x.insert();
   |       ~~~~~~

error: aborting due to previous error

[rustbot]

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

[Noratrieb]

this may be something that could be made stable in the #[diagnostic] namespace in the future (see #111780 and the RFC). cc @weiznich you may be interseted

[est31]

The suggestion made in the thread seems relevant, to use doc(alias) instead. Since #107108 it is already used for providing the needed suggestions.

Or is it explicitly wanted that if you search for BtreeSet::push then BtreeSet::insert should not show up? That seems unfortunate to me.

[jieyouxu]

The suggestion made in the thread seems relevant, to use doc(alias) instead. Since #107108 it is already used for providing the needed suggestions.

Oops, I have no clue how I missed that... I will close this PR then.

Or is it explicitly wanted that if you search for BtreeSet::push then BtreeSet::insert should not show up? That seems unfortunate to me.

I think it's just so happens that BTreeSet::push doesn't have a #[doc(alias)] for insert, so I never noticed while working on this PR.

Sorry about this!

[est31]

@jieyouxu note that this is only my private opinion and I don't know if others agree... :) I did not want to discourage you, and it might be too early to close this PR just yet. I think it's definitely worth to discuss having an attribute separate from #[doc(alias = ...)], and it's really great that you provided an implementation, so thanks a lot for that!

I also dimly remember that either the libs (api) team or the rustdoc team expressed that they want to doc(alias) to be deployed very sparingly, but I can't find the specific thread, it was not in the tracking issue #50146 at least.

But on the other hand, adding a push alias for insert seems in-line with #91383 and #97565 which seem to still be present.

edit: the policy seems to be here.

[jieyouxu]

I think it's definitely worth to discuss having an attribute separate from #[doc(alias = ...)]

I suppose I will keep this PR open for now, then, in case having a separate attribute might be useful.

But on the other hand, adding a push alias for insert seems in-line with #91383 and #97565 which seem to still be present.

I think I will open a separate PR for adding a doc-alias for BTreeSet::push to BTreeSet::insert.

[est31]

FTR the policy can be found here and some links to more discussions can be found here.

[jieyouxu]

Actually, after grepping through library/std and library/core, I don't think something like adding an alias for BTreeSet::insert would pass the doc(alias) policy requirement since it would be something like #[doc(alias = "push")] but push is also used commonly on many other stdlib types like Vec? So maybe a separate attribute might make sense after all, which would only affect no-method-found diagnostics and not documentation.

[est31]

Fair points... I think ultimately it's up to the libs team if they want doc(alias), #[diagnostic::confusable], or neither for BTreeSet::insert. From a general point of view, it might make sense to be able to not have some suggestion automatically also be a doc alias.

[Noratrieb]

I think the problem with doc aliases is that if you have too many, it becomes quite hard to navigate the docs because you search for something and get lots of random other results showing up. In the diagnostics here you don't really have that problem as its only limited to impls on the type.

[WaffleLapkin]

r? compiler

[compiler-errors]

r? compiler

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[jieyouxu]

@rustbot ready

[bors]

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

[cjgillot]

Thanks! 3 nits and r=me.

[cjgillot]

This is not used any more.

[cjgillot]

You can remove it, it is not used any more.

[cjgillot]

@bors r+

[bors]

📌 Commit 08c77a6 has been approved by cjgillot

It is now in the queue for this repository.

[bors]

⌛ Testing commit 08c77a6 with merge c4b1a20fd4e7f3fa31ac9fbf4b3e8dad1f8a912b...

[rust-log-analyzer]

The job armhf-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[cjgillot]

Seems spurious: client.read_exact(&mut header) failed with Connection reset by peer
@bors retry

[bors]

⌛ Testing commit 08c77a6 with merge 11da267...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 11da267 to master...

[rust-timer]

Finished benchmarking commit (11da267): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[0.6%, 0.6%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 658.073s -> 657.937s (-0.02%)