jiebi/CodeConvo huggingface dataset:
Code change:
As it is currently written, E0207 talks entirely about type parameters. Now that const parameters also need to constrain implementations (under the same rules described for types), they also need to be mentioned in the error explanation. Since other items don't require const parameters to be used at all, we might also want to specifically call out this difference here. Furthermore, E0207 triggers if you use an unconstrained lifetime in an associated type, and this is completely unspecified by the error as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: (`Foo`) of the impl. In this case, we can fix the error by moving the type parameter from the `impl` to the method `get`: ``` struct Foo;
Code change:
As it is currently written, E0207 talks entirely about type parameters. Now that const parameters also need to constrain implementations (under the same rules described for types), they also need to be mentioned in the error explanation. Since other items don't require const parameters to be used at all, we might also want to specifically call out this difference here. Furthermore, E0207 triggers if you use an unconstrained lifetime in an associated type, and this is completely unspecified by the error as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: } ``` <ins> ### Error example 3 Suppose we have a struct `Foo` and we would like to define some methods for it. The following code example has a definition which leads to a compiler error: ```compile_fail,E0207 struct Foo; impl<const T: i32> Foo { // error: the const parameter `T` is not constrained by the impl trait, self // type, or predicates [E0207] fn get(&self) -> i32 { i32::default() } } ``` The problem is that the const parameter `T` does not appear in the implementing type (`Foo`) of the impl. In this case, we can fix the error by moving the type parameter from the `impl` to the method `get`: ``` struct Foo; // Move the const parameter from the impl to the method impl Foo { fn get<const T: i32>(&self) -> i32 { i32::default() } } ``` ### Error example 4 Suppose we have a struct `Foo` and a struct `Bar` that uses lifetime `'a`. We would like to implement trait `Contains` for `Foo`. The trait `Contains` have the associated type `B`. The following code example has a definition which leads to a compiler error: ```compile_fail,E0207 struct Foo; struct Bar<'a>; trait Contains { type B; fn get(&self) -> i32; } impl<'a> Contains for Foo { type B = Bar<'a>; // error: the lifetime parameter `'a` is not constrained by the impl trait, // self type, or predicates [E0207] fn get(&self) -> i32 { i32::default() } } ``` Please note that unconstrained lifetime parameters are not supported if they are being used by an associated type. </ins> ### Additional information For more information, please see [RFC 447].
Code change:
The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)

Related discussion:
text: ); } else { // Trivial case: `T` needs an extra bound: `T: Bound`. <del> let (sp, suggestion) = match super_traits { None => predicate_constraint( </del> <ins> let (sp, suggestion) = match ( generics .params .iter() .filter( |p| !matches!(p.kind, hir::GenericParamKind::Type { synthetic: Some(_), ..}), ) .next(), super_traits, ) { (_, None) => predicate_constraint( </ins> generics, trait_ref.without_const().to_predicate(tcx).to_string(), ), <del> Some((ident, bounds)) => match bounds { [.., bound] => ( bound.span().shrink_to_hi(), format!(" + {}", trait_ref.print_only_trait_path().to_string()), ), [] => ( ident.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), }, </del> <ins> (None, Some((ident, []))) => ( ident.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), (_, Some((_, [.., bounds]))) => ( bounds.span().shrink_to_hi(), format!(" + {}", trait_ref.print_only_trait_path().to_string()), ), (Some(_), Some((_, []))) => ( generics.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), </ins> }; err.span_suggestion_verbose(
Code change:
The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)

Related discussion:
text: //~^ ERROR doesn't implement } <del> pub fn main() { } </del> <ins> trait Foo<T>: Sized { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bar: std::fmt::Display + Sized { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Baz: Sized where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Qux<T>: Sized where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bat<T>: std::fmt::Display + Sized { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } fn main() { } </ins>
Code change:
The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)

Related discussion:
text: //~^ ERROR doesn't implement } <del> pub fn main() { } </del> <ins> trait Foo<T> { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bar: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Baz where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Qux<T> where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bat<T>: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } fn main() { } </ins>
Code change:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

Related discussion:
text: .iter() .enumerate() .map(|(i, ty)| Argument { <del> name: Symbol::intern(&rustc_hir_pretty::param_to_string(&body.params[i])), </del> <ins> name: name_from_pat(&body.params[i].pat), </ins> type_: ty.clean(cx), }) .collect(),
Code change:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

Related discussion:
text: Path { global: path.global, res: path.res, segments } } <ins> crate fn qpath_to_string(p: &hir::QPath<'_>) -> String { let segments = match *p { hir::QPath::Resolved(_, ref path) => &path.segments, hir::QPath::TypeRelative(_, ref segment) => return segment.ident.to_string(), hir::QPath::LangItem(lang_item, ..) => return lang_item.name().to_string(), }; let mut s = String::new(); for (i, seg) in segments.iter().enumerate() { if i > 0 { s.push_str("::"); } if seg.ident.name != kw::PathRoot { s.push_str(&seg.ident.as_str()); } } s } </ins> crate fn build_deref_target_impls(cx: &DocContext<'_>, items: &[Item], ret: &mut Vec<Item>) { let tcx = cx.tcx;
Code change:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

Related discussion:
text: } } <ins> crate fn name_from_pat(p: &hir::Pat<'_>) -> Symbol { use rustc_hir::*; debug!("trying to get a name from pattern: {:?}", p); Symbol::intern(&match p.kind { PatKind::Wild => return kw::Underscore, PatKind::Binding(_, _, ident, _) => return ident.name, PatKind::TupleStruct(ref p, ..) | PatKind::Path(ref p) => qpath_to_string(p), PatKind::Struct(ref name, ref fields, etc) => format!( "{} {{ {}{} }}", qpath_to_string(name), fields .iter() .map(|fp| format!("{}: {}", fp.ident, name_from_pat(&fp.pat))) .collect::<Vec<String>>() .join(", "), if etc { ", .." } else { "" } ), PatKind::Or(ref pats) => pats .iter() .map(|p| name_from_pat(&**p).to_string()) .collect::<Vec<String>>() .join(" | "), PatKind::Tuple(ref elts, _) => format!( "({})", elts.iter() .map(|p| name_from_pat(&**p).to_string()) .collect::<Vec<String>>() .join(", ") ), PatKind::Box(ref p) => return name_from_pat(&**p), PatKind::Ref(ref p, _) => return name_from_pat(&**p), PatKind::Lit(..) => { warn!( "tried to get argument name from PatKind::Lit, which is silly in function arguments" ); return Symbol::intern("()"); } PatKind::Range(..) => return kw::Underscore, PatKind::Slice(ref begin, ref mid, ref end) => { let begin = begin.iter().map(|p| name_from_pat(&**p).to_string()); let mid = mid.as_ref().map(|p| format!("..{}", name_from_pat(&**p))).into_iter(); let end = end.iter().map(|p| name_from_pat(&**p).to_string()); format!("[{}]", begin.chain(mid).chain(end).collect::<Vec<_>>().join(", ")) } }) } </ins> crate fn print_const(cx: &DocContext<'_>, n: &'tcx ty::Const<'_>) -> String { match n.val { ty::ConstKind::Unevaluated(def, _, promoted) => {
Code change:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

Related discussion:
text: <ins> // Rustdoc shouldn't display `mut` in function arguments, which are // implementation details. Regression test for #81289. #![crate_name = "foo"] pub struct Foo; // @count foo/struct.Foo.html '//*[@class="impl-items"]//*[@class="method"]' 2 // @!has - '//*[@class="impl-items"]//*[@class="method"]' 'mut' impl Foo { pub fn foo(mut self) {} pub fn bar(mut bar: ()) {} } // @count foo/fn.baz.html '//*[@class="rust fn"]' 1 // @!has - '//*[@class="rust fn"]' 'mut' pub fn baz(mut foo: Foo) {} </ins>
Code change:
Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)

Related discussion:
text: #![crate_name = "foo"] // @has foo/fn.f.html <del> // @has - '//*[@class="rust fn"]' 'pub fn f(0u8 ...255: u8)' </del> <ins> // @has - '//*[@class="rust fn"]' 'pub fn f(_: u8)' </ins> pub fn f(0u8...255: u8) {}
Code change:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc

Related discussion:
text: use crate::{lang_items, LangItem, LanguageItems}; use rustc_ast as ast; <del> use rustc_data_structures::fx::FxHashMap; </del> <ins> use rustc_data_structures::stable_map::StableMap; </ins> use rustc_span::symbol::{sym, Symbol}; use std::lazy::SyncLazy;
Code change:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc

Related discussion:
text: macro_rules! weak_lang_items { ($($name:ident, $item:ident, $sym:ident;)*) => ( <del> pub static WEAK_ITEMS_REFS: SyncLazy<FxHashMap<Symbol, LangItem>> = SyncLazy::new(|| { let mut map = FxHashMap::default(); </del> <ins> pub static WEAK_ITEMS_REFS: SyncLazy<StableMap<Symbol, LangItem>> = SyncLazy::new(|| { let mut map = StableMap::default(); </ins> $(map.insert(sym::$name, LangItem::$item);)* map });
Code change:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc

Related discussion:
text: } } <del> for (name, &item) in WEAK_ITEMS_REFS.iter() { </del> <ins> for (name, item) in WEAK_ITEMS_REFS.clone().into_sorted_vector().into_iter() { </ins> if missing.contains(&item) && required(tcx, item) && items.require(item).is_err() { if item == LangItem::PanicImpl { tcx.sess.err("`#[panic_handler]` function required, but not found");
Code change:
The following comment causes a panic in jsondocck currently: Expected: Pretty error like 'Invalid split pattern on line X' Current: Giant stack trace, only obvious if you know what that line is doing. Opening this for tracking and so I don't forget to fix it <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (since you said "so I don't forget to fix it")

Related discussion:
text: } } <del> let args = cap.name("args").map_or(vec![], |m| shlex::split(m.as_str()).unwrap()); </del> <ins> let args = cap.name("args").map_or(Some(vec![]), |m| shlex::split(m.as_str())); let args = match args { Some(args) => args, None => { print_err( &format!( "Invalid arguments to shlex::split: `{}`", cap.name("args").unwrap().as_str() ), lineno, ); errors = true; continue; } }; </ins> if !cmd.validate(&args, commands.len(), lineno) { errors = true;
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Original: Minimized: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 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: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

Related discussion:
text: "deref-methods-{:#}", type_.print(cx.cache()) ))); <ins> debug!("Adding {} to deref id map", type_.print(cx.cache())); </ins> cx.deref_id_map .borrow_mut() .insert(type_.def_id_full(cx.cache()).unwrap(), id.clone());
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Original: Minimized: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 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: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.

Related discussion:
text: _ => None, }) .expect("Expected associated type binding"); <ins> debug!("Render deref methods for {:#?}, target {:#?}", impl_.inner_impl().for_, target); </ins> let what = AssocItemRender::DerefFor { trait_: deref_type, type_: real_target, deref_mut_: deref_mut }; if let Some(did) = target.def_id_full(cx.cache()) {