jiebi/CodeConvo huggingface dataset:
Code change:
The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.

Related discussion:
text: ///     surprising results upon inspecting the bit patterns, ///     as the same calculations might produce NaNs with different bit patterns. /// <del> /// When the number resulting from a primitive operation (addition, /// subtraction, multiplication, or division) on this type is not exactly /// representable as `f32`, it is rounded according to the roundTiesToEven /// direction defined in IEEE 754-2008. That means: </del> <ins> /// When a primitive operation (addition, subtraction, multiplication, or /// division) is performed on this type, the result is rounded according to the /// roundTiesToEven direction defined in IEEE 754-2008. That means: </ins> /// /// - The result is the representable value closest to the true value, if there ///   is a unique closest representable value.
Code change:
The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.

Related discussion:
text: /// - If the true value's magnitude is ≥ `f32::MAX` + 2<sup>(`f32::MAX_EXP` − ///   `f32::MANTISSA_DIGITS` − 1)</sup>, the result is ∞ or −∞ (preserving the ///   true value's sign). <ins> /// - If the result of a sum exactly equals zero, the outcome is +0.0 unless ///   both arguments were negative, then it is -0.0. Subtraction `a - b` is ///   regarded as a sum `a + (-b)`. </ins> /// /// For more information on floating point numbers, see [Wikipedia][wikipedia]. ///
Code change:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

Related discussion:
text: use cell::RefCell; use intrinsics; use sync::StaticRwLock; <ins> use sync::atomic::{AtomicBool, Ordering}; </ins> use sys::stdio::Stderr; use sys_common::backtrace; use sys_common::thread_info;
Code change:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

Related discussion:
text: static HANDLER_LOCK: StaticRwLock = StaticRwLock::new(); static mut HANDLER: Handler = Handler::Default; <ins> static FIRST_PANIC: AtomicBool = AtomicBool::new(true); </ins> /// Registers a custom panic handler, replacing any that was previously /// registered.
Code change:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

Related discussion:
text: let write = |err: &mut ::io::Write| { let _ = writeln!(err, "thread '{}' panicked at '{}', {}:{}", name, msg, file, line); if log_backtrace { let _ = backtrace::write(err); <ins> } else if FIRST_PANIC.compare_and_swap(true, false, Ordering::SeqCst) { let _ = writeln!(err, "note: Run with `RUST_BACKTRACE=1` for a backtrace."); </ins> } };
Code change:
Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)

Related discussion:
text: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let args: Vec<String> = std::env::args().collect(); if args.len() > 1 && args[1] == "run_test" { let _ = std::thread::spawn(|| { panic!(); }).join(); panic!(); } else { let test = std::process::Command::new(&args[0]).arg("run_test").output().unwrap(); assert!(!test.status.success()); let err = String::from_utf8_lossy(&test.stderr); let mut it = err.lines(); assert_eq!(it.next().map(|l| l.starts_with("thread '<unnamed>' panicked at")), Some(true)); assert_eq!(it.next(), Some("note: Run with `RUST_BACKTRACE=1` for a backtrace.")); assert_eq!(it.next().map(|l| l.starts_with("thread '<main>' panicked at")), Some(true)); assert_eq!(it.next(), None); } } </ins>
Code change:
https://crater-
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-10 regressed nightly: nightly-2023-09-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsthis bisection may look pretty nonsensical, but I did manually confirm that nightly-2023-09-14 worked and nightly-2023-09-16 didn't. I am surprised that this ever parsed, and given that there's only a single random repo that regressed, and the regressing code is a mistake, I don't think this is a problematic regression. anyways.
Agreed that we don't necessarily need a fix, but we should try to make sure that this is indeed limited to this one case (i.e., it's not some broader incompatibility that may have gone uncaught in Crater)
The change here is that AST validation is now checking that the attribute is valid. Some other cases: Marking as needs-test, with the new behavior being correct

Related discussion:
text: <ins> // test for #117058 - check that attributes are validated on various kinds of statements. struct A; fn func() {} fn main() { #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` if true { } else { } #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` (1); #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` match 1 { _ => {} } #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` while false {} #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` {} #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` A {}; #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` func(); #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` A; #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` loop {} } </ins>
Code change:
https://crater-
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-10 regressed nightly: nightly-2023-09-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsthis bisection may look pretty nonsensical, but I did manually confirm that nightly-2023-09-14 worked and nightly-2023-09-16 didn't. I am surprised that this ever parsed, and given that there's only a single random repo that regressed, and the regressing code is a mistake, I don't think this is a problematic regression. anyways.
Agreed that we don't necessarily need a fix, but we should try to make sure that this is indeed limited to this one case (i.e., it's not some broader incompatibility that may have gone uncaught in Crater)
The change here is that AST validation is now checking that the attribute is valid. Some other cases: Marking as needs-test, with the new behavior being correct

Related discussion:
text: <ins> error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:8:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:13:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:16:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:21:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:24:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:27:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:30:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:33:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: expected one of `(`, `,`, `::`, or `=`, found `-` --> $DIR/statement-attribute-validation.rs:36:16 | LL |     #[allow(two-words)] |                ^ expected one of `(`, `,`, `::`, or `=` error: aborting due to 9 previous errors </ins>
Code change:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.

Related discussion:
text: expected: Ty<'tcx>, found: Ty<'tcx>, ) -> bool { <del> let ty::Adt(adt, args) = found.kind() else { return false }; </del> <ins> let ty::Adt(adt, args) = found.kind() else { return false; }; </ins> let ret_ty_matches = |diagnostic_item| { <del> if let Some(ret_ty) = self .ret_coercion .as_ref() .map(|c| self.resolve_vars_if_possible(c.borrow().expected_ty())) && let ty::Adt(kind, _) = ret_ty.kind() && self.tcx.get_diagnostic_item(diagnostic_item) == Some(kind.did()) { true } else { false } </del> <ins> let Some(sig) = self.body_fn_sig() else { return false; }; let ty::Adt(kind, _) = sig.output().kind() else { return false; }; self.tcx.is_diagnostic_item(diagnostic_item, kind.did()) </ins> }; // don't suggest anything like `Ok(ok_val).unwrap()` , `Some(some_val).unwrap()`,
Code change:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.

Related discussion:
text: <ins> // edition: 2021 async fn dont_suggest() -> i32 { if false { return Ok(6); //~^ ERROR mismatched types } 5 } async fn do_suggest() -> i32 { if false { let s = Ok(6); return s; //~^ ERROR mismatched types } 5 } fn main() {} </ins>
Code change:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/async-unwrap-suggestion.rs:5:16 | LL |         return Ok(6); |                ^^^^^ expected `i32`, found `Result<{integer}, _>` | = note: expected type `i32` found enum `Result<{integer}, _>` error[E0308]: mismatched types --> $DIR/async-unwrap-suggestion.rs:15:16 | LL |         return s; |                ^ expected `i32`, found `Result<{integer}, _>` | = note: expected type `i32` found enum `Result<{integer}, _>` help: consider using `Result::expect` to unwrap the `Result<{integer}, _>` value, panicking if the value is a `Result::Err` | LL |         return s.expect("REASON"); |                 +++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: ("macro_registrar", Active), ("log_syntax", Active), ("trace_macros", Active), <ins> ("simd", Active), </ins> // These are used to test this portion of the compiler, they don't actually // mean anything
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: } } <ins> ast::ItemStruct(..) => { if attr::contains_name(i.attrs, "simd") { self.gate_feature("simd", i.span, "SIMD types are experimental and possibly buggy"); } } </ins> _ => {} }
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")]; <del> #[feature(macro_rules, globs, asm, managed_boxes, thread_local, link_args)]; </del> <ins> #[feature(macro_rules, globs, asm, managed_boxes, thread_local, link_args, simd)]; </ins> // Don't link to std. We are std. #[no_std]; #[deny(non_camel_case_types)]; #[deny(missing_doc)]; <ins> #[allow(unknown_features)]; </ins> // When testing libstd, bring in libuv as the I/O backend so tests can print // things and all of the std::io tests have an I/O interface to run on top
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: #[allow(non_camel_case_types)]; <ins> #[experimental] </ins> #[simd] pub struct i8x16(i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8); <ins> #[experimental] </ins> #[simd] pub struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16); <ins> #[experimental] </ins> #[simd] pub struct i32x4(i32, i32, i32, i32); <ins> #[experimental] </ins> #[simd] pub struct i64x2(i64, i64); <ins> #[experimental] </ins> #[simd] pub struct u8x16(u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8); <ins> #[experimental] </ins> #[simd] pub struct u16x8(u16, u16, u16, u16, u16, u16, u16, u16); <ins> #[experimental] </ins> #[simd] pub struct u32x4(u32, u32, u32, u32); <ins> #[experimental] </ins> #[simd] pub struct u64x2(u64, u64); <ins> #[experimental] </ins> #[simd] pub struct f32x4(f32, f32, f32, f32); <ins> #[experimental] </ins> #[simd] pub struct f64x2(f64, f64);
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[simd] pub struct i64x2(i64, i64); //~ ERROR: SIMD types are experimental fn main() {} </ins>  No newline at end of file
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // xfail-test FIXME #11741 tuple structs ignore stability attributes #[deny(experimental)]; use std::unstable::simd; fn main() { let _ = simd::i64x2(0, 0); //~ ERROR: experimental } </ins>
Code change:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #[allow(experimental)]; </ins> use std::unstable::simd::{i32x4, f32x4}; fn test_int(e: i32) -> i32 {
Code change:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

Related discussion:
text: // types are fine though. ty::ConstKind::Value(_) => c.ty().is_primitive(), ty::ConstKind::Unevaluated(..) | ty::ConstKind::Expr(..) => false, <ins> // This can happen if evaluation of a constant failed. The result does not matter // much since compilation is doomed. ty::ConstKind::Error(..) => false, </ins> // Should not appear in runtime MIR. ty::ConstKind::Infer(..) | ty::ConstKind::Bound(..) <del> | ty::ConstKind::Placeholder(..) | ty::ConstKind::Error(..) => bug!(), </del> <ins> | ty::ConstKind::Placeholder(..) => bug!(), </ins> }, Const::Unevaluated(..) => false, // If the same slice appears twice in the MIR, we cannot guarantee that we will
Code change:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

Related discussion:
text: <ins> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:16:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:5 | LL |     &<A<T> as Foo<T>>::BAR |     ^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>
Code change:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

Related discussion:
text: <ins> error[E0080]: evaluation of `<A<()> as Foo<()>>::BAR` failed --> $DIR/issue-50814-2.rs:16:24 | LL |     const BAR: usize = [5, 6, 7][T::BOO]; |                        ^^^^^^^^^^^^^^^^^ index out of bounds: the length is 3 but the index is 42 note: erroneous constant encountered --> $DIR/issue-50814-2.rs:20:6 | LL |     &<A<T> as Foo<T>>::BAR |      ^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn foo::<()>` --> $DIR/issue-50814-2.rs:32:22 | LL |     println!("{:x}", foo::<()>() as *const usize as usize); |                      ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>
Code change:
File: /tmp/icemaker/issue--2.rs auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
cc

Related discussion:
text: // build-fail <ins> // revisions: normal mir-opt // [mir-opt]compile-flags: -Zmir-opt-level=4 </ins> trait C { const BOO: usize;