jiebi/CodeConvo huggingface dataset:
Change:
I just wanted to note that it is nowhere mentioned that all iterators from there are in sorted order. While I have to admit that it makes sense for a ordered container to provide ordered iterators, it is not documented. In the examples it is assumed that the iterators are ordered, but nowhere explictly stated. Neither in the BTreeMap nor the BTreeSet.
part of
This is not actually closed, as the documentation for still does not mention this. The change was made only for .

Discussion:
} impl<K, V> BTreeMap<K, V> { <del> /// Gets an iterator over the entries of the map. </del> <ins> /// Gets an iterator over the entries of the map, sorted by key. </ins> /// /// # Examples ///

/// use std::collections::BTreeMap; /// /// let mut map = BTreeMap::new(); <del> /// map.insert(1, "a"); /// map.insert(2, "b"); </del> /// map.insert(3, "c"); <ins> /// map.insert(2, "b"); /// map.insert(1, "a"); </ins> /// /// for (key, value) in map.iter() { ///     println!("{}: {}", key, value);

} } <del> /// Gets a mutable iterator over the entries of the map. </del> <ins> /// Gets a mutable iterator over the entries of the map, sorted by key. </ins> /// /// # Examples ///

} } <del> /// Gets an iterator over the keys of the map. </del> <ins> /// Gets an iterator over the keys of the map, in sorted order. </ins> /// /// # Examples ///

/// use std::collections::BTreeMap; /// /// let mut a = BTreeMap::new(); <del> /// a.insert(1, "a"); </del> /// a.insert(2, "b"); <ins> /// a.insert(1, "a"); </ins> /// /// let keys: Vec<_> = a.keys().cloned().collect(); /// assert_eq!(keys, [1, 2]);

Keys { inner: self.iter() } } <del> /// Gets an iterator over the values of the map. </del> <ins> /// Gets an iterator over the values of the map, in order by key. </ins> /// /// # Examples ///

/// use std::collections::BTreeMap; /// /// let mut a = BTreeMap::new(); <del> /// a.insert(1, "a"); /// a.insert(2, "b"); </del> <ins> /// a.insert(1, "hello"); /// a.insert(2, "goodbye"); </ins> /// /// let values: Vec<&str> = a.values().cloned().collect(); <del> /// assert_eq!(values, ["a", "b"]); </del> <ins> /// assert_eq!(values, ["hello", "goodbye"]); </ins> /// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn values<'a>(&'a self) -> Values<'a, K, V> {
Change:
was closed and the user who filed it was educated, but they're not the first and not the last person to be confused by this. AFAIK the behavior of foo` &mdash; is not documented, at least I couldn't find anything in the reference and it seems a tad obscure to be mentioned in the book.
Well it is covered (and linked from the Syntax Index) but it doesn't explain the behavior discussed in .

Discussion:
Here, we bind the first and last element of the tuple to `x` and `z`, but ignore the middle element. <del> Similarly, you can use `..` in a pattern to disregard multiple values. </del> <ins> It’s worth noting that using `_` never binds the value in the first place, which means a value may not move: ```rust let tuple: (u32, String) = (5, String::from("five")); // Here, tuple is moved, because the String moved: let (x, _s) = tuple; // The next line would give "error: use of partially moved value: `tuple`" // println!("Tuple is: {:?}", tuple); // However, let tuple = (5, String::from("five")); // Here, tuple is _not_ moved, as the String was never moved, and u32 is Copy: let (x, _) = tuple; // That means this works: println!("Tuple is: {:?}", tuple); ``` This also means that any temporary variables will be dropped at the end of the statement: ```rust // Here, the String created will be dropped immediately, as it’s not bound: let _ = String::from("  hello  ").trim(); ``` You can also use `..` in a pattern to disregard multiple values: </ins> ```rust enum OptionalTuple {
Change:
This simple code fails to compile because is not defined. But the error message is . But is not the cause it just happens to occur after .
I agree that this is confusing, though from the compiler's perspective, the error message makes sense. Since isn't a variant of , becomes the name of a binding that matches all possible values of other than . (See ) Once that happens, the case is indeed unreachable.
Perhaps the error message could point to the match arm that the unreachable arm overlaps with.
Also if you comment out the Bar arm, you get a snake-case warning on Other, but unfortunately the error happens first.
Thanks for your coments. Now at least I understand why the compiler printed this error message.
Related:

Discussion:
}, hir::MatchSource::Normal => { <del> span_err!(cx.tcx.sess, pat.span, E0001, "unreachable pattern") </del> <ins> let mut err = struct_span_err!(cx.tcx.sess, pat.span, E0001, "unreachable pattern"); // if we had a catchall pattern, hint at that for row in &seen.0 { if pat_is_catchall(&cx.tcx.def_map.borrow(), row[0]) { span_note!(err, row[0].span, "this pattern matches any value"); } } err.emit(); </ins> }, hir::MatchSource::TryDesugar => {

} } <del> fn raw_pat<'a>(p: &'a Pat) -> &'a Pat { </del> <ins> /// Checks for common cases of "catchall" patterns that may not be intended as such. fn pat_is_catchall(dm: &DefMap, p: &Pat) -> bool { match p.node { PatKind::Ident(_, _, None) => pat_is_binding(dm, p), PatKind::Ident(_, _, Some(ref s)) => pat_is_catchall(dm, &s), PatKind::Ref(ref s, _) => pat_is_catchall(dm, &s), PatKind::Tup(ref v) => v.iter().all(|p| pat_is_catchall(dm, &p)), _ => false } } fn raw_pat(p: &Pat) -> &Pat { </ins> match p.node { PatKind::Ident(_, _, Some(ref s)) => raw_pat(&s), _ => p

<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. enum Enum { Var1, Var2, } fn main() { use Enum::*; let s = Var1; match s { Var1 => (), Var3 => (), //~^ NOTE this pattern matches any value Var2 => (), //~^ ERROR unreachable pattern }; match &s { &Var1 => (), &Var3 => (), //~^ NOTE this pattern matches any value &Var2 => (), //~^ ERROR unreachable pattern }; let t = (Var1, Var1); match t { (Var1, b) => (), (c, d) => (), //~^ NOTE this pattern matches any value anything => () //~^ ERROR unreachable pattern }; // `_` need not emit a note, it is pretty obvious already. let t = (Var1, Var1); match t { (Var1, b) => (), _ => (), anything => () //~^ ERROR unreachable pattern }; } </ins>
Change:
Running with will reproducibly result in Error with OS code 87. if is omitted, it works:
This is expected behavior because it appears that there are basically some required environment variables on Windows to get subprocesses to work. For example and which seems to match as well
Should we ensure that on windows we pass these variables through regardless of being specified? Otherwise, we should at least document this behaviour.
Perhaps yeah. In the past our spawning tended to mirror libuv closely (where it all originated from), but we've since backpedaled a bit from that original design. From a systems-y perspective I would prefer that actually clear the environment, but from a "let's make this ergonomic to use" perspective it'd make more sense to only clear non-required environment variables. I'd probably personally be fine either way
is used to create a new environment block. If is passed for then the returned block will "start from a clean state". If we're going to preserve a few required environment variables, might as well get them straight from the system rather than inheriting them.
Sounds reasonable to me!
I feel like this isn't a change we can make backwards compatibly. What are the considerations that are involved in making this change? Can we make it? We at least need documentation for this inconsistency, but I'm not sure what tag to use for those issues: ?
I think we've got leeway to change the implementation on Windows to preserve some environment variables. If a process can just literally not be spawned without an environment variable then we're basically guaranteed to not break anyone if we start preserving it by default on . Existing working code would override it anyway (as it'd specify a value for the variable)
See the discussion in PowerShell/PowerShell.
The issue is closed, but with the fix related to running process on windows with empty environment that seems not quite exactly as described Using on windows is still unusable in most cases and leads to the cryptic errors like
Can you open a new issue?

Discussion:
fn take_send_sync_type<T: Send + Sync>(_: T) {} take_send_sync_type(Command::new("")) } <ins> // Ensure that starting a process with no environment variables works on Windows. // This will fail if the environment block is ill-formed. #[test] #[cfg(windows)] fn env_empty() { let p = Command::new("cmd").args(&["/C", "exit 0"]).env_clear().spawn(); assert!(p.is_ok()); } </ins>

if let Some(env) = maybe_env { let mut blk = Vec::new(); <ins> // If there are no environment variables to set then signal this by // pushing a null. if env.is_empty() { blk.push(0); } </ins> for (k, v) in env { blk.extend(ensure_no_nuls(k.0)?.encode_wide()); blk.push('=' as u16);
Change:
Under the heading "Composing Option<Tvalues" in Section 5.7 of the Rust Programming Language at , a function is defined: A later example invokes appears to invoke this function: This compiles but I believe it is not using this version of map presented in the book, but rather it is using the one from the standard library. If you rename the function to zmap to distinguish them you get the following message: I believe that this an error in the book because the function presented does not use self, &self, or &mut self as the first parameter and thus cannot use dot syntax for calling map. However, it may be intended to call the real map function and not the one in the prior example. If that is the case I find this area confusing and would suggest that this is changed or clarified. I think changing the name of the example function would be sufficient personally. Later in the same area of the book there is another similar example function: and then for the example following it, a note: (Note that unwrapor is defined as a method on Option<Tin the standard library, so we use that here instead of the free-standing function we defined above. That would be a great inclusion too.
Yes, you're right here. thank you!

Discussion:
``` Indeed, `map` is [defined as a method][2] on `Option<T>` in the standard library. <ins> As a method, it has a slighly different signature: methods take `self`, `&self`, or `&mut self` as their first argument. </ins> Armed with our new combinator, we can rewrite our `extension_explicit` method to get rid of the case analysis:

} ``` <ins> Like with `map` above, the standard library implementation is a method instead of a free function. </ins> The trick here is that the default value must have the same type as the value that might be inside the `Option<T>`. Using it is dead simple in our case:
Change:
The following code produces an internal compiler error when compiled with rustc 1.8.0-nightly (2016-01-27) through the Rust playground: Here's a sample of the error output from the playground: The error occurs regardless of the type of the array's elements. The error seems to be related to the type of array constructor used, since the following code compiles just fine: The error does not occur when associated constants are not involved: Now with backtrace!

Discussion:
}, } } <ins> // If we see a const here, that's because it evaluates to a type with zero size. We // should be able to just discard it, since const expressions are guaranteed not to // have side effects. This seems to be reached through tuple struct constructors being // passed zero-size constants. if let hir::ExprPath(..) = expr.node { match bcx.def(expr.id) { Def::Const(_) | Def::AssociatedConst(_) => { assert!(type_is_zero_size(bcx.ccx(), bcx.tcx().node_id_to_type(expr.id))); return bcx; } _ => {} } } </ins> // Even if we don't have a value to emit, and the expression // doesn't have any side-effects, we still have to translate the // body of any closures.

match expr.node { hir::ExprPath(..) => { match bcx.def(expr.id) { <del> Def::Const(did) => { </del> <ins> Def::Const(did) | Def::AssociatedConst(did) => { </ins> let empty_substs = bcx.tcx().mk_substs(Substs::trans_empty()); let const_expr = consts::get_const_expr(bcx.ccx(), did, expr, empty_substs);

let lval = Lvalue::new("expr::trans_def"); DatumBlock::new(bcx, Datum::new(val, const_ty, LvalueExpr(lval))) } <del> Def::Const(_) => { </del> <ins> Def::Const(_) | Def::AssociatedConst(_) => { </ins> bcx.sess().span_bug(ref_expr.span, "constant expression should not reach expr::trans_def") }

<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. #![feature(associated_consts)] #[derive(Clone, Copy, Debug)] struct Bar; const BAZ: Bar = Bar; #[derive(Debug)] struct Foo([Bar; 1]); struct Biz; impl Biz { const BAZ: Foo = Foo([BAZ; 1]); } fn main() { let foo = Biz::BAZ; println!("{:?}", foo); } </ins>

<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. // Regression test for issue #31267 #![feature(associated_consts)] struct Foo; impl Foo { const FOO: [i32; 3] = [0; 3]; } pub fn main() { let foo = Foo::FOO; assert_eq!(foo, [0i32, 0, 0]); } </ins>
Change:
Not even sure if this is a real bug or not, but it's 100% reproducible in my environment, even after .
This is also reproducible on a completely i686 toolchain and environment (only the processor is x64, edit: also the kernel), see and some build logs: I currently have an uncleaned build tree with the failing compiled test files intact, in case you have further ideas on how to debug this. (I already tried setting to 10x the default value and it's still failing.)
I can reproduce this outside of the bootstrap as well. By downloading the i686 linux nightlies and compiling this tests I get the same valgrind error. I'm not really sure if it's legitimate or not, as it only causes weird behavior in valgrind...
Here's the proc-mem map from vgdb
Hm, shouldn't we at least file a bug upstream to valgrind?
Perhaps, yeah, but I'm also not confident that it's a bug in valgrind, so it may be premature to do so
I can confirm that it fixed the test failure on Debian i386 and the build is now green on this arch. Thanks
Also fixed on my ubuntu builds. However, I'd suggest that we file this to valgrind even if we're "not sure" if it's a bug, since otherwise this is going to get lost to history - the issue is "closed" and nobody looks at these afterwards.
Sure, go ahead !
Alright I filed feel free to add details, I'm not an expert in this topic.

Discussion:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // no-prefer-dynamic </ins> thread_local!(static FOO: Foo = Foo); thread_local!(static BAR: Bar = Bar(1)); thread_local!(static BAZ: Baz = Baz);
Change:
Both Vec<Tand &[T] are missing From impls for Cow, unlike String/&str and PathBuf/&Path. Coherence is not (afaict) an issue, since the impl would be in the same crate as Cow. Is there some reason these don't exist (do they cause coherence issues in downstream crates or something)?
Whoa, I have no idea why these aren't implemented... Should be good to go ahead and add them! Want to send a PR?

Discussion:
// Clone-on-write //////////////////////////////////////////////////////////////////////////////// <ins> #[stable(feature = "cow_from_vec", since = "1.7.0")] impl<'a, T: Clone> From<&'a [T]> for Cow<'a, [T]> { fn from(s: &'a [T]) -> Cow<'a, [T]> { Cow::Borrowed(s) } } #[stable(feature = "cow_from_vec", since = "1.7.0")] impl<'a, T: Clone> From<Vec<T>> for Cow<'a, [T]> { fn from(v: Vec<T>) -> Cow<'a, [T]> { Cow::Owned(v) } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a, T> FromIterator<T> for Cow<'a, [T]> where T: Clone { fn from_iter<I: IntoIterator<Item = T>>(it: I) -> Cow<'a, [T]> {

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> use std::borrow::Cow; </ins> use std::cmp::Ordering::{Equal, Greater, Less}; use std::str::from_utf8;

assert_eq!(data, data2); } <ins> #[test] fn test_cow_from() { let borrowed = "borrowed"; let owned = String::from("owned"); match (Cow::from(owned.clone()), Cow::from(borrowed)) { (Cow::Owned(o), Cow::Borrowed(b)) => assert!(o == owned && b == borrowed), _ => panic!("invalid `Cow::from`"), } } </ins> mod pattern { use std::str::pattern::Pattern; use std::str::pattern::{Searcher, ReverseSearcher};

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> use std::borrow::Cow; </ins> use std::iter::{FromIterator, repeat}; use std::mem::size_of;

assert_eq!(vec![1, 2, 3].into_iter().count(), 3); } <ins> #[test] fn test_cow_from() { let borrowed: &[_] = &["borrowed", "(slice)"]; let owned = vec!["owned", "(vec)"]; match (Cow::from(owned.clone()), Cow::from(borrowed)) { (Cow::Owned(o), Cow::Borrowed(b)) => assert!(o == owned && b == borrowed), _ => panic!("invalid `Cow::from`"), } } </ins> #[bench] fn bench_new(b: &mut Bencher) { b.iter(|| {
Change:
This compiles: but this doesn't: More generally, a shadowed trait's methods are usable if it is shadowed by an item, but not if it is shadowed by an import. Should methods from shadowed traits be usable?
cc
cc
Nominating for discussion at meeting. Clearly we should be consistent. I'm inclined to think that they should not be available, ever.
I'm of the same thoughts as A new "thing" with the same name as another outer "thing" should not inherit/infer/have/etc. any part of that outer thing. This is the case with , but—according to the presented opinion—it seems like it needs to be made consistent for trait bindings, right?
Is there a reason to shadow traits by name? What happens here is that it must find a method named among the imported traits, and that name has not been shadowed in any way, so it should be callable.
Well, that's the question, isn't it. Imagine then that did have an method -- would you prefer an ambiguity error here, or success?
Ambiguity error if was implemented for in the example (and this error is already implemented). Otherwise it doesn't interfere in any way.
Another more challenging example might be: should the methods from be available, given that it is shadowed by ?
My feeling is that the simplest rule is to say that methods come from "traits that are in scope", and shadowed traits are not in scope. This interpretation is shadowing of items from prelude and globs, which seem like they should clearly not count towards method resolution.
Discussed in meeting and settled on "methods from shadowed traits should be unavailable". triage: P-medium
We also want methods from to be unavailable (from your more challenging example), right?

Discussion:
} } <del> // FIXME #31379: We can use methods from imported traits shadowed by non-import items if !binding.is_import() { for glob_binding in resolution.duplicate_globs.iter() { </del> <ins> // We can always use methods from the prelude traits for glob_binding in resolution.duplicate_globs.iter() { if glob_binding.defined_with(DefModifiers::PRELUDE) { </ins> module.shadowed_traits.borrow_mut().push(glob_binding); } }

<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. // Test that methods from shadowed traits cannot be used mod foo { pub trait T { fn f(&self) {} } impl T for () {} } mod bar { pub use foo::T; } fn main() { pub use bar::*; struct T; ().f() //~ ERROR no method } </ins>
Change:
Output:
The argument is of type but it is, itself, immutable. You can't redefine to point at somebody else. The rest of the message is nonsensical because it fails to realize that is the specialest of special cases in terms of method signature parsing.

Discussion:
if let Categorization::Local(local_id) = err.cmt.cat { let span = self.tcx.map.span(local_id); if let Ok(snippet) = self.tcx.sess.codemap().span_to_snippet(span) { <del> db.span_suggestion( span, &format!("to make the {} mutable, use `mut` as shown:", self.cmt_to_string(&err.cmt)), format!("mut {}", snippet)); </del> <ins> if snippet != "self" { db.span_suggestion( span, &format!("to make the {} mutable, use `mut` as shown:", self.cmt_to_string(&err.cmt)), format!("mut {}", snippet)); } </ins> } } }

<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. // forbid-output: &mut mut self struct Struct; impl Struct { fn foo(&mut self) { (&mut self).bar(); //~^ ERROR cannot borrow immutable argument `self` as mutable // ... and no SUGGESTION that suggests `&mut mut self` } // In this case we could keep the suggestion, but to distinguish the // two cases is pretty hard. It's an obscure case anyway. fn bar(self: &mut Self) { (&mut self).bar(); //~^ ERROR cannot borrow immutable argument `self` as mutable } } fn main () {} </ins>
Change:
Any of the following uses of cause an ICE in , but not in : Use of in a local is fine; these all simply report the error without an ICE.
I believe this may be a regression caused by . Working on a fix. Edit: Maybe not, actually. Either way I'm looking into it.

Discussion:
let arenas = ty::CtxtArenas::new(); let hir_map = driver::make_map(&sess, &mut hir_forest); <del> abort_on_err(driver::phase_3_run_analysis_passes(&sess, </del> <ins> let krate_and_analysis = abort_on_err(driver::phase_3_run_analysis_passes(&sess, </ins> &cstore, hir_map, &arenas, &name, resolve::MakeGlobMap::No, <del> |tcx, _, analysis, _| { </del> <ins> |tcx, _, analysis, result| { // Return if the driver hit an err (in `result`) if let Err(_) = result { return None } </ins> let _ignore = tcx.dep_graph.in_ignore(); let ty::CrateAnalysis { access_levels, .. } = analysis;

let external_paths = ctxt.external_paths.borrow_mut().take(); *analysis.external_paths.borrow_mut() = external_paths; let map = ctxt.external_typarams.borrow_mut().take(); *analysis.external_typarams.borrow_mut() = map; let map = ctxt.inlined.borrow_mut().take(); *analysis.inlined.borrow_mut() = map; analysis.deref_trait_did = ctxt.deref_trait_did.get(); <del> (krate, analysis) }), &sess) </del> <ins> Some((krate, analysis)) }), &sess); krate_and_analysis.unwrap() </ins> }