Rename Error::provide to Error::provide_context

[JonasJebing]

Resolves the deref/autoref method name conflict between Error::provide and Provider::provide mentioned in the tracking issue for error_generic_member_access #99301.

Note: provide_context is the method name that was originally proposed in the RFC.

This comment suggests removing the provider API, which would also resolve the name conflict as a side effect. However, even if it is indeed removed, there's still a small chance it'll be brought back later, I guess. Plus, some users (including myself) feel like the name provide_context provides a clearer indication what should be provided.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[waynr]

@m-ou-se @Amanieu @yaahc please excuse the pings on a PR that's not mine, but does anything need to be done for this PR? It seems like a pretty straightforward rename, though it could impact the rustfmt and rust-analyzer nightly builds which I've seen happen when working on #113464. I'll be working on a PR to thiserror to accompany #113464 but I think it could get hairy trying to maintain two different PRs on this repo AND a thiserror PR so I might just cherry-pick this into #113464.

[JonasJebing]

@m-ou-se @Amanieu @yaahc please excuse the pings on a PR that's not mine, but does anything need to be done for this PR? It seems like a pretty straightforward rename, though it could impact the rustfmt and rust-analyzer nightly builds which I've seen happen when working on #113464. I'll be working on a PR to thiserror to accompany #113464 but I think it could get hairy trying to maintain two different PRs on this repo AND a thiserror PR so I might just cherry-pick this into #113464.

@waynr for the record, I don't mind you cherry-picking this PR :)

[m-ou-se]

r? @Amanieu

[Amanieu]

Considering the Provider trait is going to be removed, is it still worth renaming this? The removal of Provider solves the original issue.

[waynr]

@Amanieu ah yeah that's a good point. I'm in favor of sticking with provide.

[bors]

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

[waynr]

Considering the Provider trait is going to be removed, is it still worth renaming this? The removal of Provider solves the original issue.

Ah shoot, I thought I had responded to this. I agree. Without Provider this is no conflict and no need to prioritize merging this. @JonasJebing any objection?

[JonasJebing]

Considering the Provider trait is going to be removed, is it still worth renaming this? The removal of Provider solves the original issue.

Ah shoot, I thought I had responded to this. I agree. Without Provider this is no conflict and no need to prioritize merging this. @JonasJebing any objection?

No objection :)

I did mention in this PRs description that the removal of Provider solves the original issue, too.

This comment suggests removing the provider API, which would also resolve the name conflict as a side effect. However, even if it is indeed removed, there's still a small chance it'll be brought back later, I guess. Plus, some users (including myself) feel like the name provide_context provides a clearer indication what should be provided.