jiebi/CodeConvo huggingface dataset:
Code change:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

Related discussion:
text: // the post-inference `trait_ref`, as it's more accurate. trait_: Some(trait_ref.clean(cx)), for_: ty.clean(cx), <del> items: cx .tcx .associated_items(impl_def_id) .in_definition_order() .map(|x| x.clean(cx)) .collect::<Vec<_>>(), </del> <ins> items, </ins> polarity: ty::ImplPolarity::Positive, kind: ImplKind::Blanket(box trait_ref.self_ty().clean(cx)), }),
Code change:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

Related discussion:
text: /// the hashmap because certain items (traits and types) need to have their mappings for trait /// implementations filled out before they're inserted. fn item(&mut self, item: clean::Item) -> Result<(), Error> { <del> let local_blanket_impl = match item.def_id { clean::ItemId::Blanket { impl_id, .. } => impl_id.is_local(), clean::ItemId::Auto { .. } | clean::ItemId::DefId(_) | clean::ItemId::Primitive(_, _) => false, }; </del> // Flatten items that recursively store other items <del> // FIXME(CraftSpider): We skip children of local blanket implementations, as we'll have //     already seen the actual generic impl, and the generated ones don't need documenting. //     This is necessary due to the visibility, return type, and self arg of the generated //     impls not quite matching, and will no longer be necessary when the mismatch is fixed. if !local_blanket_impl { item.kind.inner_items().for_each(|i| self.item(i.clone()).unwrap()); } </del> <ins> item.kind.inner_items().for_each(|i| self.item(i.clone()).unwrap()); </ins> let id = item.def_id; if let Some(mut new_item) = self.convert_item(item) {
Code change:
Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):

Related discussion:
text: // @has blanket_with_local.json "$.index[*][?(@.name=='Load')]" pub trait Load { <ins> // @has - "$.index[*][?(@.name=='load')]" </ins> fn load() {} <ins> // @has - "$.index[*][?(@.name=='write')]" fn write(self) {} </ins> } impl<P> Load for P { fn load() {} <ins> fn write(self) {} </ins> } // @has - "$.index[*][?(@.name=='Wrapper')]"
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: use option::{Option,Some,None}; use libc::c_void; use ops::Drop; <ins> use util::NonCopyable; </ins> /** * A simple atomic flag, that can be set and cleared. The most basic atomic type. */ pub struct AtomicFlag { <del> priv v: int </del> <ins> priv v: int, priv nocopy: NonCopyable </ins> } /** * An atomic boolean type. */ pub struct AtomicBool { <del> priv v: uint </del> <ins> priv v: uint, priv nocopy: NonCopyable </ins> } /** * A signed atomic integer type, supporting basic atomic arithmetic operations */ pub struct AtomicInt { <del> priv v: int </del> <ins> priv v: int, priv nocopy: NonCopyable </ins> } /** * An unsigned atomic integer type, supporting basic atomic arithmetic operations */ pub struct AtomicUint { <del> priv v: uint </del> <ins> priv v: uint, priv nocopy: NonCopyable </ins> } /** * An unsafe atomic pointer. Only supports basic atomic operations */ pub struct AtomicPtr<T> { <del> priv p: *mut T </del> <ins> priv p: *mut T, priv nocopy: NonCopyable </ins> } /**
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: SeqCst } <del> pub static INIT_ATOMIC_FLAG : AtomicFlag = AtomicFlag { v: 0 }; pub static INIT_ATOMIC_BOOL : AtomicBool = AtomicBool { v: 0 }; pub static INIT_ATOMIC_INT  : AtomicInt  = AtomicInt  { v: 0 }; pub static INIT_ATOMIC_UINT : AtomicUint = AtomicUint { v: 0 }; </del> <ins> pub static INIT_ATOMIC_FLAG : AtomicFlag = AtomicFlag { v: 0, nocopy: NonCopyable }; pub static INIT_ATOMIC_BOOL : AtomicBool = AtomicBool { v: 0, nocopy: NonCopyable }; pub static INIT_ATOMIC_INT  : AtomicInt  = AtomicInt  { v: 0, nocopy: NonCopyable }; pub static INIT_ATOMIC_UINT : AtomicUint = AtomicUint { v: 0, nocopy: NonCopyable }; </ins> impl AtomicFlag { pub fn new() -> AtomicFlag { <del> AtomicFlag { v: 0 } </del> <ins> AtomicFlag { v: 0, nocopy: NonCopyable } </ins> } /**
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: impl AtomicBool { pub fn new(v: bool) -> AtomicBool { <del> AtomicBool { v: if v { 1 } else { 0 } } </del> <ins> AtomicBool { v: if v { 1 } else { 0 }, nocopy: NonCopyable } </ins> } #[inline]
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: impl AtomicInt { pub fn new(v: int) -> AtomicInt { <del> AtomicInt { v:v } </del> <ins> AtomicInt { v:v, nocopy: NonCopyable } </ins> } #[inline]
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: impl AtomicUint { pub fn new(v: uint) -> AtomicUint { <del> AtomicUint { v:v } </del> <ins> AtomicUint { v:v, nocopy: NonCopyable } </ins> } #[inline]
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: impl<T> AtomicPtr<T> { pub fn new(p: *mut T) -> AtomicPtr<T> { <del> AtomicPtr { p:p } </del> <ins> AtomicPtr { p:p, nocopy: NonCopyable } </ins> } #[inline]
Code change:
Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating

Related discussion:
text: <ins> // Copyright 2012 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. // Issue #8380 #[feature(globs)]; use std::unstable::atomics::*; use std::ptr; fn main() { let x = INIT_ATOMIC_FLAG; let x = *&x; //~ ERROR: cannot move out of dereference let x = INIT_ATOMIC_BOOL; let x = *&x; //~ ERROR: cannot move out of dereference let x = INIT_ATOMIC_INT; let x = *&x; //~ ERROR: cannot move out of dereference let x = INIT_ATOMIC_UINT; let x = *&x; //~ ERROR: cannot move out of dereference let x: AtomicPtr<uint> = AtomicPtr::new(ptr::mut_null()); let x = *&x; //~ ERROR: cannot move out of dereference let x: AtomicOption<uint> = AtomicOption::empty(); let x = *&x; //~ ERROR: cannot move out of dereference } </ins>
Code change:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

Related discussion:
text: debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(result.normalized_ty) </del> <ins> let res = result.normalized_ty; // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } ty::Projection(data) => {
Code change:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

Related discussion:
text: debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(crate::traits::project::PlaceholderReplacer::replace_placeholders( </del> <ins> let res = crate::traits::project::PlaceholderReplacer::replace_placeholders( </ins> infcx, mapped_regions, mapped_types, mapped_consts, &self.universes, result.normalized_ty, <del> )) </del> <ins> ); // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } _ => ty.try_super_fold_with(self), })()?; self.cache.insert(ty, res); Ok(res) }
Code change:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

Related discussion:
text: <ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait TraitOne { const MY_NUM: usize; type MyErr: std::fmt::Debug; fn do_one_stuff(arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr>; } trait TraitTwo { fn do_two_stuff(); } impl<O: TraitOne> TraitTwo for O where [(); Self::MY_NUM]:, { fn do_two_stuff() { O::do_one_stuff([5; Self::MY_NUM]).unwrap() } } struct Blargotron; #[derive(Debug)] struct ErrTy<const N: usize>([(); N]); impl TraitOne for Blargotron { const MY_NUM: usize = 3; type MyErr = ErrTy<{ Self::MY_NUM }>; fn do_one_stuff(_arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr> { Ok(()) } } fn main() { Blargotron::do_two_stuff(); } </ins>
Code change:
You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:

Related discussion:
text: <ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] use std::convert::AsMut; use std::default::Default; trait Foo: Sized { type Baz: Default + AsMut<[u8]>; fn bar() { Self::Baz::default().as_mut(); } } impl Foo for () { type Baz = [u8; 1 * 1]; //type Baz = [u8; 1]; } fn main() { <() as Foo>::bar(); } </ins>