jiebi/CodeConvo huggingface dataset:
Change:
The section of the Rust book on Slices is nice (hard to find in primitive types) but it gives more information on : The actual docs for slice just intro it out of nowhere with no explanation of the fact that it's syntactic sugar for as_slice. This is a subtle thing, but since googling for [..] is hard and github searching for "[..]" is basically impossible, it's a tough thing to have to search out, let alone explain on the web. Thanks! Anyway, great documentation, hard to search for without single page, but I would want to fix the docs in libcollections if possible since ideally it would have more information and detail there. -Rich
cc I completely agree that this is a bit weird right now. I'd like to add something, but I'm not sure what form it should take.
It doesn't seem like is defined in rust nightly. Playground link:
In general, is behind the feature gate, and should be used instead.
Ah. That explains it. So it seems like and are actually different things, because one is behind a feature gate, and one is not. Am I right about this?
They do the same thing. The syntax was later, one of the motivations was that is common and quite long, as well as an inexpensive operation.
:+1: to this, it's totally ungoogleable, from the reference I concluded it's an use of the range operator, the book section could mention it.

Discussion:
useful for allowing safe, efficient access to a portion of an array without copying. For example, you might want to reference just one line of a file read into memory. By nature, a slice is not created directly, but from an existing <del> variable. Slices have a length, can be mutable or not, and in many ways behave like arrays: </del> <ins> variable binding. Slices have a defined length, can be mutable or immutable. ## Slicing syntax You can use a combo of `&` and `[]` to create a slice from various things. The `&` indicates that slices are similar to references, and the `[]`s, with a range, let you define the length of the slice: </ins> ```rust let a = [0, 1, 2, 3, 4]; <del> let middle = &a[1..4]; // A slice of a: just the elements 1, 2, and 3 </del> let complete = &a[..]; // A slice containing all of the elements in a <ins> let middle = &a[1..4]; // A slice of a: just the elements 1, 2, and 3 </ins> ``` Slices have type `&[T]`. We’ll talk about that `T` when we cover
Change:
I noticed that the formatting of panic conditions in the documentation of a lot of functions seems to be inconsistent. Specifically it varies between simple warnings in the description of the function and 'Panics' subheaders with the panic condition listed below. A good example being the difference between and . I like that headers make it very explicit (visually) where the panic conditions in a function call are, but they can also lead to confusion since the same header used multiple times on a given page makes any links to them (via url#Header) direct to the topmost 'Panic' header.
In general, they should all be with the header, yes. At this point, since we're still doing a lot of work on the std docs, I'm doing this as I go, rather than trying to do a whole audit of every function. So I've submitted a PR for , and if you can enumerate any other places, I'm happy to knock them out.

Discussion:
/// the index `mid` itself) and the second will contain all /// indices from `[mid, len)` (excluding the index `len` itself). /// <ins> /// # Panics /// </ins> /// Panics if `mid > len`. /// /// # Examples
Change:
The trait has a sadly-neglected method that clones a value into an existing one. There is a default implementation, but it's fairly naive and therefore not optimal for all cases, notably collections. It would be good if the major collections had better implementations for where it can be implemented more efficiently. /cc
Seems pretty reasonable to me. We might also want to consider updating deriving logic to implement clone_from explicitly
cc
My thoughts here are that one-off specialized implementations are fine, but I'm not a huge fan of altering (e.g. see my comments on ). In that sense I'm fine just updating implementations in-tree for collections to "do the right thing"
[x] [x] [x] [ ] [ ] [x] [x] [x] [x] [x] [x]
Edited the list to add Option and Result
Triage: the above list is still accurate today.
Seems like a good issue for people who want to work on libstd
You can update your comment to check Option and Result. :)
Do we currently have any specific requirements to field drop order for this method? The docs are too vague. This can actuallly cause problems. For example, : prints: , but if we uncomment custom implementation of , then it prints: This can break the code which relies on specific drop order, so implementing for the sake of optimisation is actually a breaking change.
you can check , , , and . I would also argue that since and derive from hashbrown (and the benefits of seem dubious there anyway), this issue could be closed?
This was marked fixed by in ; however, currently use the trait default impl rather than because they . Is this intentional? If not, perhaps this issue should be reopened for now?
Nice catch! It should be pretty simple to resolve though, would you like to create a PR?
Opened .

Discussion:
/// // use the values stored in map /// ``` <del> #[derive(Clone)] </del> #[cfg_attr(not(test), rustc_diagnostic_item = "hashmap_type")] #[stable(feature = "rust1", since = "1.0.0")] pub struct HashMap<K, V, S = RandomState> {

} #[stable(feature = "rust1", since = "1.0.0")] <ins> impl<K, V, S> Clone for HashMap<K, V, S> where K: Clone, V: Clone, S: Clone, { #[inline] fn clone(&self) -> Self { Self { base: self.base.clone() } } #[inline] fn clone_from(&mut self, other: &Self) { self.base.clone_from(&other.base); } } #[stable(feature = "rust1", since = "1.0.0")] </ins> impl<K, V, S> PartialEq for HashMap<K, V, S> where K: Eq + Hash,

/// [`HashMap`]: crate::collections::HashMap /// [`RefCell`]: crate::cell::RefCell /// [`Cell`]: crate::cell::Cell <del> #[derive(Clone)] </del> #[cfg_attr(not(test), rustc_diagnostic_item = "hashset_type")] #[stable(feature = "rust1", since = "1.0.0")] pub struct HashSet<T, S = RandomState> {

} #[stable(feature = "rust1", since = "1.0.0")] <ins> impl<T, S> Clone for HashSet<T, S> where T: Clone, S: Clone, { #[inline] fn clone(&self) -> Self { Self { base: self.base.clone() } } #[inline] fn clone_from(&mut self, other: &Self) { self.base.clone_from(&other.base); } } #[stable(feature = "rust1", since = "1.0.0")] </ins> impl<T, S> PartialEq for HashSet<T, S> where T: Eq + Hash,
Change:
Using rustc 1.3.0 ( 2015-09-15) Apply suggestion and make a : yields
Should we change the "explain" message?
We should make the error message change depending on the compiler version. Perhaps replace it with a note "switch to a nightly compiler to be able to use constant functions". The explain message should just be expanded a bit to mention nightlies. Of course, we should leave comments there with an issue for fixing these once const fn stabilizes

Discussion:
``` "##, <ins> // FIXME(#24111) Change the language here when const fn stabilizes </ins> E0015: r##" The only functions that can be called in static or constant expressions are <del> `const` functions. Rust currently does not support more general compile-time function execution. </del> <ins> `const` functions, and struct/enum constructors. `const` functions are only available on a nightly compiler. Rust currently does not support more general compile-time function execution. ``` const FOO: Option<u8> = Some(1); // enum constructor struct Bar {x: u8} const BAR: Bar = Bar {x: 1}; // struct constructor ``` </ins> See [RFC 911] for more details on the design of `const fn`s.

use rustc_front::hir; use syntax::ast; use syntax::codemap::Span; <ins> use syntax::feature_gate::UnstableFeatures; </ins> use rustc_front::visit::{self, FnKind, Visitor}; use std::collections::hash_map::Entry;

if !is_const { v.add_qualif(ConstQualif::NOT_CONST); if v.mode != Mode::Var { <del> span_err!(v.tcx.sess, e.span, E0015, "function calls in {}s are limited to  constant functions,  struct and enum constructors", v.msg()); </del> <ins> // FIXME(#24111) Remove this check when const fn stabilizes if let UnstableFeatures::Disallow = v.tcx.sess.opts.unstable_features { span_err!(v.tcx.sess, e.span, E0015, "function calls in {}s are limited to  struct and enum constructors", v.msg()); v.tcx.sess.span_note(e.span, "a limited form of compile-time function  evaluation is available on a nightly  compiler via `const fn`"); } else { span_err!(v.tcx.sess, e.span, E0015, "function calls in {}s are limited to  constant functions,  struct and enum constructors", v.msg()); } </ins> } } }
Change:
Output:
The expansion of this is: Note that does not cause this problem.
Note also that this is only the case with jemalloc. The following runs successfully:
Actually, this is just related to calling jemalloc with 0 for the size:
We should probably apply a temporary fix for this (and audit all other uses of ), though will remove the direct allocation calls.
triage: I-nominated Seems pretty serious and something we may want to fix soon!
cc
I have a potential PR in progress, just running tests locally.

Discussion:
let (keys_size, keys_align) = (capacity * mem::size_of::<K>(), mem::align_of::<K>()); let (vals_size, vals_align) = (capacity * mem::size_of::<V>(), mem::align_of::<V>()); let (edges_size, edges_align) = if is_leaf { <del> (0, 1) </del> <ins> // allocate one edge to ensure that we don't pass size 0 to `heap::allocate` if mem::size_of::<K>() == 0 && mem::size_of::<V>() == 0 { (1, mem::align_of::<Node<K, V>>()) } else { (0, 1) } </ins> } else { ((capacity + 1) * mem::size_of::<Node<K, V>>(), mem::align_of::<Node<K, V>>()) };

assert_eq!(a[&3], "three"); } <ins> #[test] fn test_zst() { let mut m = BTreeMap::new(); assert_eq!(m.len(), 0); assert_eq!(m.insert((), ()), None); assert_eq!(m.len(), 1); assert_eq!(m.insert((), ()), Some(())); assert_eq!(m.len(), 1); assert_eq!(m.iter().count(), 1); m.clear(); assert_eq!(m.len(), 0); for _ in 0..100 { m.insert((), ()); } assert_eq!(m.len(), 1); assert_eq!(m.iter().count(), 1); } // This test's only purpose is to ensure that zero-sized keys with nonsensical orderings // do not cause segfaults when used with zero-sized values. All other map behavior is // undefined. #[test] fn test_bad_zst() { use std::cmp::Ordering; struct Bad; impl PartialEq for Bad { fn eq(&self, _: &Self) -> bool { false } } impl Eq for Bad {} impl PartialOrd for Bad { fn partial_cmp(&self, _: &Self) -> Option<Ordering> { Some(Ordering::Less) } } impl Ord for Bad { fn cmp(&self, _: &Self) -> Ordering { Ordering::Less } } let mut m = BTreeMap::new(); for _ in 0..100 { m.insert(Bad, Bad); } } </ins> mod bench { use std::collections::BTreeMap; use std::__rand::{Rng, thread_rng};
Change:
The above link states that rust is not production ready. Is this a mistake?
I wonder how many people read this FAQ after 1.0 :fearful:
Well, we're hoping to re-do the FAQ: (I'll send a PR to fix this in the meantime though, nice catch!)
I see that this was merged. But, the website still says the same thing, that Rust isn't production-ready. I think the issue should be re-opened until the website is actually updated. This is an important issue as far as advocacy and community-building goes.
They've already made their way to beta, and so will be part of stable as of the next release. The docs are part of the release, we'd have to cut a 1.5.1 to update this.
OK, thanks for clarifying that. I think it's reasonable to let it ride until 1.5 is released.

Discussion:
# Is any part of this thing production-ready? <del> No. Feel free to play around, but don't expect completeness or stability yet. Expect incompleteness and breakage. </del> <ins> Yes! </ins> # Is this a completely Mozilla-planned and orchestrated thing?
Change:
In I have this trait like this: I'd like to switch the bound on to be , but then I can no longer use a bare for , because there is currently no . It seems to me that such an impl ought to exist, especially because already exists.
Yes, and .
Since it landed now, it should appear first in Rust 1.5 (and will be stable).
Thank you!

Discussion:
} } <ins> #[stable(feature = "vec_as_mut", since = "1.5.0")] impl<T> AsMut<Vec<T>> for Vec<T> { fn as_mut(&mut self) -> &mut Vec<T> { self } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<T> AsRef<[T]> for Vec<T> { fn as_ref(&self) -> &[T] {

} } <ins> #[stable(feature = "vec_as_mut", since = "1.5.0")] impl<T> AsMut<[T]> for Vec<T> { fn as_mut(&mut self) -> &mut [T] { self } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a, T: Clone> From<&'a [T]> for Vec<T> { #[cfg(not(test))]
Change:
Compiling the following code causes a panic: Compiler output: I compiled with rustc 1.5.0-nightly ( 2015-09-19) binary: rustc commit-hash: commit-date: 2015-09-19 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Reduced test case:
This is a 1.3-1.4 regression. I accidentally caused it in .
triage: I-nominated
triage: P-medium

Discussion:
self.resolve_type_vars_or_error(&ty) } <ins> pub fn tables_are_tcx_tables(&self) -> bool { let tables: &RefCell<ty::Tables> = &self.tables; let tcx_tables: &RefCell<ty::Tables> = &self.tcx.tables; tables as *const _ == tcx_tables as *const _ } </ins> pub fn type_moves_by_default(&self, ty: Ty<'tcx>, span: Span) -> bool { let ty = self.resolve_type_vars_if_possible(&ty); <del> if ty.needs_infer() { </del> <ins> if ty.needs_infer() || (ty.has_closure_types() && !self.tables_are_tcx_tables()) { </ins> // this can get called from typeck (by euv), and moves_by_default // rightly refuses to work with inference variables, but // moves_by_default has a cache, which we want to use in other

<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. struct A<F: FnOnce()->T,T>(F::Output); struct B<F: FnOnce()->T,T>(A<F,T>); // Removing Option causes it to compile. fn foo<T,F: FnOnce()->T>(f: F) -> Option<B<F,T>> { Some(B(A(f()))) } fn main() { let v = (|| foo(||4))(); match v { Some(B(A(4))) => {}, _ => unreachable!() } } </ins>
Change:
is valid syntax and compiles to a regular vector. This is because macros use s, not s as their names. Multi-segment paths are disallowed, but the path can have type parameters. We can move macros to s, however this would not be backwards compatible since anyone using would get a syntax error (even though the original syntax is meaningless). It's still a bug, so perhaps we can get away with this breaking change. Thoughts? cc
I'd say fix it and do a crater run.
Sounds like a plan to me
Ping?
I don't think anyone worked on it. In case someone wants to work on it, the two relevant points are and . It should be possible to error if the path is absolute, has more than one component, or any lifetime/type parameters. We can then do a crater run to see if these are used in the wild for some reason.
cc
I fixed this in .

Discussion:
&fld.cx.ecfg.features.unwrap()); } <del> if path.segments.len() > 1 { </del> <ins> if path.segments.len() > 1 || path.global || !path.segments[0].parameters.is_empty() { </ins> fld.cx.span_err(path.span, "expected macro name without module separators"); return None; }

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // error-pattern:expected macro name without module separators </del> fn main() { <del> globnar::brotz!(); </del> <ins> globnar::brotz!(); //~ ERROR expected macro name without module separators ::foo!(); //~ ERROR expected macro name without module separators foo::<T>!(); //~ ERROR expected macro name without module separators </ins> }
Change:
This has happened as much as it will for now, once we actually stabilize no_std, we will have to fix up its docs, but we don't need an issue open to track it.

Discussion:
this is undesirable, and can be avoided with the `#![no_std]` attribute attached to the crate. <del> ```ignore // a minimal library #![crate_type="lib"] #![feature(no_std)] #![no_std] # // fn main() {} tricked you, rustdoc! ``` </del> Obviously there's more to life than just libraries: one can use `#[no_std]` with an executable, controlling the entry point is possible in two ways: the `#[start]` attribute, or overriding the

in the same format as C: ```rust <del> #![feature(lang_items, start, no_std, libc)] </del> <ins> # #![feature(libc)] #![feature(lang_items)] #![feature(start)] #![feature(no_std)] </ins> #![no_std] // Pull in the system libc library for what crt0.o likely requires

correct ABI and the correct name, which requires overriding the compiler's name mangling too: <del> ```ignore </del> <ins> ```rust # #![feature(libc)] </ins> #![feature(no_std)] <ins> #![feature(lang_items)] #![feature(start)] </ins> #![no_std] #![no_main] <del> #![feature(lang_items, start)] </del> extern crate libc;

The core library has very few dependencies and is much more portable than the standard library itself. Additionally, the core library has most of the <del> necessary functionality for writing idiomatic and effective Rust code. </del> <ins> necessary functionality for writing idiomatic and effective Rust code. When using `#![no_std]`, Rust will automatically inject the `core` crate, just like we do for `std` when we’re using it. </ins> As an example, here is a program that will calculate the dot product of two vectors provided from C, using idiomatic Rust practices. <del> ```ignore #![feature(lang_items, start, no_std, core, libc)] </del> <ins> ```rust # #![feature(libc)] #![feature(lang_items)] #![feature(start)] #![feature(no_std)] #![feature(core)] #![feature(core_slice_ext)] #![feature(raw)] </ins> #![no_std] <del> # extern crate libc; extern crate core; use core::prelude::*; </del> <ins> extern crate libc; </ins> use core::mem;
Change:
We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.
intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.
That's not the problem, really, I believe we already have code to generate the shims. The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.
I don't think we have code for creating the shims, even. It's more that the ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.
We haven't had code for generating shims around intrinsics for a long time. As alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.
No longer ICEs ()
It requires now.
Ah, ok. Still no longer ICEs, but fails with a linker error (), if the distinction matters.
I think this has been fixed -- marking as E-needstest. Did you mean to self-assign this?
This seems like it could be made into an easy issue for newcomers.
This is now caught by .

Discussion:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

<ins> // edition:2018 use std::sync::{Arc, Mutex}; pub async fn f(_: ()) {} pub async fn run() { let x: Arc<Mutex<()>> = unimplemented!(); f(*x.lock().unwrap()).await; } </ins>

<ins> // aux-build: issue_67893.rs // edition:2018 // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. extern crate issue_67893; fn g(_: impl Send) {} fn main() { g(issue_67893::run()) //~^ ERROR: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely } </ins>

<ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

<ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

<ins> // aux-build: issue_24843.rs // check-pass extern crate issue_24843; static _TEST_STR_2: &'static str = &issue_24843::TEST_STR; fn main() {} </ins>
Change:
struct with unknow value from enum in slice variable I tried this code: I expected to see this happen: Instead, this happened:

Discussion:
ShiftRightWithOverflow, MissingStructField, NonConstPath, <ins> UnresolvedPath, </ins> ExpectedConstTuple, ExpectedConstStruct, TupleIndexOutOfBounds,

ShiftLeftWithOverflow => "attempted left shift with overflow".into_cow(), ShiftRightWithOverflow => "attempted right shift with overflow".into_cow(), MissingStructField  => "nonexistent struct field".into_cow(), <del> NonConstPath        => "non-constant path in constant expr".into_cow(), </del> <ins> NonConstPath        => "non-constant path in constant expression".into_cow(), UnresolvedPath => "unresolved path in constant expression".into_cow(), </ins> ExpectedConstTuple => "expected constant tuple".into_cow(), ExpectedConstStruct => "expected constant struct".into_cow(), TupleIndexOutOfBounds => "tuple index out of bounds".into_cow(),

} } hir::ExprPath(..) => { <del> let opt_def = tcx.def_map.borrow().get(&e.id).map(|d| d.full_def()); </del> <ins> let opt_def = if let Some(def) = tcx.def_map.borrow().get(&e.id) { // After type-checking, def_map contains definition of the // item referred to by the path. During type-checking, it // can contain the raw output of path resolution, which // might be a partially resolved path. // FIXME: There's probably a better way to make sure we don't // panic here. if def.depth != 0 { signal!(e, UnresolvedPath); } Some(def.full_def()) } else { None }; </ins> let (const_expr, const_ty) = match opt_def { Some(def::DefConst(def_id)) => { if def_id.is_local() {

<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. fn main() { fn f(a: [u8; u32::DOESNOTEXIST]) {} //~^ ERROR unresolved path in constant expression } </ins>