jiebi/CodeConvo huggingface dataset:
Code change:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim

Related discussion:
text: err_ty_str = format!("`{}`", ty); Some(err_ty_str.as_str()) } <del> } }; if let Some(unsupported_type) = err { if is_ptr { tcx.sess.span_err( hir_ty.span, &format!( "using {} as const generic parameters is forbidden", unsupported_type ), ); } else { let mut err = tcx.sess.struct_span_err( hir_ty.span, &format!( "{} is forbidden as the type of a const generic parameter", unsupported_type ), ); err.note("the only supported types are integers, `bool` and `char`"); if tcx.sess.is_nightly_build() { err.help( </del> <ins> }; if let Some(unsupported_type) = err { if is_ptr { tcx.sess.span_err( hir_ty.span, &format!( "using {} as const generic parameters is forbidden", unsupported_type ), ); } else { let mut err = tcx.sess.struct_span_err( hir_ty.span, &format!( "{} is forbidden as the type of a const generic parameter", unsupported_type ), ); err.note("the only supported types are integers, `bool` and `char`"); if tcx.sess.is_nightly_build() { err.help( </ins> "more complex types are supported with `#![feature(adt_const_params)]`", ); <ins> } err.emit(); </ins> } <del> err.emit(); } }; if traits::search_for_structural_match_violation(param.span, tcx, ty).is_some() { // We use the same error code in both branches, because this is really the same // issue: we just special-case the message for type parameters to make it // clearer. if let ty::Param(_) = ty.peel_refs().kind() { // Const parameters may not have type parameters as their types, // because we cannot be sure that the type parameter derives `PartialEq` // and `Eq` (just implementing them is not enough for `structural_match`). struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be  used as the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` may not derive both `PartialEq` and `Eq`", ty), ) .note( "it is not currently possible to use a type parameter as the type of a  const parameter", ) .emit(); } else { struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` must be annotated with `#[derive(PartialEq, Eq)]` to be used as  the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` doesn't derive both `PartialEq` and `Eq`", ty), ) .emit(); </del> } } }
Code change:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim

Related discussion:
text: = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error[E0741]: `&'static (dyn A + 'static)` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter --> $DIR/issue-63322-forbid-dyn.rs:9:18 | LL | fn test<const T: &'static dyn A>() { |                  ^^^^^^^^^^^^^^ `&'static (dyn A + 'static)` doesn't derive both `PartialEq` and `Eq` error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> For more information about this error, try `rustc --explain E0741`. </del>
Code change:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim

Related discussion:
text: impl A for B {} fn test<const T: &'static dyn A>() { <del> //~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used </del> <ins> //[full]~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used </ins> //[min]~^^ ERROR `&'static (dyn A + 'static)` is forbidden unimplemented!() }
Code change:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim

Related discussion:
text: = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error[E0015]: cannot call non-const fn `Foo::{constant#0}::Foo::<17_usize>::value` in constants --> $DIR/nested-type.rs:15:5 | LL |     Foo::<17>::value() |     ^^^^^^^^^^^^^^^^^^ | = note: calls in constants are limited to constant functions, tuple structs and tuple variants error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> For more information about this error, try `rustc --explain E0015`. </del>
Code change:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim

Related discussion:
text: } Foo::<17>::value() <del> //~^ ERROR cannot call non-const fn </del> <ins> //[full]~^ ERROR cannot call non-const fn </ins> }]>; fn main() {}
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.

Related discussion:
text: use super::{Custom, ErrorData, ErrorKind, SimpleMessage}; use alloc::boxed::Box; <ins> use core::marker::PhantomData; </ins> use core::mem::{align_of, size_of}; use core::ptr::NonNull;
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.

Related discussion:
text: const TAG_OS: usize = 0b10; const TAG_SIMPLE: usize = 0b11; <ins> /// The internal representation. /// /// See the module docs for more, this is just a way to hack in a check that we /// indeed are not unwind-safe. /// /// ```compile_fail,E0277 /// fn is_unwind_safe<T: core::panic::UnwindSafe>() {} /// is_unwind_safe::<std::io::Error>(); /// ``` </ins> #[repr(transparent)] <del> pub(super) struct Repr(NonNull<()>); </del> <ins> pub(super) struct Repr(NonNull<()>, PhantomData<ErrorData<Box<Custom>>>); </ins> // All the types `Repr` stores internally are Send + Sync, and so is it. unsafe impl Send for Repr {}
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.

Related discussion:
text: // box, and `TAG_CUSTOM` just... isn't zero -- it's `0b01`). Therefore, // `TAG_CUSTOM + p` isn't zero and so `tagged` can't be, and the // `new_unchecked` is safe. <del> let res = Self(unsafe { NonNull::new_unchecked(tagged) }); </del> <ins> let res = Self(unsafe { NonNull::new_unchecked(tagged) }, PhantomData); </ins> // quickly smoke-check we encoded the right thing (This generally will // only run in libstd's tests, unless the user uses -Zbuild-std) debug_assert!(matches!(res.data(), ErrorData::Custom(_)), "repr(custom) encoding failed");
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.

Related discussion:
text: pub(super) fn new_os(code: i32) -> Self { let utagged = ((code as usize) << 32) | TAG_OS; // Safety: `TAG_OS` is not zero, so the result of the `|` is not 0. <del> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }); </del> <ins> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }, PhantomData); </ins> // quickly smoke-check we encoded the right thing (This generally will // only run in libstd's tests, unless the user uses -Zbuild-std) debug_assert!(
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.

Related discussion:
text: pub(super) fn new_simple(kind: ErrorKind) -> Self { let utagged = ((kind as usize) << 32) | TAG_SIMPLE; // Safety: `TAG_SIMPLE` is not zero, so the result of the `|` is not 0. <del> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }); </del> <ins> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }, PhantomData); </ins> // quickly smoke-check we encoded the right thing (This generally will // only run in libstd's tests, unless the user uses -Zbuild-std) debug_assert!(
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.

Related discussion:
text: #[inline] pub(super) const fn new_simple_message(m: &'static SimpleMessage) -> Self { // Safety: References are never null. <del> Self(unsafe { NonNull::new_unchecked(m as *const _ as *mut ()) }) </del> <ins> Self(unsafe { NonNull::new_unchecked(m as *const _ as *mut ()) }, PhantomData) </ins> } #[inline]
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: //! Everything here is basically just a shim around calling either `rustbook` or //! `rustdoc`. <del> use std::collections::HashSet; </del> use std::fs; use std::io; use std::path::{Path, PathBuf};
Code change:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild

Related discussion:
text: let paths = builder .paths .iter() <del> .map(components_simplified) .filter_map(|path| { if path.get(0) == Some(&"compiler") { path.get(1).map(|p| p.to_owned()) } else { None } </del> <ins> .filter(|path| { let components = components_simplified(path); components.len() >= 2 && components[0] == "compiler" </ins> }) .collect::<Vec<_>>();