jiebi/CodeConvo huggingface dataset:
Code change:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL | fn wat<T>(t: &T) -> T { |        -            - expected `T` because of return type |        | |        this type parameter LL |     t.clone() |     ^^^^^^^^^ expected type parameter `T`, found `&T` | = note: expected type parameter `T` found reference `&T` note: `T` does not implement `Clone`, so `&T` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL |     t.clone() |     ^ help: consider restricting type parameter `T` | LL | fn wat<T: Clone>(t: &T) -> T { |         +++++++ error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL | fn wut(t: &Foo) -> Foo { |                    --- expected `Foo` because of return type LL |     t.clone() |     ^^^^^^^^^ expected struct `Foo`, found `&Foo` | note: `Foo` does not implement `Clone`, so `&Foo` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL |     t.clone() |     ^ help: consider annotating `Foo` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

Related discussion:
text: | LL |     nc.clone() |     ^^ <ins> help: consider annotating `NotClone` with `#[derive(Clone)]` | LL | #[derive(Clone)] | </ins> error: aborting due to previous error
Code change:
Was just trying to read through std::fmt to understand how format values to a particular decimal point. I came across this set of examples, which don't do a good job of explaining the output of each, so it's difficult to visually pattern match what I type in to what comes out:
Sorry for the mess :sweat_smile: I guess it is clearer now.

Related discussion:
text: //!    in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers //!    to the *value* to print, and the `precision` must come in the input preceding `<arg>`. //! <del> //! For example, these: </del> <ins> //! For example, the following calls all print the same thing `Hello x is 0.01000`: </ins> //! //! ``` <del> //! // Hello {arg 0 (x)} is {arg 1 (0.01) with precision specified inline (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 1 (0.01) with precision specified inline (5)} </ins> //! println!("Hello {0} is {1:.5}", "x", 0.01); //! <del> //! // Hello {arg 1 (x)} is {arg 2 (0.01) with precision specified in arg 0 (5)} </del> <ins> //! // Hello {arg 1 ("x")} is {arg 2 (0.01) with precision specified in arg 0 (5)} </ins> //! println!("Hello {1} is {2:.0$}", 5, "x", 0.01); //! <del> //! // Hello {arg 0 (x)} is {arg 2 (0.01) with precision specified in arg 1 (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 2 (0.01) with precision specified in arg 1 (5)} </ins> //! println!("Hello {0} is {2:.1$}", "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {second of next two args (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {second of next two args (0.01) with precision </ins> //! //                          specified in first of next two args (5)} //! println!("Hello {} is {:.*}",    "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg 2 (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {arg 2 (0.01) with precision </ins> //! //                          specified in its predecessor (5)} //! println!("Hello {} is {2:.*}",   "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg "number" (0.01) with precision specified </del> <ins> //! // Hello {next arg ("x")} is {arg "number" (0.01) with precision specified </ins> //! //                          in arg "prec" (5)} //! println!("Hello {} is {number:.prec$}", "x", prec = 5, number = 0.01); //! ``` //! <del> //! All print the same thing: //! //! ```text //! Hello x is 0.01000 //! ``` //! </del> //! While these: //! //! ```
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: /// ``` #[stable(feature = "move_cell", since = "1.17.0")] pub fn into_inner(self) -> T { <del> unsafe { self.value.into_inner() } </del> <ins> self.value.into_inner() </ins> } }
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: // compiler statically verifies that it is not currently borrowed. // Therefore the following assertion is just a `debug_assert!`. debug_assert!(self.borrow.get() == UNUSED); <del> unsafe { self.value.into_inner() } </del> <ins> self.value.into_inner() </ins> } /// Replaces the wrapped value with a new one, returning the old value,
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: /// Unwraps the value. /// <del> /// # Safety /// /// This function is unsafe because this thread or another thread may currently be /// inspecting the inner value. /// </del> /// # Examples /// /// ```
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: /// /// let uc = UnsafeCell::new(5); /// <del> /// let five = unsafe { uc.into_inner() }; </del> <ins> /// let five = uc.into_inner(); </ins> /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> pub unsafe fn into_inner(self) -> T { </del> <ins> pub fn into_inner(self) -> T { </ins> self.value } }
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: #[inline] #[stable(feature = "atomic_access", since = "1.15.0")] pub fn into_inner(self) -> bool { <del> unsafe { self.v.into_inner() != 0 } </del> <ins> self.v.into_inner() != 0 </ins> } /// Loads a value from the bool.
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: #[inline] #[stable(feature = "atomic_access", since = "1.15.0")] pub fn into_inner(self) -> *mut T { <del> unsafe { self.p.into_inner() } </del> <ins> self.p.into_inner() </ins> } /// Loads a value from the pointer.
Code change:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

Related discussion:
text: #[inline] #[$stable_access] pub fn into_inner(self) -> $int_type { <del> unsafe { self.v.into_inner() } </del> <ins> self.v.into_inner() </ins> } /// Loads a value from the atomic integer.
Code change:
From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

Related discussion:
text: let &(ref first_arm_pats, _) = &arms[0]; let first_pat = &first_arm_pats[0]; let span = first_pat.span; <del> span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern"); </del> <ins> struct_span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern") .span_label(span, &format!("irrefutable pattern")) .emit(); </ins> }, hir::MatchSource::ForLoopDesugar => {
Code change:
From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

Related discussion:
text: tcx.sess.add_lint(lint::builtin::MATCH_OF_UNIT_VARIANT_VIA_PAREN_DOTDOT, pat.id, pat.span, msg); } else { <del> span_err!(tcx.sess, pat.span, E0164, "{}", msg); </del> <ins> struct_span_err!(tcx.sess, pat.span, E0164, "{}", msg) .span_label(pat.span, &format!("not a tuple variant or struct")).emit(); </ins> on_error(); } };
Code change:
From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

Related discussion:
text: .emit(); } Err(CopyImplementationError::HasDestructor) => { <del> span_err!(tcx.sess, span, E0184, </del> <ins> struct_span_err!(tcx.sess, span, E0184, </ins> "the trait `Copy` may not be implemented for this type;  <del> the type has a destructor"); </del> <ins> the type has a destructor") .span_label(span, &format!("Copy not allowed on types with destructors")) .emit(); </ins> } } });
Code change:
From: src/test/compile- E0263 needs a span_label, updating it from: To: Bonus: underline and label the previous declaration:
I'm on it.

Related discussion:
text: let lifetime_j = &lifetimes[j]; if lifetime_i.lifetime.name == lifetime_j.lifetime.name { <del> span_err!(self.sess, lifetime_j.lifetime.span, E0263, "lifetime name `{}` declared twice in  the same scope", lifetime_j.lifetime.name); </del> <ins> struct_span_err!(self.sess, lifetime_j.lifetime.span, E0263, "lifetime name `{}` declared twice in the same scope", lifetime_j.lifetime.name) .span_label(lifetime_j.lifetime.span, &format!("declared twice")) .span_label(lifetime_i.lifetime.span, &format!("previous declaration here")) .emit(); </ins> } }
Code change:
From: src/test/compile- E0263 needs a span_label, updating it from: To: Bonus: underline and label the previous declaration:
I'm on it.

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { } //~ ERROR E0263 </del> <ins> fn foo<'a, 'b, 'a>(x: &'a str, y: &'b str) { //~^ ERROR E0263 //~| NOTE declared twice //~| NOTE previous declaration here } </ins> fn main() {}