jiebi/CodeConvo huggingface dataset:
Code change:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.

Related discussion:
text: /// Inserts the given element just after the element most recently returned by `.next()`. /// The inserted element does not appear in the iteration. /// <del> /// # Examples /// /// ``` /// #![feature(linked_list_extras)] /// /// use std::collections::LinkedList; /// /// let mut list: LinkedList<_> = vec![1, 3, 4].into_iter().collect(); /// /// { ///     let mut it = list.iter_mut(); ///     assert_eq!(it.next().unwrap(), &1); ///     // insert `2` after `1` ///     it.insert_next(2); /// } /// { ///     let vec: Vec<_> = list.into_iter().collect(); ///     assert_eq!(vec, [1, 2, 3, 4]); /// } /// ``` </del> <ins> /// This method will be removed soon. </ins> #[inline] #[unstable( feature = "linked_list_extras", reason = "this is probably better handled by a cursor type -- we'll see", issue = "27794" )] <ins> #[rustc_deprecated( reason = "Deprecated in favor of CursorMut methods. This method will be removed soon.", since = "1.47.0" )] </ins> pub fn insert_next(&mut self, element: T) { match self.head { // `push_back` is okay with aliasing `element` references
Code change:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.

Related discussion:
text: /// Provides a reference to the next element, without changing the iterator. /// <del> /// # Examples /// /// ``` /// #![feature(linked_list_extras)] /// /// use std::collections::LinkedList; /// /// let mut list: LinkedList<_> = vec![1, 2, 3].into_iter().collect(); /// /// let mut it = list.iter_mut(); /// assert_eq!(it.next().unwrap(), &1); /// assert_eq!(it.peek_next().unwrap(), &2); /// // We just peeked at 2, so it was not consumed from the iterator. /// assert_eq!(it.next().unwrap(), &2); /// ``` </del> <ins> /// This method will be removed soon. </ins> #[inline] #[unstable( feature = "linked_list_extras", reason = "this is probably better handled by a cursor type -- we'll see", issue = "27794" )] <ins> #[rustc_deprecated( reason = "Deprecated in favor of CursorMut methods. This method will be removed soon.", since = "1.47.0" )] </ins> pub fn peek_next(&mut self) -> Option<&mut T> { if self.len == 0 { None
Code change:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.

Related discussion:
text: } #[test] <del> fn test_insert_prev() { let mut m = list_from(&[0, 2, 4, 6, 8]); let len = m.len(); { let mut it = m.iter_mut(); it.insert_next(-2); loop { match it.next() { None => break, Some(elt) => { it.insert_next(*elt + 1); match it.peek_next() { Some(x) => assert_eq!(*x, *elt + 2), None => assert_eq!(8, *elt), } } } } it.insert_next(0); it.insert_next(1); } check_links(&m); assert_eq!(m.len(), 3 + len * 2); assert_eq!(m.into_iter().collect::<Vec<_>>(), [-2, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1]); } #[test] </del> #[cfg_attr(target_os = "emscripten", ignore)] fn test_send() { let n = list_from(&[1, 2, 3]);
Code change:
Willing to mentor this. Fix is simple, just need to check for . We should also add a run-pass test to ensure that the above code continues to compile. Feel free to ask me if you have further questions!
I've been willing for a long time to start getting involved in some contributions to Rust, so if it's ok for you I would like to give this one a go and make it my first contribution.
Go ahead!

Related discussion:
text: for arg in &fd.inputs { match arg.pat.node { hir::PatIdent(hir::BindByValue(hir::MutImmutable), _, None) => {} <ins> hir::PatWild(_) => {} </ins> _ => { span_err!(self.tcx.sess, arg.pat.span, E0022, "arguments of constant functions can only
Code change:
Willing to mentor this. Fix is simple, just need to check for . We should also add a run-pass test to ensure that the above code continues to compile. Feel free to ask me if you have further questions!
I've been willing for a long time to start getting involved in some contributions to Rust, so if it's ok for you I would like to give this one a go and make it my first contribution.
Go ahead!

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. #![feature(const_fn)] fn main() {} const fn size_ofs(_: usize) {} const fn size_ofs2(_foo: usize) {} </ins>
Code change:
The linkable icon is difficult to . I'm playing with this currently. I'm toying with trying to change the icon from unicode into a svg because unicode has a weird box border shape that doesn't allow the icon to scale to the full box size. I'll put up a PR if I get it working. !

Related discussion:
text: .rusttest { display: none; } pre.rust { position: relative; } <del> .test-arrow { </del> <ins> a.test-arrow { </ins> display: inline-block; position: absolute; <del> top: 0; right: 10px; font-size: 150%; -webkit-transform: scaleX(-1); transform: scaleX(-1); </del> <ins> background-color: #4e8bca; color: #f5f5f5; padding: 5px 10px 5px 10px; border-radius: 5px; font-size: 130%; top: 5px; right: 5px; </ins> } .methods .section-header {
Code change:
The linkable icon is difficult to . I'm playing with this currently. I'm toying with trying to change the icon from unicode into a svg because unicode has a weird box border shape that doesn't allow the icon to scale to the full box size. I'll put up a PR if I get it working. !

Related discussion:
text: } var a = document.createElement('a'); <del> a.textContent = '⇱'; </del> a.setAttribute('class', 'test-arrow'); <ins> a.textContent = 'Run'; </ins> var code = el.previousElementSibling.textContent;
Code change:
I tried this code: I expected to see this happen: "Error: invalid float literal" Instead, this happened: OK: 0 It seems the "leading +" and "leading -" is broken. Further, with i32 and i64 is emits an error but IMO an incorrect one: "cannot parse integer from empty string" I would expect: "Invalid integer literal" : rustc 1.5.0-nightly ( 2015-10-11) binary: rustc commit-hash: commit-date: 2015-10-11 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Oh my, the float part is embarrassing. Preparing a fix right now.
Thanks for taking a look Looks like this is working as expected on stable and has leaked into beta/nightly, so tagging as such.
Yes, this is a bug (not checking for empty strings in the right places) of the dec2flt code. The bug is also in beta, so the PR (which I'll file very soon) should probably be backported to beta.

Related discussion:
text: let s = s.as_bytes(); let (integral, s) = eat_digits(s); match s.first() { <del> None => Valid(Decimal::new(integral, b"", 0)), </del> <ins> None => { if integral.is_empty() { return Invalid; // No digits at all } Valid(Decimal::new(integral, b"", 0)) } </ins> Some(&b'e') | Some(&b'E') => { if integral.is_empty() { return Invalid; // No digits before 'e'
Code change:
I tried this code: I expected to see this happen: "Error: invalid float literal" Instead, this happened: OK: 0 It seems the "leading +" and "leading -" is broken. Further, with i32 and i64 is emits an error but IMO an incorrect one: "cannot parse integer from empty string" I would expect: "Invalid integer literal" : rustc 1.5.0-nightly ( 2015-10-11) binary: rustc commit-hash: commit-date: 2015-10-11 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Oh my, the float part is embarrassing. Preparing a fix right now.
Thanks for taking a look Looks like this is working as expected on stable and has leaked into beta/nightly, so tagging as such.
Yes, this is a bug (not checking for empty strings in the right places) of the dec2flt code. The bug is also in beta, so the PR (which I'll file very soon) should probably be backported to beta.

Related discussion:
text: } #[test] <ins> fn lonely_sign() { assert!("+".parse::<f32>().is_err()); assert!("-".parse::<f64>().is_err()); } #[test] fn whitespace() { assert!(" 1.0".parse::<f32>().is_err()); assert!("1.0 ".parse::<f64>().is_err()); } #[test] </ins> fn nan() { assert!("NaN".parse::<f32>().unwrap().is_nan()); assert!("NaN".parse::<f64>().unwrap().is_nan());
Code change:
Playpen: Code like that puts a unicode character in a byte literal gets a confusing error message: A lot of people read this as if the part after the colon is in reference to "use a xHH escape", so it should show an example of that, but it really is just displaying the char that is in error, though somewhat obfuscated by using the codepoint instead of the actual char.
I agree. As someone unfamiliar with the language the error message lead me to fix the playpen code like this: fn main() { b'u{2192}' } Which leads to: error: unicode escape sequences cannot be used as a byte or in a byte string

Related discussion:
text: _ => { if ascii_only && first_source_char > 'x7F' { let last_pos = self.last_pos; <del> self.err_span_char(start, last_pos, "byte constant must be ASCII. Use a xHH escape for a  non-ASCII byte", first_source_char); </del> <ins> self.err_span_(start, last_pos, "byte constant must be ASCII. Use a xHH escape for a  non-ASCII byte"); </ins> return false; } }
Code change:
The message for E0139 suggests replacing with . Actually performing such a replacement will result in double drops, since the version consumes but the version does not. (It presumably needs a or something.)

Related discussion:
text: ``` ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType` ``` <ins> Note that this does not move `v` (unlike `transmute`), and may need a call to `mem::forget(v)` in case you want to avoid destructors being called. </ins> "##, E0152: r##"
Code change:
The first example
Thanks, these are hard to keep in sync, as they don't get automated testing :/

Related discussion:
text: fn expand_rn(cx: &mut ExtCtxt, sp: Span, args: &[TokenTree]) -> Box<MacResult + 'static> { <del> static NUMERALS: &'static [(&'static str, u32)] = &[ </del> <ins> static NUMERALS: &'static [(&'static str, usize)] = &[ </ins> ("M", 1000), ("CM", 900), ("D", 500), ("CD", 400), ("C",  100), ("XC",  90), ("L",  50), ("XL",  40), ("X",   10), ("IX",   9), ("V",   5), ("IV",   4), ("I",    1)]; <del> let text = match args { [TokenTree::Token(_, token::Ident(s, _))] => s.to_string(), </del> <ins> if args.len() != 1 { cx.span_err( sp, &format!("argument should be a single identifier, but got {} arguments", args.len())); return DummyResult::any(sp); } let text = match args[0] { TokenTree::Token(_, token::Ident(s, _)) => s.to_string(), </ins> _ => { cx.span_err(sp, "argument should be a single identifier"); return DummyResult::any(sp);
Code change:
The first example
Thanks, these are hard to keep in sync, as they don't get automated testing :/

Related discussion:
text: ("X",   10), ("IX",   9), ("V",   5), ("IV",   4), ("I",    1)]; <del> let text = match args { [TokenTree::Token(_, token::Ident(s, _))] => s.to_string(), </del> <ins> if args.len() != 1 { cx.span_err( sp, &format!("argument should be a single identifier, but got {} arguments", args.len())); return DummyResult::any(sp); } let text = match args[0] { TokenTree::Token(_, token::Ident(s, _)) => s.to_string(), </ins> _ => { cx.span_err(sp, "argument should be a single identifier"); return DummyResult::any(sp);
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

Related discussion:
text: let path = match def.full_def() { def::DefStruct(def_id) => def_to_path(tcx, def_id), def::DefVariant(_, variant_did, _) => def_to_path(tcx, variant_did), <ins> def::DefFn(..) => return P(hir::Pat { id: expr.id, node: hir::PatLit(P(expr.clone())), span: span, }), </ins> _ => unreachable!() }; let pats = args.iter().map(|expr| const_expr_to_pat(tcx, &**expr, span)).collect();
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

Related discussion:
text: _ => signal!(e, NonConstPath), }, Some(ast_map::NodeTraitItem(..)) => signal!(e, NonConstPath), <del> Some(_) => unimplemented!(), </del> <ins> Some(_) => signal!(e, UnimplementedConstVal("calling struct, tuple or variant")), </ins> } }
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

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. #![feature(const_fn)] enum Cake { BlackForest, Marmor, } use Cake::*; const BOO: (Cake, Cake) = (Marmor, BlackForest); //~^ ERROR: constant evaluation error: non-constant path in constant expression [E0471] const FOO: Cake = BOO.1; const fn foo() -> Cake { Marmor //~ ERROR: constant evaluation error: non-constant path in constant expression [E0471] //~^ ERROR: non-constant path in constant expression } const WORKS: Cake = Marmor; const GOO: Cake = foo(); fn main() { match BlackForest { FOO => println!("hi"), //~ NOTE: in pattern here GOO => println!("meh"), //~ NOTE: in pattern here WORKS => println!("möp"), _ => println!("bye"), } } </ins>
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

Related discussion:
text: <del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(const_fn)] </ins> const FOO: isize = 10; const BAR: isize = 3; <ins> const fn foo() -> isize { 4 } const BOO: isize = foo(); </ins> pub fn main() { let x: isize = 3; let y = match x { FOO => 1, BAR => 2, <ins> BOO => 4, </ins> _ => 3 }; assert_eq!(y, 2);
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

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. #![feature(const_fn)] const fn f() -> usize { 5 } struct A { field: usize, } fn main() { let _ = [0; f()]; } </ins>
Code change:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

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. #![feature(const_fn)] struct A { field: usize, } const fn f() -> usize { 5 } fn main() { let _ = [0; f()]; } </ins>
Code change:
The macros chapter says: However the second sentence isn't true. is either nothing or a path with one and one identifier. That is, this pair of macros doesn't work, either when called from within the crate or from another one:

Related discussion:
text: function name will expand to either `::increment` or `::mylib::increment`. To keep this system simple and correct, `#[macro_use] extern crate ...` may <del> only appear at the root of your crate, not inside `mod`. This ensures that `$crate` is a single identifier. </del> <ins> only appear at the root of your crate, not inside `mod`. </ins> # The deep end