-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
auto-borrow and consistent behavior of pointers #13988
Comments
Closing in favor of the linked RFC issue. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 13, 2023
Fix markdown removal in hover handling whitespace weirdly Fixes rust-lang/rust-analyzer#10028
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Feb 20, 2025
…le_impls` (rust-lang#13988) When looking for `Default` impls that could be derived, we look at the body of their `fn default()` and if it is an fn call or literal we check if they are equivalent to what `#[derive(Default)]` would have used. Now, when checking those fn calls in the `fn default()` body, we also compare against the corresponding type's `Default::default` body to see if our call is equivalent to that one. For example, given ```rust struct S; impl S { fn new() -> S { S } } impl Default for S { fn default() -> S { S::new() } } ``` `<S as Default>::default()` and `S::new()` are considered equivalent. Given that, if the user also writes ```rust struct R { s: S, } impl Default for R { fn default() -> R { R { s: S::new() } } } ``` the `derivable_impls` lint will now trigger. changelog: [`derivable_impls`]: detect when a `Default` impl is using the same fn call that that type's `Default::default` calls changelog: [`mem_replace_with_default`]: detect when `std::mem::replace` is being called with the same fn that that type's `Default::default` calls, without the need of a manually maintained list
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
auto-deref has been added but I'm still interested in a more uniform behavior of custom pointers (meaning the ones that exist by trait implementation) and native ones (like the dying
~T
).An example situation:
I've looked in #7141, #12491, #13542, #5527, #12825, #12610 and RFC 59 but could not grasp whether any would be addressing this or whether it's desirable, sorry if it's a duplicate.
The text was updated successfully, but these errors were encountered: