jiebi/CodeConvo huggingface dataset:
Code change:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> // run-rustfix </del> #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> {
Code change:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)

Related discussion:
text: fn forbidden_narratives() -> Result<isize, ()> { missing_discourses()? //~^ ERROR try expression alternatives have incompatible types <del> //~| HELP try wrapping with a success variant </del> } fn main() {}
Code change:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)

Related discussion:
text: error[E0308]: try expression alternatives have incompatible types <del> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:20:5 </del> <ins> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:18:5 </ins> | LL |     missing_discourses()? <del> |     ^^^^^^^^^^^^^^^^^^^^^ |     | |     expected enum `std::result::Result`, found isize |     help: try wrapping with a success variant: `Ok(missing_discourses()?)` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found isize </ins> | = note: expected type `std::result::Result<isize, ()>` found type `isize`
Code change:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up. I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim

Related discussion:
text: )); } <del> let needs_parens = match expr.kind { // parenthesize if needed (Issue #46756) hir::ExprKind::Cast(_, _) | hir::ExprKind::Binary(_, _, _) => true, // parenthesize borrows of range literals (Issue #54505) _ if is_range_literal(expr) => true, _ => false, }; </del> if let Some((sugg, msg)) = self.can_use_as_ref(expr) { return Some(( sugg,
Code change:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up. I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim

Related discussion:
text: <ins> // Issue #52544 // run-rustfix fn main() { let i: &i64 = &1; if *i < 0 {} //~^ ERROR mismatched types [E0308] } </ins>
Code change:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up. I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim

Related discussion:
text: <ins> // Issue #52544 // run-rustfix fn main() { let i: &i64 = &1; if i < 0 {} //~^ ERROR mismatched types [E0308] } </ins>
Code change:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up. I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/binary-op-suggest-deref.rs:6:12 | LL |     if i < 0 {} |            ^ expected `&i64`, found integer | help: consider dereferencing the borrow | LL |     if *i < 0 {} |        + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.

Related discussion:
text: <del> Subproject commit 52a6a4d7087d14a35d44a11c39c77fa79d71378d </del> <ins> Subproject commit d549d85b1735dc5066b2973f8549557a813bb9c8 </ins>
Code change:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.

Related discussion:
text: <del> Subproject commit 03684905101f0b7e49dfe530e54dc1aeac6ef0fb </del> <ins> Subproject commit e19f07f5a6e5546ab4f6ea951e3c6b8627edeaa7 </ins>
Code change:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.

Related discussion:
text: # If this file is modified, then llvm will be (optionally) cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2018-07-12 </del>  No newline at end of file <ins> 2018-08-02 </ins>
Code change:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.

Related discussion:
text: <del> Subproject commit 8214ccf861d538671b0a1436dbf4538dc4a64d09 </del> <ins> Subproject commit f76ea3ca16ed22dde8ef929db74a4b4df6f2f899 </ins>
Code change:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by

Related discussion:
text: <ins> // ignore-tidy-linelength #![feature(type_alias_impl_trait)] use std::fmt::Debug; pub trait Foo { type Item: Debug; fn foo<T: Debug>(_: T) -> Self::Item; } #[derive(Debug)] pub struct S<T>(std::marker::PhantomData<T>); pub struct S2; impl Foo for S2 { type Item = impl Debug; fn foo<T: Debug>(_: T) -> Self::Item { //~^ Error type parameter `T` is part of concrete type but not used in parameter list for the `impl Trait` type alias S::<T>(Default::default()) } } fn main() { S2::foo(123); } </ins>
Code change:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by

Related discussion:
text: <ins> error: type parameter `T` is part of concrete type but not used in parameter list for the `impl Trait` type alias --> $DIR/issue-53598.rs:20:42 | LL |       fn foo<T: Debug>(_: T) -> Self::Item { |  __________________________________________^ LL | | LL | |         S::<T>(Default::default()) LL | |     } | |_____^ error: aborting due to previous error </ins>
Code change:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by

Related discussion:
text: <ins> // ignore-tidy-linelength #![feature(arbitrary_self_types)] #![feature(type_alias_impl_trait)] use std::ops::Deref; trait Foo { type Bar: Foo; fn foo(self: impl Deref<Target = Self>) -> Self::Bar; } impl<C> Foo for C { type Bar = impl Foo; fn foo(self: impl Deref<Target = Self>) -> Self::Bar { //~^ Error type parameter `impl Deref<Target = Self>` is part of concrete type but not used in parameter list for the `impl Trait` type alias self } } fn main() {} </ins>