jiebi/CodeConvo huggingface dataset:
Code change:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.

Related discussion:
text: span: codemap::Span) -> IoResult<()> { try!(self.print_ident(ident)); try!(self.print_generics(generics)); <del> try!(self.print_where_clause(generics)); </del> if ast_util::struct_def_is_tuple_like(struct_def) { if !struct_def.fields.is_empty() { try!(self.popen());
Code change:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.

Related discussion:
text: )); try!(self.pclose()); } <ins> try!(self.print_where_clause(generics)); </ins> try!(word(&mut self.s, ";")); try!(self.end()); self.end() // close the outer-box } else { <ins> try!(self.print_where_clause(generics)); </ins> try!(self.nbsp()); try!(self.bopen()); try!(self.hardbreak_if_not_bol());
Code change:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.

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. struct Baz<U> where U: Eq(U); //This is parsed as the new Fn* style parenthesis syntax. struct Baz<U> where U: Eq(U) -> R; // Notice this parses as well. struct Baz<U>(U) where U: Eq; // This rightfully signals no error as well. struct Foo<T> where T: Copy, (T); //~ ERROR unexpected token in `where` clause struct Bar<T> { x: T } where T: Copy //~ ERROR expected item, found `where` fn main() {} </ins>
Code change:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.

Related discussion:
text: // Test syntax checks for `type` keyword. <del> struct S1 for type; //~ ERROR expected `{`, `(`, or `;` after struct name, found `for` </del> <ins> struct S1 for type; //~ ERROR expected `where`, `{`, `(`, or `;` after struct name, found `for` </ins> pub fn main() { }
Code change:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.

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. struct Foo<T> where T: Copy; struct Bar<T>(T) where T: Copy; struct Bleh<T, U>(T, U) where T: Copy, U: Sized; struct Baz<T> where T: Copy { field: T } fn main() {} </ins>
Code change:
This should say Undefinedfn foo() -Undefined {}` does.
triage: still true today
As of the error is I will add a regression test so this issue can be closed.

Related discussion:
text: <ins> // Copyright 2015 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. impl Undefined {} //~^ ERROR use of undeclared type name `Undefined` fn main() {} </ins>
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: AssignmentLhsSized,        // L = X implies that L is Sized StructInitializerSized,    // S { ... } must be Sized VariableType(ast::NodeId), // Type of each variable must be Sized <ins> ReturnType,                // Return type must be Sized </ins> RepeatVec,                 // [T,..n] --> T must be Copy // Captures of variable the given id by a closure (span is the
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: // Remember return type so that regionck can access it later. let fn_sig_tys: Vec<ty::t> = <del> arg_tys.iter() .chain([ret_ty].iter()) .map(|&ty| ty) .collect(); </del> <ins> arg_tys.iter().chain([ret_ty].iter()).map(|&ty| ty).collect(); </ins> debug!("fn-sig-map: fn_id={} fn_sig_tys={}", fn_id, fn_sig_tys.repr(tcx)); <del> inherited.fn_sig_map .borrow_mut() .insert(fn_id, fn_sig_tys); </del> <ins> inherited.fn_sig_map.borrow_mut().insert(fn_id, fn_sig_tys); </ins> { let mut visit = GatherLocalsVisitor { fcx: &fcx, };
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: visit.visit_block(body); } <ins> fcx.require_type_is_sized(ret_ty, decl.output.span, traits::ReturnType); </ins> check_block_with_expected(&fcx, body, ExpectHasType(ret_ty));
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: traits::RepeatVec => { tcx.sess.span_note( obligation.cause.span, <del> format!( "the `Copy` trait is required because the  repeated element will be copied").as_slice()); </del> <ins> "the `Copy` trait is required because the  repeated element will be copied"); </ins> } traits::VariableType(_) => { tcx.sess.span_note( obligation.cause.span, "all local variables must have a statically known size"); } <ins> traits::ReturnType => { tcx.sess.span_note( obligation.cause.span, "the return type of a function must have a  statically known size"); } </ins> traits::AssignmentLhsSized => { tcx.sess.span_note( obligation.cause.span,
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: #![no_std] #![feature(lang_items)] <ins> #[lang="sized"] pub trait Sized for Sized? {} </ins> #[lang="fail"] fn fail(_: &(&'static str, &'static str, uint)) -> ! { loop {} }
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: C([Box<A>]), } <del> fn c(c:char) -> A { B(c) //~ ERROR cannot move a value of type A: the size of A cannot be statically determined </del> <ins> fn c(c:char) { B(c); //~^ ERROR cannot move a value of type A: the size of A cannot be statically determined </ins> } pub fn main() {}
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

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. pub trait AbstractRenderer {} fn _create_render(_: &()) -> AbstractRenderer //~^ ERROR: the trait `core::kinds::Sized` is not implemented { match 0u { _ => unimplemented!() } } fn main() { } </ins>
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: r: A+'static } <del> fn new_struct(r: A+'static) -> Struct { </del> <ins> fn new_struct(r: A+'static) -> Struct { //~^  ERROR the trait `core::kinds::Sized` is not implemented </ins> //~^ ERROR the trait `core::kinds::Sized` is not implemented Struct { r: r } //~^ ERROR the trait `core::kinds::Sized` is not implemented
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(globs)] </del> <ins> #![feature(globs, lang_items)] </ins> #![no_std] // makes debugging this test *a lot* easier (during resolve) <ins> #[lang = "sized"] pub trait Sized for Sized? {} </ins> // Test to make sure that private items imported through globs remain private // when  they're used.
Code change:
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(lang_items)] </ins> #![no_std] <ins> #[lang="sized"] pub trait Sized for Sized? {} </ins> // error-pattern:requires `start` lang_item fn main() {}
Code change:
There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use

Related discussion:
text: #[inline] unsafe fn into_ascii_nocheck(self) -> Vec<Ascii> { <del> let v: Vec<u8> = mem::transmute(self); v.into_ascii_nocheck() </del> <ins> self.into_bytes().into_ascii_nocheck() </ins> } }
Code change:
There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use

Related discussion:
text: #[inline] unsafe fn into_ascii_nocheck(self) -> Vec<Ascii> { <del> mem::transmute(self) </del> <ins> let v = Vec::from_raw_parts(self.len(), self.capacity(), mem::transmute(self.as_ptr())); // We forget `self` to avoid freeing it at the end of the scope // Otherwise, the returned `Vec` would point to freed memory mem::forget(self); v </ins> } }
Code change:
There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use

Related discussion:
text: impl IntoBytes for Vec<Ascii> { fn into_bytes(self) -> Vec<u8> { <del> unsafe { mem::transmute(self) } </del> <ins> unsafe { let v = Vec::from_raw_parts(self.len(), self.capacity(), mem::transmute(self.as_ptr())); // We forget `self` to avoid freeing it at the end of the scope // Otherwise, the returned `Vec` would point to freed memory mem::forget(self); v } </ins> } }
Code change:
On the latest nightly (previously it worked fine) Rust fails to compile this code: It emits this error message: I managed to strip it down to this example: It fails to compile with this error: If is replaced with , then it compiles fine, so the error seems to be related to matching on s.
Sorry for the breakage, fix on its way.

Related discussion:
text: let const_did = tcx.def_map.borrow().get_copy(&pat.id).def_id(); let const_pty = ty::lookup_item_type(tcx, const_did); fcx.write_ty(pat.id, const_pty.ty); <del> demand::eqtype(fcx, pat.span, expected, const_pty.ty); </del> <ins> demand::suptype(fcx, pat.span, expected, const_pty.ty); </ins> } ast::PatIdent(bm, ref path, ref sub) if pat_is_binding(&tcx.def_map, pat) => { let typ = fcx.local_ty(pat.span, pat.id);
Code change:
On the latest nightly (previously it worked fine) Rust fails to compile this code: It emits this error message: I managed to strip it down to this example: It fails to compile with this error: If is replaced with , then it compiles fine, so the error seems to be related to matching on s.
Sorry for the breakage, fix on its way.

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. const X: &'static str = "12345"; fn test(s: String) -> bool { match s.as_slice() { X => true, _ => false } } fn main() { assert!(test("12345".to_string())); } </ins>
Code change:
Right now the Int and Integer traits imply PartialOrd but not Ord. Is there a reason for this? It seems like integers do have a total order, not just partial. I asked on IRC and people seemed to think Int should imply Ord. If this is correct I can send a pull request?
Yup :)
I have two questions: May I ask what is the trait? Couldn't find any in the std doc: Did you mean  () when you wrote "the trait"? But it doesn't even inherit . Am I missing something?
The trait is in .
Ah, it was the big int code separated from the std lib! Thanks. I also overlooked implemented , implying . Sorry for the noise!

Related discussion:
text: use {uint, u8, u16, u32, u64}; use {f32, f64}; use clone::Clone; <del> use cmp::{PartialEq, PartialOrd}; </del> <ins> use cmp::{Ord, PartialEq, PartialOrd}; </ins> use kinds::Copy; use mem::size_of; use ops::{Add, Sub, Mul, Div, Rem, Neg};
Code change:
Right now the Int and Integer traits imply PartialOrd but not Ord. Is there a reason for this? It seems like integers do have a total order, not just partial. I asked on IRC and people seemed to think Int should imply Ord. If this is correct I can send a pull request?
Yup :)
I have two questions: May I ask what is the trait? Couldn't find any in the std doc: Did you mean  () when you wrote "the trait"? But it doesn't even inherit . Am I missing something?
The trait is in .
Ah, it was the big int code separated from the std lib! Thanks. I also overlooked implemented , implying . Sorry for the noise!

Related discussion:
text: /// A primitive signed or unsigned integer equipped with various bitwise /// operators, bit counting methods, and endian conversion functions. pub trait Int: Primitive <ins> + Ord </ins> + CheckedAdd + CheckedSub + CheckedMul
Code change:
In we had the submitter change a to an as follows: We felt that better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to , which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib). However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code. Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to . It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since still includes a filename and line number in its output. However, given the precedent of optional messages set by , I don't think it would be a stretch to imagine that could also have an optional message. Usage for the typical case would be the same: could optionally look like this:
I'll have a go at implementing this.

Related discussion:
text: /// ``` #[macro_export] macro_rules! unreachable( <del> () => (panic!("internal error: entered unreachable code")) </del> <ins> () => ({ panic!("internal error: entered unreachable code") }); ($msg:expr) => ({ unreachable!("{}", $msg) }); ($fmt:expr, $($arg:tt)*) => ({ panic!(concat!("internal error: entered unreachable code: ", $fmt), $($arg)*) }); </ins> ) /// A standardised placeholder for marking unfinished code. It panics with the