jiebi/CodeConvo huggingface dataset:
Code change:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

Related discussion:
text: let mut rbml_w = Encoder::new(wr); <ins> encode_rustc_version(&mut rbml_w); </ins> encode_crate_name(&mut rbml_w, &ecx.link_meta.crate_name); encode_crate_triple(&mut rbml_w, &tcx.sess.opts.target_triple); encode_hash(&mut rbml_w, &ecx.link_meta.crate_hash);
Code change:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

Related discussion:
text: // can just use the tcx as the typer. // // FIXME(stage0): the :'t here is probably only important for stage0 <del> pub struct ExprUseVisitor<'d, 't, 'a: 't, 'tcx:'a+'d+'t> { </del> <ins> pub struct ExprUseVisitor<'d, 't, 'a: 't, 'tcx:'a+'d> { </ins> typer: &'t infer::InferCtxt<'a, 'tcx>, mc: mc::MemCategorizationContext<'t, 'a, 'tcx>, delegate: &'d mut Delegate<'tcx>,
Code change:
When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata

Related discussion:
text: impl<'d,'t,'a,'tcx> ExprUseVisitor<'d,'t,'a,'tcx> { pub fn new(delegate: &'d mut Delegate<'tcx>, typer: &'t infer::InferCtxt<'a, 'tcx>) <del> -> ExprUseVisitor<'d,'t,'a,'tcx> </del> <ins> -> ExprUseVisitor<'d,'t,'a,'tcx> where 'tcx:'a </ins> { ExprUseVisitor { typer: typer,
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: % Closures <del> Rust not only has named functions, but anonymous functions as well. Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment. Rust has a really great implementation of them, as we’ll see. </del> <ins> Sometimes it is useful to wrap up a function and _free variables_ for better clarity and reuse. The free variables that can be used come from the enclosing scope and are ‘closed over’ when used in the function. From this, we get the name ‘closures’ and Rust provides a really great implementation of them, as we’ll see. </ins> # Syntax
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: ``` You’ll notice a few things about closures that are a bit different from regular <del> functions defined with `fn`. The first is that we did not need to </del> <ins> named functions defined with `fn`. The first is that we did not need to </ins> annotate the types of arguments the closure takes or the values it returns. We can:
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: assert_eq!(2, plus_one(1)); ``` <del> But we don’t have to. Why is this? Basically, it was chosen for ergonomic reasons. While specifying the full type for named functions is helpful with things like documentation and type inference, the types of closures are rarely documented since they’re anonymous, and they don’t cause the kinds of error-at-a-distance problems that inferring named function types can. </del> <ins> But we don’t have to. Why is this? Basically, it was chosen for ergonomic reasons. While specifying the full type for named functions is helpful with things like documentation and type inference, the full type signatures of closures are rarely documented since they’re anonymous, and they don’t cause the kinds of error-at-a-distance problems that inferring named function types can. </ins> <del> The second is that the syntax is similar, but a bit different. I’ve added spaces here for easier comparison: </del> <ins> The second is that the syntax is similar, but a bit different. I’ve added spaces here for easier comparison: </ins> ```rust fn  plus_one_v1   (x: i32) -> i32 { x + 1 }
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: # Closures and their environment <del> Closures are called such because they ‘close over their environment’. It looks like this: </del> <ins> The environment for a closure can include bindings from its enclosing scope in addition to parameters and local bindings. It looks like this: </ins> ```rust let num = 5;
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: it, while a `move` closure is self-contained. This means that you cannot generally return a non-`move` closure from a function, for example. <del> But before we talk about taking and returning closures, we should talk some more about the way that closures are implemented. As a systems language, Rust gives you tons of control over what your code does, and closures are no different. </del> <ins> But before we talk about taking and returning closures, we should talk some more about the way that closures are implemented. As a systems language, Rust gives you tons of control over what your code does, and closures are no different. </ins> # Closure implementation
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: #   some_closure(1) } ``` <del> Because `Fn` is a trait, we can bound our generic with it. In this case, our closure takes a `i32` as an argument and returns an `i32`, and so the generic bound we use is `Fn(i32) -> i32`. </del> <ins> Because `Fn` is a trait, we can bound our generic with it. In this case, our closure takes a `i32` as an argument and returns an `i32`, and so the generic bound we use is `Fn(i32) -> i32`. </ins> There’s one other key point here: because we’re bounding a generic with a trait, this will get monomorphized, and therefore, we’ll be doing static
Code change:
The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this

Related discussion:
text: The error also points out that the return type is expected to be a reference, but what we are trying to return is not. Further, we cannot directly assign a `'static` lifetime to an object. So we'll take a different approach and return <del> a "trait object" by `Box`ing up the `Fn`. This _almost_ works: </del> <ins> a ‘trait object’ by `Box`ing up the `Fn`. This _almost_ works: </ins> ```rust,ignore fn factory() -> Box<Fn(i32) -> i32> {
Code change:
After some discussion about the libs subteam decided that iterator adaptors should always preserve the same semantics in terms of the convenience methods and such. This was not audited for when all the initial specializations landed, so we should take a look and make sure that everything adheres to this policy. Additionally, documentation should be to the trait methods indicating what form of guarantees you are given (e.g. calling is equivalent to exhausting the iterator). triage: I-nominated
I've checked . should exhaust before but that's the only bug I found (and it wasn't my bug for once :tada:). Unless, of course, you care about drop order. I haven't tried to reason about that.
The slice iterators () are fine because they are side-effect free.
and are fine because they are also side-effect free.
I'd appreciate it if someone else double checked but I think that's all of them.
This is relevant as well, because implementations of Drop may also (and usually do, in form of memory deallocation) contain side effects. Can we make a [x] list [x] of iterators which were specialised [x] like this?
I strongly disagree. Drop has side effects but programmers should never rely on drop order except stack drop order because drop order is often unspecified (e.g. within structs). core::iter::Chain::last core::iter::Peekable::last core::iter::Peekable::count (fixable) core::iter::Skip::last (fixable?)[x] core::iter::Chain [x] core::iter::Enumerate [x] core::iter::Peekable [x] core::iter::Skip [x] core::iter::Take [x] core::iter::Fuse [x] core::str::Bytes [x] core::slice::Iter [x] core::slice::IterMut [x] core::slice::Windows [x] core::slice::Chunks [x] core::slice::ChunksMut [x] collections::vec::IntoIter
Ah right, this will be decided by anyway.
Awesome, thanks for the work here
Updated list of out-of-order drops (didn't notice ).
triage: P-medium
(Need to make sure this behavior is documented/explicitly promised.)
Is this done? (Everything in the list above is :whitecheckmark:'d)
I believe this is left open as to-be-documented. Also, I don't see any decision as to whether out of order drop is ok.
re-tagging as docs
So I believe that all of these are then documented in Iterator's methods, at least as far as I can tell. Can someone from libs double check me here and help provide any specifics as to what's not documented?
Looks good to me, thanks

Related discussion:
text: #[inline] fn last(self) -> Option<A::Item> { match self.state { <del> ChainState::Both => self.b.last().or(self.a.last()), </del> <ins> ChainState::Both => { // Must exhaust a before b. let a_last = self.a.last(); let b_last = self.b.last(); b_last.or(a_last) }, </ins> ChainState::Front => self.a.last(), ChainState::Back => self.b.last() }
Code change:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

Related discussion:
text: talk about what you do want instead. There are three broad classes of things that are relevant here: iterators, <del> *iterator adapters*, and *consumers*. Here's some definitions: </del> <ins> *iterator adaptors*, and *consumers*. Here's some definitions: </ins> * *iterators* give you a sequence of values. <del> * *iterator adapters* operate on an iterator, producing a new iterator with a </del> <ins> * *iterator adaptors* operate on an iterator, producing a new iterator with a </ins> different output sequence. * *consumers* operate on an iterator, producing some final set of values.
Code change:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

Related discussion:
text: These two basic iterators should serve you well. There are some more advanced iterators, including ones that are infinite. <del> That's enough about iterators. Iterator adapters are the last concept </del> <ins> That's enough about iterators. Iterator adaptors are the last concept </ins> we need to talk about with regards to iterators. Let's get to it! <del> ## Iterator adapters </del> <ins> ## Iterator adaptors </ins> <del> *Iterator adapters* take an iterator and modify it somehow, producing </del> <ins> *Iterator adaptors* take an iterator and modify it somehow, producing </ins> a new iterator. The simplest one is called `map`: ```rust,ignore
Code change:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

Related discussion:
text: If you are trying to execute a closure on an iterator for its side effects, just use `for` instead. <del> There are tons of interesting iterator adapters. `take(n)` will return an </del> <ins> There are tons of interesting iterator adaptors. `take(n)` will return an </ins> iterator over the next `n` elements of the original iterator. Let's try it out with an infinite iterator:
Code change:
After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.

Related discussion:
text: This will give you a vector containing `6`, `12`, `18`, `24`, and `30`. <del> This is just a small taste of what iterators, iterator adapters, and consumers </del> <ins> This is just a small taste of what iterators, iterator adaptors, and consumers </ins> can help you with. There are a number of really useful iterators, and you can write your own as well. Iterators provide a safe, efficient way to manipulate all kinds of lists. They're a little unusual at first, but if you play with
Code change:
The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] impl<T> Drop for IntoIter<T> { <ins> #[unsafe_destructor_blind_to_params] </ins> fn drop(&mut self) { // destroy the remaining elements for _x in self {}
Code change:
The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.

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. // This test ensures that vec.into_iter does not overconstrain element lifetime. pub fn main() { original_report(); revision_1(); revision_2(); } fn original_report() { drop(vec![&()].into_iter()) } fn revision_1() { // below is what above `vec!` expands into at time of this writing. drop(<[_]>::into_vec(::std::boxed::Box::new([&()])).into_iter()) } fn revision_2() { drop((match (Vec::new(), &()) { (mut v, b) => { v.push(b); v } }).into_iter()) } </ins>
Code change:
One minor doc bug: first example should call writetenbytesatend in test case instead of writetenbytes. PS: Is this a good place for website/doc issues?
Yep, this is the right place!

Related discussion:
text: ///     use std::io::Cursor; ///     let mut buff = Cursor::new(vec![0; 15]); /// <del> ///     write_ten_bytes(&mut buff).unwrap(); </del> <ins> ///     write_ten_bytes_at_end(&mut buff).unwrap(); </ins> /// ///     assert_eq!(&buff.get_ref()[5..15], &[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); /// }
Code change:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> //! A Unicode scalar value </del> <ins> //! Unicode scalar values </ins> //! //! This module provides the `CharExt` trait, as well as its //! implementation for the primitive `char` type, in order to allow
Code change:
Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.

Related discussion:
text: /// character, as `char`s. /// /// All characters are escaped with Rust syntax of the form `u{NNNN}` <del> /// where `NNNN` is the shortest hexadecimal representation of the code /// point. </del> <ins> /// where `NNNN` is the shortest hexadecimal representation. </ins> /// /// # Examples /// <ins> /// Basic usage: /// </ins> /// ``` /// for c in '❤'.escape_unicode() { ///     print!("{}", c);