jiebi/CodeConvo huggingface dataset:
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: // TestType, TrFailedMsg, TrIgnored, TrOk, }, }; <ins> use std::any::TypeId; </ins> use std::sync::mpsc::channel; use std::time::Duration;
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result != TrOk); </del> <ins> assert_ne!(result, TrOk); </ins> } #[test]
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrIgnored); </del> <ins> assert_eq!(result, TrIgnored); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrOk); </del> <ins> assert_eq!(result, TrOk); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: panic!("an error message"); } let expected = "foobar"; <del> let failed_msg = "panic did not include expected string"; </del> <ins> let failed_msg = r#"panic did not contain expected string panic message: `"an error message"`, expected substring: `"foobar"`"#; </ins> let desc = TestDescAndFn { desc: TestDesc { name: StaticTestName("whatever"),
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrFailedMsg(format!("{} '{}'", failed_msg, expected))); </del> <ins> assert_eq!(result, TrFailedMsg(failed_msg.to_string())); } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251) #[test] #[cfg(not(target_os = "emscripten"))] fn test_should_panic_non_string_message_type() { use crate::tests::TrFailedMsg; fn f() { panic!(1i32); } let expected = "foobar"; let failed_msg = format!(r#"expected panic with string value, found non-string value: `{:?}` expected substring: `"foobar"`"#, TypeId::of::<i32>()); let desc = TestDescAndFn { desc: TestDesc { name: StaticTestName("whatever"), ignore: false, should_panic: ShouldPanic::YesWithMessage(expected), allow_fail: false, test_type: TestType::Unknown, }, testfn: DynTestFn(Box::new(f)), }; let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; assert_eq!(result, TrFailedMsg(failed_msg)); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrFailedMsg("test did not panic as expected".to_string())); </del> <ins> assert_eq!(result, TrFailedMsg("test did not panic as expected".to_string())); </ins> } fn report_time_test_template(report_time: bool) -> Option<TestExecTime> {
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: ]; for (a, b) in expected.iter().zip(filtered) { <del> assert!(*a == b.desc.name.to_string()); </del> <ins> assert_eq!(*a, b.desc.name.to_string()); </ins> } }
Code change:
produces an expected error: , the original error is replaced with this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nominating because: The trait impl does not exist, the compiler hallucinated it into existence Inherent methods are supposed to take precedence over trait methods This might indicate a quite serious bug in the compiler.
I would suggest stable- and beta-nominating the fix for this PR; it seems like this could warrant a point release. cc
modify labels: beta-nominated stable-nominated
Phew; looks like precedence works correctly in non-error code at least: Crisis averted? :)
assign
unnominating for back ports; we don't backport nominate issues, just Pull Requests.
claim I'll take a look, since is finding this to be mighty tricky to track down
I managed to get similar symptoms without async but with . But this time the trait compiles.
I am 99% sure that also applies here.
The async case is fixed by , I think we should break out the arbitrary self types case into a distinct bug.

Related discussion:
text: <ins> // edition:2018 trait Test<T> { fn is_some(self: T); //~ ERROR invalid `self` parameter type } async fn f() { let x = Some(2); if x.is_some() { println!("Some"); } } fn main() {} </ins>
Code change:
produces an expected error: , the original error is replaced with this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nominating because: The trait impl does not exist, the compiler hallucinated it into existence Inherent methods are supposed to take precedence over trait methods This might indicate a quite serious bug in the compiler.
I would suggest stable- and beta-nominating the fix for this PR; it seems like this could warrant a point release. cc
modify labels: beta-nominated stable-nominated
Phew; looks like precedence works correctly in non-error code at least: Crisis averted? :)
assign
unnominating for back ports; we don't backport nominate issues, just Pull Requests.
claim I'll take a look, since is finding this to be mighty tricky to track down
I managed to get similar symptoms without async but with . But this time the trait compiles.
I am 99% sure that also applies here.
The async case is fixed by , I think we should break out the arbitrary self types case into a distinct bug.

Related discussion:
text: <ins> error[E0307]: invalid `self` parameter type: T --> $DIR/issue-66312.rs:4:22 | LL |     fn is_some(self: T); |                      ^ | = note: type of `self` must be `Self` or a type that dereferences to it = help: consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, `self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one of the previous types except `Self`) error: aborting due to previous error For more information about this error, try `rustc --explain E0307`. </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

Related discussion:
text: "clippy_lints", "compiletest_rs", "derive-new", <ins> "git2", </ins> "lazy_static 1.3.0", "regex", "rustc-workspace-hack", "rustc_tools_util 0.2.0", "semver", "serde", <ins> "tempfile", </ins> "tester", ]
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

Related discussion:
text: <del> Subproject commit 7b8e8293d08d298579470f9d6c74731043c6601a </del> <ins> Subproject commit 7a943a9dfcdca98e5988da6d0b7d2f83a364b5ba </ins>
Code change:
PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are

Related discussion:
text: impl<'tcx> MirPass<'tcx> for SimplifyArmIdentity { fn run_pass(&self, _: TyCtxt<'tcx>, _: MirSource<'tcx>, body: &mut Body<'tcx>) { <del> for bb in body.basic_blocks_mut() { </del> <ins> let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut(); for bb in basic_blocks { </ins> // Need 3 statements: let (s0, s1, s2) = match &mut *bb.statements { [s0, s1, s2] => (s0, s1, s2),
Code change:
PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are

Related discussion:
text: Some(x) => x, }; if local_tmp_s0 != local_tmp_s1 <ins> // The field-and-variant information match up. </ins> || vf_s0 != vf_s1 <ins> // Source and target locals have the same type. // FIXME(Centril | oli-obk): possibly relax to same layout? || local_decls[local_0].ty != local_decls[local_1].ty // We're setting the discriminant of `local_0` to this variant. </ins> || Some((local_0, vf_s0.var_idx)) != match_set_discr(s2) { continue;
Code change:
PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are

Related discussion:
text: <ins> // Checks that `SimplifyArmIdentity` is not applied if enums have incompatible layouts. // Regression test for issue #66856. // // compile-flags: -Zmir-opt-level=2 enum Src { Foo(u8), Bar, } enum Dst { Foo(u8), } fn main() { let e: Src = Src::Foo(0); let _: Dst = match e { Src::Foo(x) => Dst::Foo(x), Src::Bar => Dst::Foo(0), }; } // END RUST SOURCE // START rustc.main.SimplifyArmIdentity.before.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.before.mir // START rustc.main.SimplifyArmIdentity.after.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.after.mir </ins>
Code change:
PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are

Related discussion:
text: <ins> // This used to mis-compile because the mir-opt `SimplifyArmIdentity` // did not check that the types matched up in the `Ok(r)` branch. // // run-pass // compile-flags: -Zmir-opt-level=2 #[derive(Debug, PartialEq, Eq)] enum SpecialsRes { Res(u64) } fn e103() -> SpecialsRes { if let Ok(r) = "1".parse() { SpecialsRes::Res(r) } else { SpecialsRes::Res(42) } } fn main() { assert_eq!(e103(), SpecialsRes::Res(1)); } </ins>