jiebi/CodeConvo huggingface dataset:
Code change:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.

Related discussion:
text: use fmt; use hash::{Hash, self}; use iter::IntoIterator; <del> use marker::{Sized, Unsize}; </del> <ins> use marker::{Copy, Sized, Unsize}; </ins> use option::Option; use slice::{Iter, IterMut, SliceExt};
Code change:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.

Related discussion:
text: } #[stable(feature = "rust1", since = "1.0.0")] <ins> impl<T:Copy> Clone for [T; $N] { fn clone(&self) -> [T; $N] { *self } } #[stable(feature = "rust1", since = "1.0.0")] </ins> impl<T: Hash> Hash for [T; $N] { fn hash<H: hash::Hasher>(&self, state: &mut H) { Hash::hash(&self[..], state)
Code change:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.

Related discussion:
text: } array_impl_default!{32, T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T} <del> macro_rules! array_impl_clone { {$n:expr, $i:expr, $($idx:expr,)*} => { #[stable(feature = "rust1", since = "1.0.0")] impl<T: Clone> Clone for [T; $n] { fn clone(&self) -> [T; $n] { [self[$i-$i].clone(), $(self[$i-$idx].clone()),*] } } array_impl_clone!{$i, $($idx,)*} }; {$n:expr,} => { #[stable(feature = "rust1", since = "1.0.0")] impl<T: Clone> Clone for [T; 0] { fn clone(&self) -> [T; 0] { [] } } }; } array_impl_clone! { 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9,  8,  7,  6,  5,  4,  3,  2,  1,  0, } </del>
Code change:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.

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. // test for issue #30244 #[derive(Copy, Clone)] struct Array { arr: [[u8; 256]; 4] } pub fn main() {} </ins>
Code change:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")

Related discussion:
text: use self::Destination::*; <del> use codemap::{self, COMMAND_LINE_SP, COMMAND_LINE_EXPN, Pos, Span}; </del> <ins> use codemap::{self, COMMAND_LINE_SP, COMMAND_LINE_EXPN, DUMMY_SP, Pos, Span}; </ins> use diagnostics; use errors::{Level, RenderSpan, DiagnosticBuilder};
Code change:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")

Related discussion:
text: lvl: Level) { let error = match sp { Some(COMMAND_LINE_SP) => self.emit_(FileLine(COMMAND_LINE_SP), msg, code, lvl), <ins> Some(DUMMY_SP) | None => print_diagnostic(&mut self.dst, "", lvl, msg, code), </ins> Some(sp) => self.emit_(FullSpan(sp), msg, code, lvl), <del> None => print_diagnostic(&mut self.dst, "", lvl, msg, code), </del> }; if let Err(e) = error {
Code change:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")

Related discussion:
text: ex = ExprBreak(None); } hi = self.last_span.hi; <ins> } else if self.token.is_keyword(keywords::Let) { // Catch this syntax error here, instead of in `check_strict_keywords`, so // that we can explicitly mention that let is not to be used as an expression let mut db = self.fatal("expected expression, found statement (`let`)"); db.note("variable declaration using `let` is a statement"); return Err(db); </ins> } else if self.check(&token::ModSep) || self.token.is_ident() && !self.check_keyword(keywords::True) &&
Code change:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")

Related discussion:
text: // ignore-cross-compile <del> // error-pattern:expected identifier, found keyword `let` </del> <ins> // error-pattern:expected expression, found statement (`let`) </ins> #![feature(quote, rustc_private)]
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: } } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<T> fmt::Debug for Sender<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Sender {{ .. }}") } } </ins> //////////////////////////////////////////////////////////////////////////////// // SyncSender ////////////////////////////////////////////////////////////////////////////////
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: } } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<T> fmt::Debug for SyncSender<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "SyncSender {{ .. }}") } } </ins> //////////////////////////////////////////////////////////////////////////////// // Receiver ////////////////////////////////////////////////////////////////////////////////
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: } } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<T> fmt::Debug for Receiver<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Receiver {{ .. }}") } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<T> fmt::Debug for SendError<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: repro() } } <ins> #[test] fn fmt_debug_sender() { let (tx, _) = channel::<i32>(); assert_eq!(format!("{:?}", tx), "Sender { .. }"); } #[test] fn fmt_debug_recv() { let (_, rx) = channel::<i32>(); assert_eq!(format!("{:?}", rx), "Receiver { .. }"); } #[test] fn fmt_debug_sync_sender() { let (tx, _) = sync_channel::<i32>(1); assert_eq!(format!("{:?}", tx), "SyncSender { .. }"); } </ins> }
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: issue = "27800")] <ins> use fmt; </ins> use core::cell::{Cell, UnsafeCell}; use core::marker; use core::ptr;
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: } } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl fmt::Debug for Select { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Select {{ .. }}") } } #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<'rx, T:Send+'rx> fmt::Debug for Handle<'rx, T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Handle {{ .. }}") } } </ins> #[cfg(test)] #[allow(unused_imports)] mod tests {
Code change:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.

Related discussion:
text: } } } <ins> #[test] fn fmt_debug_select() { let sel = Select::new(); assert_eq!(format!("{:?}", sel), "Select { .. }"); } #[test] fn fmt_debug_handle() { let (_, rx) = channel::<i32>(); let sel = Select::new(); let mut handle = sel.handle(&rx); assert_eq!(format!("{:?}", handle), "Handle { .. }"); } </ins> }
Code change:
Code like the following one generates some unnecessary LLVM IR. Namely: We should skip zero-sized fields in .

Related discussion:
text: operand: OperandRef<'tcx>) { debug!("store_operand: operand={}", operand.repr(bcx)); <ins> // Avoid generating stores of zero-sized values, because the only way to have a zero-sized // value is through `undef`, and store itself is useless. if common::type_is_zero_size(bcx.ccx(), operand.ty) { return; } </ins> match operand.val { OperandValue::Ref(r) => base::memcpy_ty(bcx, lldest, r, operand.ty), OperandValue::Immediate(s) => base::store_ty(bcx, s, lldest, operand.ty),
Code change:
Code like the following one generates some unnecessary LLVM IR. Namely: We should skip zero-sized fields in .

Related discussion:
text: }, _ => { for (i, operand) in operands.iter().enumerate() { <del> // Note: perhaps this should be StructGep, but // note that in some cases the values here will // not be structs but arrays. let lldest_i = build::GEPi(bcx, dest.llval, &[0, i]); self.trans_operand_into(bcx, lldest_i, operand); </del> <ins> let op = self.trans_operand(bcx, operand); // Do not generate stores and GEPis for zero-sized fields. if !common::type_is_zero_size(bcx.ccx(), op.ty) { // Note: perhaps this should be StructGep, but // note that in some cases the values here will // not be structs but arrays. let dest = build::GEPi(bcx, dest.llval, &[0, i]); self.store_operand(bcx, dest, op); } </ins> } } }
Code change:
Code like the following one generates some unnecessary LLVM IR. Namely: We should skip zero-sized fields in .

Related discussion:
text: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -C no-prepopulate-passes #![feature(rustc_attrs)] #![crate_type = "lib"] use std::marker::PhantomData; struct Zst { phantom: PhantomData<Zst> } // CHECK-LABEL: @mir #[no_mangle] #[rustc_mir] fn mir(){ // CHECK-NOT: getelementptr // CHECK-NOT: store{{.*}}undef let x = Zst { phantom: PhantomData }; } </ins>
Code change:
As , if one of the stdio handles for a Windows process is unset (e.g. isn't present) then you won't actually be able to spawn a process by default. All handles are set, by default, to "inherit", but duplicate the existing handle, which in turn means that if the stdio handle isn't present this operation will fail. Rust currently by always opening up handles even if is specified (just pointing them to a blank stream), but Rust should also defend against this situation when it was spawned from elsewhere.
cc

Related discussion:
text: impl<R: io::Read> io::Read for Maybe<R> { fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { match *self { <del> Maybe::Real(ref mut r) => handle_ebadf(r.read(buf), buf.len()), </del> <ins> Maybe::Real(ref mut r) => handle_ebadf(r.read(buf), 0), </ins> Maybe::Fake => Ok(0) } }
Code change:
As , if one of the stdio handles for a Windows process is unset (e.g. isn't present) then you won't actually be able to spawn a process by default. All handles are set, by default, to "inherit", but duplicate the existing handle, which in turn means that if the stdio handle isn't present this operation will fail. Rust currently by always opening up handles even if is specified (just pointing them to a blank stream), but Rust should also defend against this situation when it was spawned from elsewhere.
cc

Related discussion:
text: impl Stdio { fn to_handle(&self, stdio_id: c::DWORD) -> io::Result<Handle> { match *self { <ins> // If no stdio handle is available, then inherit means that it // should still be unavailable so propagate the // INVALID_HANDLE_VALUE. </ins> Stdio::Inherit => { <del> stdio::get(stdio_id).and_then(|io| { io.handle().duplicate(0, true, c::DUPLICATE_SAME_ACCESS) }) </del> <ins> match stdio::get(stdio_id) { Ok(io) => io.handle().duplicate(0, true, c::DUPLICATE_SAME_ACCESS), Err(..) => Ok(Handle::new(c::INVALID_HANDLE_VALUE)), } </ins> } Stdio::Raw(handle) => { RawHandle::new(handle).duplicate(0, true, c::DUPLICATE_SAME_ACCESS)
Code change:
I am following the Book in the Getting Started chapter, try my first rustc and get the error: The manual should at least mention the need for a C compiler (or at least a linker) as a dependency if you are using to install the binaries.

Related discussion:
text: repair, or remove installation" page and ensure "Add to PATH" is installed on the local hard drive. <ins> Rust does not do its own linking, and so you’ll need to have a linker installed. Doing so will depend on your specific system, consult its documentation for more details. </ins> If not, there are a number of places where we can get help. The easiest is [the #rust IRC channel on irc.mozilla.org][irc], which we can access through [Mibbit][mibbit]. Click that link, and we'll be chatting with other Rustaceans
Code change:
Brand new to Rust so I apologize if this is not the right place for something like this. I just finished "The Guessing Game" and noticed a small typo: We can do that with three more lines. Here’s our new program: The new three lines: It appears the book was updated at some point to only contain two lines. Similarly. in the following section. this could be a typo or possibly just confusing: If we leave off calling these two methods, our program will compile, but we’ll get a warning: The two methods could refer to .expect and panic!.
Nope, this is a typo. There used to be calls to in there, and they were removed, but the English wasn't.

Related discussion:
text: [expect]: ../std/option/enum.Option.html#method.expect [panic]: error-handling.html <del> If we leave off calling these two methods, our program will compile, but </del> <ins> If we leave off calling this method, our program will compile, but </ins> we’ll get a warning: ```bash
Code change:
Brand new to Rust so I apologize if this is not the right place for something like this. I just finished "The Guessing Game" and noticed a small typo: We can do that with three more lines. Here’s our new program: The new three lines: It appears the book was updated at some point to only contain two lines. Similarly. in the following section. this could be a typo or possibly just confusing: If we leave off calling these two methods, our program will compile, but we’ll get a warning: The two methods could refer to .expect and panic!.
Nope, this is a typo. There used to be calls to in there, and they were removed, but the English wasn't.

Related discussion:
text: } ``` <del> The new three lines: </del> <ins> The new two lines: </ins> ```rust,ignore let guess: u32 = guess.trim().parse()