Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create unnecessary_send_constraint lint for &(dyn ... + Send) #110961

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

john-h-k
Copy link
Contributor

Fixes #110937

Does not yet handle `Send` being only constraint (will still recommend removing it)
@rustbot
Copy link
Collaborator

rustbot commented Apr 28, 2023

r? @davidtwco

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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 28, 2023
@rustbot
Copy link
Collaborator

rustbot commented Apr 28, 2023

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

library/core/src/cell.rs Outdated Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@john-h-k
Copy link
Contributor Author

Also, tests/ui/lint tests seem to have really inconsistent naming - when should I use hyphens vs underscores in file names?

@john-h-k
Copy link
Contributor Author

Also, it appears no lint is generated for duplicate auto traits (like &(dyn Any + Any + Send)). Is there a reason for this? If not I can add that to as the logic is similar ish (in a separate PR)

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jun 27, 2023
@rfcbot
Copy link

rfcbot commented Jun 27, 2023

🔔 This is now entering its final comment period, as per the review above. 🔔

/// References cannot be sent across threads unless they have a `Sync` bound, so constraining them to `Send` without `Sync` is unnecessary.
pub UNNECESSARY_SEND_CONSTRAINT,
Warn,
"constraining a reference to `Send` without `Sync` is unnecessary, consider removing it"
Copy link
Member

@RalfJung RalfJung Jun 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the recommendation be to replace Send by Sync? That seems more likely to be what the author intended.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this comment: #110961 (comment)

In those situations, it stems from a Box<dyn Any + Send> to which a &dyn was made. It's easy to just copy Any + Send, but the Send part should be removed for shared references.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like a fairly special case to me, I would not expect this to be common enough to warrant a general recommendation of dropping the Send. The more symmetric thing to do would be to have &dyn Any+Sync, to get a shared reference that can still be shared across thread boundaries. Of course then you'd need Box<dyn Any+Send+Sync> for the owned case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it should recommend replacing Send with Sync instead? just confirming before making the change

@@ -192,6 +192,12 @@ lint_redundant_semicolons =
*[false] this semicolon
}

lint_unnecessary_send_constraint = constraining a reference to `Send` is meaningless
.suggestion = {$only_trait ->
[true] replace this with `std::any::Any`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replacing by Any is a very strange suggestion. Why would type_id machinery be necessary? Can't the 'static bound cause a problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure what else to put, this is for the scenario where Send is the only trait specified (so removing it would be invalid)

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jul 7, 2023
@rfcbot
Copy link

rfcbot commented Jul 7, 2023

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label Jul 7, 2023
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jul 13, 2023
@nikomatsakis
Copy link
Contributor

It looks like we agreed to this. I'm going to drop nomination.

@rustbot labels -I-lang-nominated

@rustbot rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Jul 18, 2023
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Jul 18, 2023
Explicitly document how Send and Sync relate to references

Some of these relations were already mentioned in the text, but that Send is implemented for &mut impl Send was not mentioned, neither did the docs list when &T is Sync. Inspired by the discussion in #110961.

[Proof](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ed77bfc3c77ba664400ebc2734f500e6) based on `@lukas-code` 's [example](rust-lang/rust#110961 (comment)).
@nikomatsakis
Copy link
Contributor

@rustbot author

The team role is done here, FCP is complete, we are now waiting on the author to address feedback though.

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 25, 2023
@joshtriplett joshtriplett removed the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label Aug 8, 2023
@john-h-k
Copy link
Contributor Author

@rustbot ready

(still 1 part of the review I am unsure about so have asked for clarification, but other comments have been addressed)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 31, 2023
pub fn get_mut(&mut self) -> Option<&mut (dyn error::Error + Send + Sync + 'static)> {
pub fn get_mut(&mut self) -> Option<&mut (dyn error::Error + Sync + 'static)> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a mutable reference. For &mut … + Send, the Send makes sense, doesn’t it?

pub fn get_ref(&self) -> Option<&(dyn error::Error + Send + Sync + 'static)> {
pub fn get_ref(&self) -> Option<&(dyn error::Error + Sync + 'static)> {
Copy link
Member

@steffahn steffahn Jan 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dyn Error + Send + Sync has some API that dyn Error + Sync doesn’t have. Like an is method and a downcast_ref method.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, in any case, changing these methods is a breaking change the impact of which I’m not sure has been tested anywhere yet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that dyn Error + Sync doesn’t have. Like an is method and a downcast_ref method.

dyn Error also implements is and downcast_* with exact the same signature.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dyn Error also implements is and downcast_* with exact the same signature.

Oops, my bad. We cannot use dyn Error's methods on dyn Error + Sync, though it seems odd to me.

@Dylan-DPC
Copy link
Member

@john-h-k if you can rebase and resolve the conflicts, we can push this for a review

@Dylan-DPC Dylan-DPC added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a lint to warn about &(dyn … + Send)