'infinite' loop of E0119 error messages | While convoluting some code to try to find error messages, I came across a loop in the errors. The code: impl<T: Drop> Drop for T { fn drop(&mut self) {} } The errors: ``` 120.rs:17:1: 19:2 error: the Drop trait may only be implemented on structures [E0120] 120.rs:17 impl<T: Drop | labels: A-diagnostics


Stable 1.1 ICE: assertion failed: bound_list_is_sorted(&bounds.projection_bounds) | It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is https://github.com/frankmcsherry/timely-dataflow/commit/fcb32c5ad120039273fdba301 | labels: I-ICE


arithmetic operation overflowed at /src/libcore/cell.rs:510 | Hello, I seem to be experiencing a very volatile bug and after seeking help in the rust irc channel, I decided to file a bug report. Unfortunately I didn't found a small piece of code that is able to replicate the bug, and even my full source code doesn't do so at all times (I ha


Macros: Unexpected token when metavariable is "tt", works with "expr" | http://is.gd/GKzXeD ``` rust struct S(u8); macro_rules! mac { ( $val:tt ) => ( S($val) ); //( $val:expr ) => ( S($val) ); } fn main() { let s: S = mac!(4); println!("{}", s.0); } ``` ``` <anon>:4:24: 4:28 error: unexpected token: `4` <anon>:4 ( $val:tt ) => ( S($val) ); ^~~~ ```  | labels: A-macros


Add HashMap::get_pair? | `HashMap` has this method: ``` rust pub fn get<Q: ?Sized>(&self, k: &Q) -> Option<&V> where K: Borrow<Q>, Q: Hash + Eq { self.search(k).map(|bucket| bucket.into_refs().1) } ``` I’d like to add this one, where the only difference is removing `.1`: ``` rust pub fn get_pair<Q: ?Size


types with a raw pointer appearing twice are considered to be dropck types | ``` Rust use std::fmt; struct NoisyDrop<T: fmt::Debug>(T); impl<T: fmt::Debug> Drop for NoisyDrop<T> { fn drop(&mut self) { println!("dropping {:?}", self.0) } } struct Bar<T: fmt::Debug>([*const NoisyDrop<T>; 2]); fn fine() { let (u,b); u = vec![43]; b = Bar([&NoisyDrop(&u), &No | labels: A-type-system


dropck is unsound with closure upvars | This should be fixed by @nikomatsakis's new patch even if the code isn't changed, but I thought it would be nice to track too. ``` Rust use std::fmt; struct NoisyDrop<T: fmt::Debug>(T); impl<T: fmt::Debug> Drop for NoisyDrop<T> { fn drop(&mut self) { let _ = vec!["0wned"]; printl


Make HashMap use a per-process or per-thread seed instead of a per-instance seed | Currently every call to HashMap::new makes a new RandomState that makes two new calls to the thread_rng to create its seed. This is, to my knowledge cryptographic overkill, as there is no clear distinction between a single HashMap with a seed and many HashMaps with the same seed, | labels: E-easy, E-mentor


Allow macros in type positions | Tracking issue for rust-lang/rfcs#873 | labels: E-easy, E-mentor, B-RFC-approved, T-lang, B-unstable, E-help-wanted


Same compiler error two times | Hi everybody, while playing around with rust for the first time (which is great fun!), I noticed something odd. Compiling this: https://play.rust-lang.org/?gist=fb5a1d527f2681d38858&version=stable gives me the same error two times on stable, beta and nightly. Edit: the given erro | labels: A-diagnostics


'missing lifetime specifier' regression in protobuf-1.0.1 | As [reported by crater](https://internals.rust-lang.org/t/new-crater-reports-1-1-stable-vs-beta-2015-07-10-and-nightly-2015-07-10/2358), Rust 1.3 nightlies appear to have [introduced a regression in lifetime elision](https://tools.taskcluster.net/task-inspector/#cuF_XQCSRQafsszsN | labels: regression-from-stable-to-nightly, I-needs-decision, P-high, T-lang


ICE when using associated constants | The following code results in a compiler panic: ``` #![feature(associated_consts)] struct Foo; impl Foo { pub const FOO: u32 = 3; } fn main() { Foo::FOO; } ``` Backtrace: ``` $ RUST_BACKTRACE=1 rustc a.rs a.rs:11:5: 11:14 warning: path statement with no effect, #[warn(path_statem | labels: I-ICE, A-associated-items


Setting --libdir breaks rustc build | Fedora x86_64 builds install libraries to /usr/lib64 so that 32-bit and 64-bit libraries can coexist on the same system. However, with `configure --prefix=/usr --libdir=/usr/lib64 && make`, the build breaks: ``` ... rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknow


ICE on invalid syntax "impl A .. {}" | I'm currently attempting to write a grammar reference from the parser source code, and noticed that there doesn't appear to be anything to prevent you from omitting `for` from `impl A for .. {}`, so I decided to give it a try and this happened: ``` cmd F:\Programming\Rust\sandbox | labels: I-ICE


Edge case on dead_code lint with unused variants | Using this code: https://github.com/retep998/winapi-rs/blob/lint-fail/src/winnt.rs#L2061-L2070 Build log: https://ci.appveyor.com/project/retep998/winapi-rs/build/1.0.327 Relevant warnings: ``` src\winnt.rs:2062:5: 2062:34 warning: variant is never used: `UmsThreadInvalidInfoClas | labels: A-lints


Implement a cap on lints on the rustc CLI | Tracking issue for https://github.com/rust-lang/rfcs/pull/1193 | labels: B-RFC-approved


Error compiling for armv7-apple-ios | This is 607f74df2ad6b6fb32ce5b862a9e48a8c4afdad2. ``` rustc: x86_64-apple-darwin/stage2/lib/rustlib/armv7-apple-ios/lib/libstd warning: dropping unsupported crate type `dylib` for target `armv7-apple-ios` ../src/libstd/rand/os.rs:215:43: 215:52 error: found zero-size struct in fo


Add a method to get the in6_addr from an Ipv6Addr? | How would you feel about adding a method to `std::net::Ipv6Addr` that returned either an `in6_addr` or (equivalently) a `[u16; 8]` in which the `u16`s are in network order? My motivation is that I am writing a binding to a C library which naturally wants an `in6_addr`; on the Rus


Lint against calling .clone() on an otherwise copyable value. | Certain types could start out as having contents that move and then switch to only copyable field, or could just be missing `#[deriving(Copy)]` initially. If `Copy` is implemented after that type has been used in a large codebase (there's a few cases in `rustc` itself), there wil | labels: A-lints


ICE with closure in constant | ``` rust fn main() { const C: &'static Fn() = &||{}; } ``` ``` error: internal compiler error: no type for node 15: expr { } (id=15) in fcx note: the compiler unexpectedly panicked. this is a bug. ``` | labels: I-ICE


Add set_limit() fn to std::io::Take | `std::io::Cursor` has a fn to update the position yet `Take` does not have a fn for setting the limit. Being able to update the limit is required for implementing various traits for Take. For example, `Read` works by updating the limit. I was hoping to implement `Buf` for `Take`  | labels: T-libs-api


Roman numeral plugin example fails to run | The roman numeral demo plugin compiles successfully, but fails with an ICE when run (the same as #26488). ``` rustc --version rustc 1.3.0-nightly (69ca01256 2015-07-23) ``` ``` error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bu | labels: O-macos, A-syntaxext, A-plugins


Stabilisation of `result_expect` | Introduced in RFC1119, covers the `Result::expect` method. An easy candidate for stabilisation as far as I can see, as it's just a single method that brings `Result`'s and `Option`'s APIs closer. (#26868) | labels: E-easy, T-libs-api, final-comment-period, B-unstable


rustc build warning: diagnostic code E0005 already used | Building the master branch yields this warning. ``` src/librustc/middle/check_match.rs:1050:5: 1059:6 warning: diagnostic code E0005 already used src/librustc/middle/check_match.rs:1050 for input in &decl.inputs { src/librustc/middle/check_match.rs:1051 is_refutable(cx, &*input.p


ICE with Self in function bodies, associated types, and lifetimes | ## STR ``` Rust pub trait Trait<'a> { type T; fn foo(&self, s: &'a ()) -> &'a (); } impl<'a> Trait<'a> for () { type T = &'a (); fn foo(&self, s: &'a ()) -> &'a () { let t: Self::T = s; s } } fn main() {} ``` ## Result ``` <anon>:10:16: 10:23 error: internal compiler error: canno


Can mutate in match-arm using a closure | **Update from pnkfelix**: Note that this is now fixed by NLL (see #50783). This bug just remains open because @pnkfelix thinks our policy is to keep NLL-fixed-by-NLL bugs open until we make NLL the default for `rustc`. ---- ## STR ``` Rust fn main() { match Some(&4) { None => {}, | labels: A-type-system, P-medium, T-compiler, I-unsound, A-NLL, C-bug


User facing messages MUST NOT say "illegal". | `error: illegal width`4`for float literal, valid widths are 32 and 64` `error: illegal recursive enum type; wrap the inner value in a box to make it representable [E0072]` You can almost always replace `illegal` with `invalid`. Since we're (probably) not breaking the law writing


Closure fails Sized bound check when capturing struct with fat pointer | # Code ``` rust struct Foo<T: ?Sized> { ptr: *mut T } unsafe impl<T: Send> Send for Foo<T> {} impl<T: Copy> Foo<[T]> { fn new_array(arr: &[T]) -> Self { loop {} } } fn do_something<F: FnOnce() + Send + 'static>(f: F) {} fn main() { let x = Foo::new_array(&[0u8; 4]); do_something(


Build fails with musl | In make install I get: ``` prepare: tmp/dist/rustc-1.1.0-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-*.so ls: cannot access x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-*.so: No such file or directory install


Allow asserts in constant functions | Currently constant functions are not allowed to contain asserts. As asserts are base of defensive it would be nice if they were at least ignored - if nor changed into static asserts - in contexts when constant functions are required.


Mismatched register sizes in inline assembly produces incorrect code or crashes the compiler | ``` rust #![feature(asm)] fn main() { let res: u8; unsafe { asm!("addw %rax, %rbx" : // output operands "={rbx}"(res) : // input operands "{rax}"(1u8), "{rbx}"(2u8) : // clobbers : // options ); } println!("{}", res); } ``` If compiled without optimizations, the assembly is simpl


Explicitly using `extern crate` in documentation examples gives unhelpful error | This would be more an enhancement than anything, but say if you have a library `bignum` and wanted to write an example in your docs `````` //lib.rs //... impl BigNum { //... /// Constructs a ... /// /// # Examples /// /// ``` /// extern crate bignum; /// use bignum::inits::Zero;  | labels: T-rustdoc, A-diagnostics, T-dev-tools, C-bug


improper_ctypes lint triggers for functions returning `()` | https://github.com/rust-lang/rust/commit/6fa17b43d351ed4f9093cf80f4044d1208044241 made the `improper_ctypes` lint trigger for tuples, but as far as I understand, returning `()` is equivalent to returning c_void, and therefore should be allowed. Here is an example: ``` Rust extern | labels: A-diagnostics


Document the correct FFI equivalent to a C opaque struct | With recent changes to the `improper_ctypes` lint, it now rejects `#[repr(C)] struct Foo;` for representing a C opaque struct. ``` Rust #[repr(C)] pub struct Foo; extern "C" { pub fn foo(arg: *const Foo); } fn main() { } ``` ``` foo.rs:5:25: 5:28 warning: found zero-size struct i


Add BitAndNot | The ANDNOT operation is used at least as commonly as XOR and often has a more efficient implementation than x & !y. It introduces a symmetric function to OR for implementing clear-bit and set-bit on bit-vector-like classes. It should be given the same attention (including it's ow


Document Default Type Parameter Fallback | Now that https://github.com/rust-lang/rust/pull/26870 has landed we should document the behavior of the algorithm in the book. I would be happy to draft/review docs for this. cc @steveklabnik | labels: E-easy, E-mentor


Confusing error message (compiler expects `fn` but found `fn`) on macro expantion | ``` rust macro_rules! test { ($Trait:ident, {$($items:tt)*}) => { trait $Trait { $($items)* } } } test!(Foo, { fn test() {} }); ``` Error message: ``` <anon>:4:15: 4:21 error: expected one of `const`, `extern`, `fn`, `type`, or `unsafe`, found `fn` <anon>:4 $($items)* ^~~~~~ play | labels: A-diagnostics


"illegal hardware instruction" when compiling code sample with E0391 error | While implementing explanation for E0391 error (unsupported cyclic reference between types/traits detected) realized, that Rust from master branch fails to compile the following code sample: ``` trait A : B {} trait B : A {} fn main() {} ``` Output: ``` $ rustc ../main/src/main.r | labels: I-ICE, E-needs-test


unexpected panic in rustc | I can't show just a snippet of code to crash rustc but I made an special branch in my project with (what I think) is the minimum code required to crash rustc. This is the full version of the code: ludat/lurri@2ec32237c50b45c84d18f9dc22e008f8187d6724 This is the trimmed down versi | labels: E-easy, E-needs-test, E-mentor


error: internal compiler error: unexpected panic while building nix-rust | Hello, for my latest PR for mq_unlink support in nix-rust the Travis build fails with a message that says: error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. The PR where this happes can be found here: https://github.com/carl | labels: I-ICE


VecDeque has no `sort_by` method (should possibly have one to match Vec). | I just came across a use case for this while working on a visit order for the UI graph in conrod - its absence took me by surprise :smile_cat: Is there a particular reason this hasn't been implemented yet? Or has it just not _popped_ up yet (pun intended)? | labels: A-collections, T-libs-api, C-feature-request


impl Clone for Box<str> | Just like `Box<[T]>`, Clone is also wanted for `Box<str>`, but that can be much simpler: There is no panic issue, and it can use a simple ptr::copy of the data. Follow up after #25097


Generated debuginfo may apparently be ill-formed | Coming from an issue with kcov, here: https://github.com/SimonKagstrom/kcov/issues/105 Apparently, the debuginfo generated in rust executables causes kcov to sometimes put breakpoints in the middle of some instructions. According to kcov developper, it is possibly because the deb | labels: A-debuginfo, C-bug


Test examples in extended diagnostics | The [extended error explanations](https://github.com/rust-lang/rust/blob/master/src/librustc/diagnostics.rs) are filled with amazing examples, but they are not validated in any way. Having these tested would be a great extension to the test suite and ensure that they do not becom | labels: A-testsuite, T-rustdoc


Cargo/rustc fails to compile a project when it is located on one specific Windows drive | I get unexpected errors when running 'cargo build' on a very simple project that basically just imports 'num' crate. The problem happens when I try to compile a project with this Cargo.toml (I can reproduce the problem with just this file in the directory and nothing else.) Cargo | labels: O-windows


Remove morestack dependency. | As we know the concept of segmented stack has been already abandoned. But for freestanding build the Rust compiler still complains about missing _libmorestack.a_: > rustc --crate-type rlib,staticlib --target x86_64-unknown-linux-gnu -C opt-level=3 -C no-stack-check -Z no-landing-


LLVM crash with SIMD types and inline asm | I wrote some code which extracts the two halves of a u64x4, calls some arm neon inline assembly on each half, and combines them again. Trying to compile that code for arm crashes the compiler deep in the LLVM code. I had previously used the exact same inline assembly without any  | labels: A-LLVM, P-low, E-mentor, A-inline-assembly, T-compiler, C-bug


Make OOM a lang item | Currently `alloc::oom` just calls `intrinsics::abort` making the program look like it faulted, when really we killed it in a controlled manner. The reason it does that is that liballoc only assumes we have an allocator and no other OS/runtime. However if oom was a lang item, we c


Tracking Issue for RFC 213: Default Type Parameter Fallback | 2024-07-15: This feature (`default_type_parameter_fallback`) is slated for removal, but that is currently blocked on too many [crater regressions](https://github.com/rust-lang/rust/pull/127655#issuecomment-2228285460). ----- EDIT: this issue has been stalled on disagreements abou | labels: B-RFC-approved, T-lang, B-unstable, B-RFC-implemented, C-tracking-issue, F-default_type_parameter_fallback


Compiler crash on wrong enum definition | I accidentially defined an enum in the wrong way, compiler crashed just after wrinting error messsage. I tried this code: ``` rust #![crate_name = "Test"] #![crate_type = "dylib"] #[repr(C)] enum Foo { Foo_X = 0, Foo_Y = Foo::Foo_X, } #[repr(C)] enum Bar { Bar_X = 0, Bar_Y = Foo: | labels: I-ICE


derive(Copy) on tuple struct with non-Copy field uses unclear "<unnamed_field>" | ``` rust struct Foo; #[derive(Copy, Clone)] struct Bar(Foo); fn main() {} ``` ``` <anon>:2:10: 2:14 error: the trait `Copy` may not be implemented for this type; field `<unnamed_field>` does not implement `Copy` [E0204] <anon>:2 #[derive(Copy, Clone)] ^~~~ ``` It'd be nice to men | labels: A-diagnostics


Compiler UI/UX Design Guidelines Document | There's a lot of compiler UI and UX rules that exist in the developer mindshare, but are not documented anywhere. They aren't really Rust code style guidelines, since they only apply to the compiler (and possibly compiler plugins), so we really need to have another document for t


difficulty with binding example in patterns.md | The second example for the bindings contains advanced syntax that the reader has not seen (at leat to the best of my knowledge when skipping "learn rust"). Those bits: ``` rust let mut x: Option<Person> = Some(Person { name: Some(name) }); match x { Some(Person { name: ref a @ So


Path join() not joining correctly with relative path: "./something" | When you join a path with a relative path like `./something` it does not strip the `./` For example ([Playpen](https://play.rust-lang.org/?gist=004728342ced073706bd&version=nightly)) ``` rust fn main() { let base = PathBuf::from("/some/path"); let relative = PathBuf::from("./some


fs::Path.PathExt::exists accesses uninitialized variable | When running this test program ``` #![feature(path_ext)] use std::path::Path; use std::fs::PathExt; fn main() { println!("Hello, world!"); Path::new("/dev/disk/by-uuid/").join("foo").exists(); println!("Hello, world!"); } ``` in valgrind, I see the following error message: ``` ==


split_at_mut does sketchy things with aliasing | The problematic function: ``` Rust fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) { unsafe { let self2: &mut [T] = mem::transmute_copy(&self); (ops::IndexMut::index_mut(self, ops::RangeTo { end: mid } ), ops::IndexMut::index_mut(self2, ops::RangeFrom { start: mid


freebsd32 test failures | ``` thread '<unnamed>' panicked at 'assertion failed: `(left == right)` (left: `140737488355328`, right: `3`)', ../src/libstd/fs.rs:2036 test fs::tests::open_flavors ... FAILED thread '<unnamed>' panicked at 'assertion failed: `(left == right)` (left: `140737488355328`, right: `3


Confusing error message with unsafe functions in extern blocks | This code produces "error: expected one of `fn`, `pub`, `static`, or `unsafe`, found `unsafe`": ``` rust extern { unsafe fn foo(); } ``` | labels: A-diagnostics


rustdoc: `const fn` not displayed for reexported docs | Doc inclusion / doc reexport does not show `const fn` properly (example: std::cell::Cell::new). - Reexport metabug: rustdoc: Pain points of reexports #24305 - const fn tracker: #24111 | labels: T-rustdoc


Cargo.toml confused by [dependencies.url] | Using Cargo.toml [dependencies.url] in error against some named crate.io, will lead to compile errors, rather than suggesting some "failed to parse" error against Cargo.toml. For example: ``` [dependencies.url] regex = "*" git = "https://github.com/servo/rust-url" ``` will lead t


rustc panic | Unfortunately, I have no idea what causes this panic. I wish I could give more useful info. Here is the backtrace: ``` error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.


Nightly panics when using associated constant in array size | In the playpen (Mode: Debug, Channel: Nightly) I was playing with associated constants when this code made the compiler panic: ``` rust #![feature(associated_consts)] use ::std::marker::PhantomData; trait Num { const VAL: usize; fn val() -> usize; } struct N1; impl Num for N1 { c


readelf complains that .note.rustc is malformed | After building rustc 1.1.0, if I run `readelf --section-headers --note` over the shared libraries produced, I see output like the following: ``` $ readelf --section-headers --note x86_64-unknown-linux-gnu/stage2/lib/libarena-e9599659.so There are 30 section headers, starting at o | labels: O-linux


Some old doc should be removed | https://doc.rust-lang.org/stable/getopts/index.html People might see this page through old link, so these old pages should be removed. We may need `make clean` here, I guess..


Error E0399 regression on nightly from beta. | I have found that with a trait of the form ``` trait Foo { type A = (); fn get_a(&self) -> Option<Self::A> { None } type B = (); fn get_b(&self) -> Option<Self::B> { None } } impl Foo for () { type A = (); } ``` I get the following error message on nightly (as of the time of this


Rustc crashed with stack overflow error | Test code is in https://github.com/zonyitoo/coroutine-rs with branch `boost-stackoverflow`. `cargo build` should be ok, but if you run `cargo run --example simple`, then it will report ``` Compiling coroutine v0.3.1 (file:///Users/zonyitoo/Projects/coroutine-rs) thread 'rustc' ha | labels: I-ICE


Bad impl of the new placement-in suggests to use `ref` where it is invalid | When you implement new placement protocol traits invalidly and consume the collection you’re placing into such as like this: ``` rust let mut x = MyVec(Vec::new()); in x {42}; x ``` the code yields ``` vec-emplace.rs:56:5: 56:6 error: use of moved value: `x` [E0382] vec-emplace.r | labels: A-diagnostics


Tracking issue for changing the global, default allocator (RFC 1974) | Tracking issue for ~~https://github.com/rust-lang/rfcs/pull/1183~~ https://github.com/rust-lang/rfcs/pull/1974 Known bugs: * [ ] The `#[global_allocator]` attribute doesn't work in modules #44113 Current status: * [x] Implemented in https://github.com/rust-lang/rust/pull/42727 *  | labels: T-libs-api, B-unstable, C-tracking-issue


Compiler allows for wrong struct initialization | By mistake I used recursively `Default::default()` inside `Default::default()` implementation. Compilation suceeded, but program crashed on illegal instruction. I tried this code: ``` rust struct A { x: i32, } impl Default for A { fn default() -> A { A { x: 1 } } } struct B { x:


Tracking issue for `no_std` (RFC #1184) | https://github.com/rust-lang/rfcs/pull/1184 | labels: B-RFC-approved


Assembly private symbols redefinition error | On playpen nightly ``` rust #![crate_type="lib"] #![feature(asm)] fn main() { unsafe { routine() } } pub unsafe fn routine() { asm!("mov ecx, 0xFF .loop: loop .loop" : // no outputs : // no inputs : "ecx" : "intel"); } pub unsafe fn routine2() { routine(); // causes inlining, dup | labels: P-low, A-inline-assembly, T-compiler


std::io::BufReader reads incorrect data | Steps to reproduce: 1) Download test TGA image at https://drive.google.com/file/d/0B7COwFox9fT8Wk9WSk5iMWRaRFk/view?usp=sharing . 2) Past this code in `bug_example.rs`: ``` Rust use std::fs::File; use std::io::BufReader; use std::io::Read; use std::path::Path; fn main() { let pat


Drop flags on the stack not reinitialized in loops | It looks like that when a local variable is initialized in a loop and dropped in the same loop, the stack local drop flag for that local isn't reinitialized to "not dropped" when the loop runs after the first time. Concretely, this test passes on stable and fails on nightly right | labels: T-compiler


rustc does not add the LIBPATH for ucrt.lib to the MSVC command line. | When `cargo build` is used outside of an VS2015 {x86,x64} Native Tools Command Prompt, I receive this error during linking: `rustc: LINK : fatal error LNK1104: cannot open file 'ucrt.lib'` in librustc_trans/back/msvc/mod.rs: ``` rust // The MSVC linker uses the LIB environment va


conflicting implementations when attempting to `impl<S> Into<S> for ArbitraryStructWithNoOtherImpls<S>` | At the very least (if this failure is expected), the error needs to be improved to actually point to the conflicting impl rather than simply printing the crate name and repeating the same function output that conflicts (if it is for some reason not possible to print better info a | labels: C-enhancement, A-diagnostics, P-low, T-lang


Rustbook isn't stripping %'s | https://doc.rust-lang.org/nightly/adv-book/ and https://doc.rust-lang.org/nightly/book/ Show the title rendered twice, once as a header, once as `% ...`


Allow late environment capture for closures | I suggest to allow a closure to capture their environment either at its call site or whenever a reference to the closure leaves the scope in which it can access the environment. This would allow the following code which is a very common use case of lambdas and is currently reject


Poor report of macro_rules! error message | rustc 1.3.0-dev (04badd6a9 2015-07-25) A macro_rules! syntax error reported at expansion site instead of macro definition: ``` macro_rules! sum { ($h:expr) => $h; ($h:expr, $($t:expr),*) => ($h + sum!($($t),*)); } fn main() { let i = sum!(2,3,4); println!("{}", i); } ``` Error me | labels: A-diagnostics, A-macros


Bikeshed "The Advanced Rust Programming Language" as a name | @dherman suggested this iirc -- but I can't remember. @brson is concerned that it is too similar Originally it was called _The Unsafe Rust Programming Language_ since it largely focuses on unsafe code and the stuff that matters to it.


Weird statement macro expansion | ``` rust macro_rules! e { () => ( drop(1) drop(2) ) } fn main() { e!(); } ``` This is currently accepted; I would normally expect it to complain about a missing semicolon, or something like that. | labels: A-macros


[wish list] Confusing error message E0308 when using two diff versions of a library | I came across this confusing error message: ``` src/main.rs:17:37: 17:67 error: mismatched types: expected `&nalgebra::structs::vec::Vec3<f32>`, found `&nalgebra::structs::vec::Vec3<f32>` (expected struct `nalgebra::structs::vec::Vec3`, found a different struct `nalgebra::structs


Option<T> `map_or` and `map_or_else` type is inconsistent with `map` | `map` method type is ``` fn map<U, F>(self, f: F) -> Option<U> where F: FnOnce(T) -> U ``` `map_or` method type is ``` fn map_or<U, F>(self, default: U, f: F) -> U where F: FnOnce(T) -> U ``` `map_or_else` method type is ``` fn map_or_else<U, D, F>(self, default: D, f: F) -> U wh


Is there plan to add `Result<T, E>.expect_err` method? | `Result<T, E>` has `unwrap` and `expect` method yielding `Ok`, but only has `unwrap_err` yielding `Err`, there isn't `expect_err` method.


`move_val_init` signature change broke freebsd32 build | I don't quite understand what's going on here, but it looks like intrinsics changed under us. From [`freebsd10_32` build 151](http://buildbot.rust-lang.org/builders/auto-freebsd10_32-1/builds/151/steps/compile/logs/stdio): ``` rustc: i686-unknown-freebsd/stage0/lib/rustlib/i686-u


Getting started in the book should state how to get a backtrace | This is the most annoying and most useless error message ever if you don't know how to get a backtrace. The docs should state how to get one. Without a backtrace it's only helpful if you already know where the error isn't always the case. This: ``` rust vec![1, 2][7]; ``` Returns


Confusing Error Message When Doc Comment inside Array | Probably a few other places where it's also confusing. Should probably state something like 'unexpected doc comment. A doc comment must precede an item`. ``` rust fn main() { let a = [1.0, 1.0 /** b */, 1.0]; } ``` ``` <anon>:1:31: 1:39 error: expected one of `,`, `.`, or an oper | labels: A-diagnostics


match of associated_const from const_fn | I am using an associated constant in a match pattern. The associated constant was initiated with a const function. https://play.rust-lang.org/?gist=0a3ce02daba0b2226cac&version=nightly ``` rust #![feature(associated_consts, const_fn)] struct A(u32); impl A { const fn new() -> A { | labels: I-ICE, A-associated-items


Invalid error (E0425) reported | In the following code: ``` Rust fn main() { let foo = 42u32; const FOO : u32 = foo; } ``` We have the following errors: ``` Shell <anon>:3:23: 3:26 error: attempt to use a non-constant value in a constant [E0435] <anon>:3 const FOO : u32 = foo; ^~~ <anon>:3:23: 3:26 error: unreso | labels: A-diagnostics, E-needs-test


the type placeholder `_` is not allowed within types on item signatures should hint at generics | The following signature yields the mentioned error ``` rust fn shuffle(args: Vec<_>) -> Vec<_> ``` it should be replaced by ``` rust fn shuffle<T>(args: Vec<T>) -> Vec<T> ``` There should be an error hint suggesting this change. | labels: C-enhancement, A-diagnostics, P-medium, E-medium, D-newcomer-roadblock


VecMap Debug implementation should use debug_map | Right now, it doesn't support pretty printing as a result.


compiler error on crate hyper 0.6.6 (solicit v.0.4.0) | I just tried to include extern crate hyper = "*" -> 0.6.6 when crate starts building there is an internal compiler error: Cargo.toml [dependencies] hyper="*" $ rustc --version rustc 1.3.0-nightly (freebsd) $ cargo build Compiling solicit v0.4.0 src/libcore/iter.rs:804:35: 804:42  | labels: I-ICE


Warn on redundant 'as Foo' statements | ``` rust fn main() { let x: i8 = 42; let y: i8 = x as i8; println!("y: {}", y); } ``` This doesn't generate any warnings from rustc, even though the `as i8` is redundant here. I bump into this occasionally when refactoring, so it would be nice if rustc could help find these sitau


rustc panics if the terminal's terminfo is invalid | If the terminfo for my terminal is malformed, rustc panics with ``` thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `0`, right: `2`)', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libterm/terminfo/parser/compiled.rs:315 ``` The | labels: A-frontend, E-needs-test


Defining a public method on a private type alias causes linking failures | Suppose we have a crate named `c`. **src/lib.rs**: ``` rust pub struct A<T>(T); type B = A<()>; impl B { pub fn new() -> Self { A(()) } } ``` ``` text src/lib.rs:5:5: 7:6 warning: method is never used: `new`, #[warn(dead_code)] on by default src/lib.rs:5 pub fn new() -> Self { sr


ICE when comparing two *const Trait for equality | Hey all, I'm trying to see if two &Trait refer to the same object. It sounds like the correct way to do this is by casting to `*const Trait` and comparing those pointers for equality, however this produces an ICE. Here's a simple [repro on playpen](http://is.gd/c4UIFd) and pasted | labels: I-ICE


poor error message when casting from fat raw pointer to usize | [playpen](https://play.rust-lang.org/?code=trait%20Num%20%7B%7D%0Aimpl%20Num%20for%20i32%20%7B%7D%0A%0Afn%20main%28%29%20%7B%0A%20%20%20%20%260i32%20as%20*const%20Num%20as%20usize%3B%0A%7D%0A&version=beta) ``` rust trait Num {} impl Num for i32 {} fn main() { &0i32 as *const Num  | labels: E-easy, A-diagnostics


Entry point `_ZSt24__throw_out_of_range_fmtPKcz` not found in `libstdc++6.dll` | I cloned and compiled https://github.com/steveklabnik/rustbook on Windows 32bits. When trying to run the `rustbook.exe` executable, I get an error about entry point `_ZSt24__throw_out_of_range_fmtPKcz` not found in `libstdc++6.dll` (the exact message is in french for me). Happens


Rust assumes PATH_MAX is not a lie in a few places | See http://insanecoding.blogspot.ca/2007/11/pathmax-simply-isnt.html for some background. Basically, `PATH_MAX` just doesn't work. Currently. Rust uses `PATH_MAX` in a few important places. ./src/libstd/sys/unix/fs.rs:377:`let mut buf = vec![0;libc::PATH_MAX as usize];` ./src/lib | labels: P-medium


Compiler segfault / illegal instruction: llvm: Assertion `Ty && "Invalid GetElementPtrInst indices for type!"' failed. | ## Environment #### Local Environment ``` Darwin genesis.local 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64 rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14) ``` #### Playpen Environment This was tested 01/07/20 | labels: I-ICE


Warn for functions that should 'obviously' be unsafe | As a noob writing FFI code I have more than once made a mistake something like this ``` rust fn foo(pointer: *const u32) -> u32 { unsafe { *pointer + 1 } } ``` Clearly `foo()` should have been marked unsafe, as a caller can demonstrate by writing the following safe code: ``` rust


Possible error about variance in the nomicon | [In the paragraph about the variance of `&mut T`](https://github.com/rust-lang/rust/blame/master/src/doc/tarpl/subtyping.md#L97) > (...) If `&mut T` was variant over T, then `&mut &'a str` would be a subtype of `&mut &'static str`, > **since `&'a str` is a subtype of `&'static st


trim and related giving unexpected behavior on strings with many nulls | ``` #[test] fn validate_trim() { let s: &str = "QUIT\r\n"; let s2: &str = "\x51\x55\x49\x54\x0d\x0a"; let buf: [u8; 6] = [ 81u8, 85u8, 73u8, 84u8, 13u8, 10u8 ]; let buf2: [u8; 16] = [ 0x51u8, 0x55u8, 0x49u8, 0x54u8, 0x0Du8, 0x0Au8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ]; let input: &str


io::Take's BufRead::fill_buf always attempts to fill the inner buffer | Even if self.limit is 0, fill_buf will attempt to read from the underlying BufRead, possibly causing additional blocking read(2) calls from split/read_until/etc: ``` use std::os::unix::io::FromRawFd; use std::fs::File; use std::io::BufReader; use std::io::BufRead; use std::io::Wr


Stabilization of weak pointers | Currently, both `alloc::rc::Weak` and `alloc::arc::Weak` are unstable. The somewhat vague reason for this is that _weak pointers may not belong in this module_. Now this has been addressed multiple times in #24028 and I have been observing this situation for a few months. However


std::ptr::null() should perhaps use `llvm::ConstantPointerNull` rather than `0 as *const T` | - http://llvm.org/docs/doxygen/html/classllvm_1_1ConstantPointerNull.html But I know of no platform where `0 as *const T` is wrong! Maybe not that important... - http://stackoverflow.com/questions/12126252/what-does-nvidia-gpu-do-with-device-memory-0x0 - https://software.intel.co


link_section attribute seems to be broken | I compile the code below: ``` rust #[link_section = ".multiboot_header"] pub static MULTIBOOT_HEADER: multiboot::Header = multiboot::Header { magic: multiboot::HEADER_MAGIC, flags: HEADER_FLAGS, checksum: (-((multiboot::HEADER_MAGIC + HEADER_FLAGS) as i32) as u32), header_addr: 0


Compiler outputs error in pieces, creating spaghetti output. | Output: ``` $ cargo test -- --nocapture Compiling unrar v0.1.0 (file:///Users/danyel/workspace/rust/unrar) src/archive.rs:151:17: 151:21src/archive.rs:151:17: 151:21 error: error: expected one of `!`, `.`, `::`, `;`, `{`, `}`, or an operator, found `Some`expected one of `!`, `.`, | labels: A-diagnostics


docs: add `meta` to the list of valid designators | The documentation [says](https://doc.rust-lang.org/reference.html#macro-by-example): > Valid designators are item, block, stmt, pat, expr, ty (type), ident, path, tt (either side of the => in macro rules). `meta` is presumably a valid designator as well. Regards, Ivan


into_ascii_lowercase shouldn't be deprecated | We really really need it for performance in Servo.


Expressions involving blocks do not parse well | ``` rust 0; // OK 0 + 1; // OK {0} + 1; // Error: unexpected token: `+` ({0} + 1); // OK ``` @copy and @durka found this issue on IRC. I baked cookies for them! Also, @tsion found this interesting corner case: ``` // Is `*` a multiplication? Or a dereference? Currently it parses


A block evaluated as a function is not directly callable | ``` rust fn f() {} f(); // OK {f}(); // Error: expected `()`, found `fn()` let a = {f}; a(); // OK ``` Another corner case found here! | labels: A-diagnostics, C-bug


Link failure due to exporting function with a non-exported return type | This code snippet causes a link failure. I am guessing it is because the return type of foo is not publicly exported from the crate it is causing a link failure in the test. I tried this (reduced) code: lib.rs ``` rust mod helper { pub struct Foo; impl Foo { pub fn baz(&self) { }


ICE in borrow checker | https://play.rust-lang.org/?gist=23de822c03921663ae66&version=nightly . Error message: ``` <anon>:110:25: 110:60 error: cannot assign to `*entry` because it is borrowed <anon>:110 *entry = FragmentRepr::Enum(discrs); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ note: in expansion of if le | labels: I-ICE, A-borrow-checker


Overflow error for valid trait implementation | Playpen: https://play.rust-lang.org/?gist=8e86843e775a046c9cb7&version=stable AFAICT, the impl shouldn't cause an overflow error. | labels: A-trait-system


Internal compiler error with &[[bool]] | Hi! When I was writing my own version of Game of Life, I made new function which caused message: ``` C:\Users\User\projects\testi2>cargo build Compiling testi2 v0.1.0 (file:///C:/Users/User/projects/testi2) ... some warnings... error: internal compiler error: unexpected panic not


buggy code generated when initializing a [Vec<_>;..] | The following code non-deterministically either works, goes into an infinite loop, or seg-faults, on both my mac environment and on https://play.rust-lang.org/, in all three channels. However, only in Debug mode -- it works fine in all three cases in Release. It also works fine i


rustc produces N^2 error messages for multiple mutable borrows | ``` rust fn main() { let mut x = 1; let mut addr; loop { match 1 { 1 => { addr = &mut x; } 2 => { addr = &mut x; } 3 => { addr = &mut x; } 4 => { addr = &mut x; } 5 => { addr = &mut x; } 6 => { addr = &mut x; } 7 => { addr = &mut x; } 8 => { addr = &mut x; } 9 => { addr = &mut x; | labels: A-diagnostics


ICE when attempting to borrow non-existent item associated with type for argument | The following code generates an internal compiler error: ``` rust struct Mozilla; fn some_function(c: &Mozilla) {} fn main() { some_function(&Mozilla::PHANTOM); } ``` As far as I can tell: - One must be attempting to borrow (`&`) the value - It must be a non-existent name associa


Borrow checker gets confused with a mutable pointer which should be moved | ``` rust pub struct FragmentRepr(Vec<FragmentRepr>); pub fn accepted(mut entry: &mut FragmentRepr) { loop { let FragmentRepr(ref mut discrs) = *{entry}; entry = &mut discrs[0]; } } pub fn rejected(mut entry: &mut FragmentRepr) { loop { let FragmentRepr(ref mut discrs) = *entry; e | labels: A-borrow-checker, C-bug, fixed-by-NLL


unescaped quotation marks in macro-processed doc comments | It seems like one of the recent fix to macro handling of doc comments (perhaps [this](https://github.com/rust-lang/rust/pull/26777)) was a bit overzealous in not parsing the string, so that embedded quotation marks don't get escaped. It doesn't show up unless `stringify!` is call | labels: T-rustdoc


rust-release-1.1.0 cannt configure on osx 10.11(beta 4) | the ./configure output is : configure: looking for configure programs configure: found program cmp configure: found program mkdir configure: found program printf configure: found program cut configure: found program head configure: found program grep configure: found program xarg


is_instantiable check is broken by nested types | ## STR ``` Rust struct Foo<T>(T, Box<Bar<Bar<Foo<T>>>); struct Bar<T>(T); fn main() { println!("Hello, world!"); } ``` ## Results `Foo` is uninhabitable, but the uninhabitability error doesn't trigger. Removing one of the `Bar`-s does make it trigger. This is rather suprising. Th | labels: I-needs-decision, T-lang


still some unneeded integer suffixes in the docs | I noticed recently that the FFI chapter still has `1u32` in places, from before integer fallback existed. That, along with any other suffixes, should be removed. (I'm not sure how many there are, exactly, but looking around for more while those get fixed is a Good Idea)


PathBuf set_extension returns bool, builder pattern impossible | I think that returning bool when calling `set_extension` is weird because it breaks the builder pattern that you have with most other methods. For example I wanted to use it in my project, I have to change the extension from `.md` to `.html`. My first try was to do it like this:


"Concurrency" section comes before "Traits" in TRPL | The [Concurrency](http://doc.rust-lang.org/nightly/book/concurrency.html) chapter of TRPL gives some background on `Send` and `Sync`, describing them as traits and giving a summary of their properties and how they allow preservation of memory safety in a concurrent context. But t


repr C newtype for empty enum | It's currently legal to define the following type, even though `repr(C)` on empty enums is forbidden. ``` rust enum No {} #[repr(C)] struct Yes(No); ``` | labels: A-type-system


Missing information when spanning E0282 | The function call note_obligation_cause seems to be missing after [this line](https://github.com/rust-lang/rust/blob/master/src/librustc/middle/traits/error_reporting.rs#L349-L352) but is present [here](https://github.com/rust-lang/rust/blob/master/src/librustc/middle/traits/erro | labels: A-diagnostics


Failing debuginfo test | The test that was restored in #27500 fails for me: ``` failures: ---- [debuginfo-gdb] debuginfo/gdb-pretty-struct-and-enums.rs stdout ---- NOTE: compiletest thinks it is using GDB version 7.7 error: line not found in debugger output: $13 = Some = {"abc"} status: exit code: 0 comm | labels: A-debuginfo, T-compiler, C-bug


Add `ByNeed` and `Predicate` traits | #18424 "Implement collections reform" was closed with one part left not implemented yet: > Tracking issue for rust-lang/rfcs#235, there are a number of sub-issues associated with this: > > [...] > > Backwards compatible changes that will require additional language features: > -  | labels: B-RFC-approved, T-libs-api


Bad span for self type | The high end of the span of `&SomeType` in ``` rust trait Foo { fn handler(self: &SomeType); } ``` is incorrectly set to `BytePos(0)`. | labels: A-diagnostics, A-trait-system, E-needs-test


docs: clarify `PhantomData` vs "phantom types" statement | In the documentation for [`PhantomData`](https://doc.rust-lang.org/stable/core/marker/struct.PhantomData.html), it states that: "Though they both have scary names, PhantomData<T> and "phantom types" are unrelated." This seems to not be an accurate description of the relationship


Docs: nomicon: missing word in send-and-sync.md | In `send-and-sync.md`, there is a sentence where some word(s?) seem to be missing: > This means that they are unsafe to implement, and other unsafe code can that they are correctly implemented. (I suppose it's something like "other unsafe code can ASSUME that..."?) r? @Gankro PS:


Nullable field optimization does the Wrong Thing when faced with associated types | ## STR ``` Rust use std::mem; trait Mirror { type Image; } impl<T> Mirror for T { type Image = T; } struct S1<T>(<T as Mirror>::Image); struct S2<T>(T); fn main() { println!("with: {}", mem::size_of::<Option<S1<&u8>>>()); println!("without: {}", mem::size_of::<Option<S2<&u8>>>())


Document interaction of std APIs with OS syscalls | @aturon and I have long had the desire to audit all of our various `std::{io, process, env, fs, os}` APIs with what they're actually doing on all platforms. This is very helpful for getting more information about the precise semantics of the API in various corner cases as well as


Rust does not dynamically export functions in Android shared library | I've been trying to compile Rust for Android and call exported JNI functions directly from Java, without a C++ shim in between. I found that if I marked a function as `#[no_mangle] pub extern "C"` it would show up in the symbol table just like JNI exported functions in C++, but i | labels: O-android


Rustc produces bad binaries on Fedora 14, Centos 6.6, 32 bit | I think it's because of the TLS setup not working properly Here's a (sorry, screenshot) of vimdiff of readelf of a working and non-working binary https://i.imgur.com/zfdDYss.png -- Both compiled with the same rustc binary, but different host OSes. I believe this is related to htt | labels: T-libs-api


Explicit OIBIT impls hide the default impls | ``` rust #![allow(dead_code)] trait Foo {} struct A<T>(T); unsafe impl<T: Foo> Sync for A<T> {} // Comment this line and the code compiles trait IsSync: Sync {} struct X; impl IsSync for A<X> {} // error: the trait `Foo` is not implemented for the type `X` [E0277] fn main() {} `` | labels: A-type-system, A-trait-system, P-medium, T-lang


Misleading "unused" warning message | We got the following warning message: ``` Shell warning: variant is never used: `Foo`, #[warn(dead_code)] on by default ``` For this code: ``` Rust enum Something { Foo, NotFoo } fn main() { match Something::NotFoo { Something::Foo => {} _ => {} } } ``` This warning could mislead | labels: A-lints


Span output should be shortened to three lines (w/ ellipsis) unless --verbose | The compiler reports spanned warnings and errors with the full span of the responsible code. While that makes it abundandly clear where the error arose, it also makes the output very verbose by default. Since we have a `--verbose` command line flag, I propose that the compiler sh | labels: A-diagnostics


Invalid error message for E0423 | Example: ``` Rust struct Foo { x: u8 } println!("{:?}", Foo); // error: `Foo` is a structure name, but this expression uses it like a function name ``` The error message is incorrect. | labels: A-diagnostics


pretty test should not specify --crate-type=lib when typechecking | Since the early days of pretty tests (77be30fa737c6b55faf3a52fbd2050f5b35ebb02) they were compiled as libraries so that they did not require a main function. By now they also run on all the run pass test, which all have a main and there is (or soon will be) at least one run pass


End of macro invocation before expected produces EOF | ``` rust fn main() { let message = "world"; println!("Hello, {}", message/); } ``` This gives the following compile error: ``` <anon>:3:34: 3:35 error: unexpected token: `<eof>` <anon>:3 println!("Hello, {}", message/); ^ ``` I think this is slightly misleading: it's not an EOF a | labels: C-enhancement, A-diagnostics, A-parser, A-macros


mem::transmute is too restrictive | Because `mem::transmute` checks its constraints before monomorphization, it fails for types containing fields whose type is determined by a generic parameter: > cannot transmute to or from a type that contains unsubstituted type parameters It's great that it attempts to catch err


Tracking issue for the `use_group_as` RFC | Tracking issue for rust-lang/rfcs#1219. Intention is to permit syntax like: ``` rust use std::io::{ Error as IoError, Read, Write } ``` the semantics of which are fairly self-explanatory. | labels: B-RFC-approved


Projections, lifetimes, and WF tracking issue (RFC 1214) | ### Tracking issue for rust-lang/rfcs#1214 - [x] rust-lang/rust#26406 - [x] ~~rust-lang/rust#24622~~ - [x] ~~rust-lang/rust#23442~~ - [x] ~~rust-lang/rust#21748~~ - [x] ~~rust-lang/rust#25692~~ - [x] ~~rust-lang/rust#21953~~ - [x] ~~rust-lang/rust#27592~~ - [ ] Just take implied  | labels: A-type-system, B-RFC-approved, T-lang, T-compiler, C-tracking-issue, S-tracking-needs-summary


Leading plus for string to integer parsing | The `parse::<i32>()` function (and all its cousins for other integer types) fail for strings starting with a `+` with `ParseIntError { kind: InvalidDigit }`. Failing snippet: ``` fn main () { assert_eq!("+42".parse::<i32>().unwrap(), 42); } ``` The same error occurs with the symm | labels: P-low, I-needs-decision, T-libs-api


Redundant mut checking does not work for lazily initialized variables | The following piece of code contains a redundant `mut`, but triggers no warning: ``` rust fn main() { let mut a; a = 13; println!("{}", a); } ```


Apparent regression in implied bounds | In the RFC 1214 branch, I found that at some point after a rebase (where a new snapshot was introduced), a new implied bound was needed. I believe this is specific to stage0, but I am not sure. I didn't have time to minimize or dig deeply, so i've marked the offending bound for n | labels: A-type-system


Tracking issue for `read_exact` (RFC #980) | https://github.com/rust-lang/rfcs/pull/980 | labels: B-RFC-approved, T-libs-api, final-comment-period


The Rust Reference - no mention of #[cfg(target_env)]. | Title says it all. cc @steveklabnik


Docs: & in colored method signatures not rendered correctly on chrome in windows 10 | When rendering [the documentation to any standard library class](https://doc.rust-lang.org/std/collections/struct.LinkedList.html) with Chrome Version 44.0.2403.130 m (64-bit) - the latest release on Windows 10, the & character is obviously not rendered correctly, as demonstrated | labels: T-rustdoc


v1.2.0 error when building rustc for ios targets | Cannot seem to get the same targets to compile on v1.2.0, with the same commands used for v1.1.0 ``` bash git clone git@github.com:rust-lang/rust.git cd rust git checkout 1.2.0 ./configure --target=armv7-apple-ios,armv7s-apple-ios,i386-apple-ios,aarch64-apple-ios,x86_64-apple-ios


[Nightly 1.4.0-4f33e43cb 2015-08-05] Compiler panic when mis-using Zero trait | Attempting to misuse a trait can cause a compiler panic. The offending code is a simplified version of what I was working on. I tried this code: ``` fn rem_is_zero<T: Eq + Rem + Zero>(n: T, m: T) -> bool where <T as Rem>::Output: Zero + Eq { let z = <T as Rem>::Output::zero(); // | labels: I-ICE, regression-from-stable-to-nightly


format_args! returned from a closure causes corruption/crash | The following code causes an abort in the generated executable, due to a bad jump in `::std::fmt::write` (indirect call to 0x1) This is present on stable, beta, and nightly, both with and without optimisation on. (from my tests in playpen) ``` rust fn write<'a, F: ::std::ops::FnO | labels: A-type-system


Error message for mutating field of immutable struct could be clearer | ``` rust struct Foo { pub v: Vec<String> } fn main() { let f = Foo { v: Vec::new() }; f.v.push("cat".to_string()); } ``` The above code gives this compile error: ``` rust <anon>:8:5: 8:8 error: cannot borrow immutable field `f.v` as mutable <anon>:8 f.v.push("cat".to_string()); ^ | labels: A-diagnostics


False negative comparing targets with equivalent paths | Imagine a directory structure such as: ``` ├── main.rs ├── target.json ├── libthing/ │ ├── lib.rs ``` Where `main.rs` depends on the separate crate `thing` ``` cd libthing/ && rustc lib.rs --target ../target.json rustc main.rs --target target.json --extern thing=libthing/libthing


broken links in nightly docs search result | Searching https://doc.rust-lang.org/nightly/std/ for something from the `collections` module (i.e. `into_boxed_slice` produces links to the documentation of `core_collections::...` as well as `collection::...`, where the `core_collections::...` entries are listed first and more i | labels: T-rustdoc


std implementation of panic might not detect double panicking | Implementation of `std::panicking::on_panic` may panic and not detect it is double-panicking, entering endless loop of panicking and overflowing stack.


Backport #27582 to beta | #27582 Needs to be back ported (I'm on a mobile device, and I forgot our protocol for nominating back ports. Just wanted to ensure this doesn't fall through the cracks.)


Shift operators: signed RHS, Wrapping impl | **1. Shift operators are defined for signed RHS types** The following fails to compile: `1u32 << -1i32`; this compiles: `let i = -1i32; 1u32 << i` but panics due to overflow in debug mode and evaluates to `0` or `2147483648` in release mode, depending on whether the `u32` value i


thread 'rustc' panicked at 'assertion failed: index.end <= self.len()', ../src/libcore/slice.rs:544 | $ rustc --version rustc 1.2.0 (082e47636 2015-08-03) $ RUST_BACKTRACE=1 cargo build error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONT


Confusing error message when using arithmetic operators on different number types | ``` rust fn main() { let x : f32 = 1.0; let y = x / 10; //error: the trait `core::ops::Div<_>` is not implemented for the type `f32` } ``` The error message is confusing because it reads as though you cannot divide `f32`s at all when the real issue is that you can't divide a `f32 | labels: A-diagnostics


When are we getting the "more general mechanism" for struct inheritance | Aka virtual structs, [this](https://github.com/rust-lang/rfcs/blob/master/text/0341-remove-virtual-structs.md), although relatively old, said that there might be a general mechanism in the future. When is the future and what is the general mechanism?


Rustdoc should display the `since` version for stable items | You can't tell when something like `FromRawFd` was stabilized without going into the source: https://doc.rust-lang.org/stable/std/os/unix/io/trait.FromRawFd.html | labels: T-rustdoc


Wrong "Private type in exported type signature" error | Consider this code: ``` rust mod a { pub mod x { pub fn return_x() -> ::X { ::X } } } struct X; fn main() { let _value = a::x::return_x(); } ``` It fails to compile with the following error: ``` test.rs:3:30: 3:33 error: private type in exported type signature test.rs:3 pub fn re


std::sync::Once has way more barriers than necessary | I believe that (comments removed) ``` rust pub fn call_once<F>(&'static self, f: F) where F: FnOnce() { if self.cnt.load(Ordering::Acquire) < 0 { return } let prev = self.cnt.fetch_add(1, Ordering::Acquire); if prev < 0 { self.cnt.store(isize::MIN, Ordering::Release); return } le | labels: I-slow, C-enhancement, T-libs-api


Borrow checker overly conservative when assigning to a parent reference | Consider the following simplified testcase. This is some Rust translation of the C idiom `while ((p = p->next))`. ``` struct List { next: Option<Box<List>> } fn bar(p: &mut List) { let n = match (*p).next { Some (ref mut q) => &mut **q, None => p }; bar(n); } ``` The code compile


borrowck is unsound in the presence of `&'static mut`s | ## STR ``` Rust use std::mem; fn leak<T>(mut b: Box<T>) -> &'static mut T { // isn't this supposed to be safe? let inner = &mut *b as *mut _; mem::forget(b); unsafe { &mut *inner } } fn evil(mut s: &'static mut String) { // create alias let alias: &'static mut String = s; let inn | labels: T-lang


Intermittent with backtrace-debuginfo.rs | http://buildbot.rust-lang.org/builders/auto-linux-32-opt/builds/6036/steps/test/logs/stdio from https://github.com/rust-lang/rust/pull/27617 ``` failures: ---- [run-pass] run-pass/backtrace-debuginfo.rs stdout ---- error: test run failed! status: exit code: 101 command: i686-unkn


btree: Reliance on structure layout | The function `collections::btree::node::Node::as_slices_internal_mut` relies on structure layout of two relatively unrelated structures to be the same, which is considered a bad thing™: ``` #[inline] pub fn as_slices_internal_mut<'b>(&'b mut self) -> MutNodeSlice<'b, K, V> { unsa


configure should make sure that LLVM FileCheck exists | Trying to package rust 1.2 into Debian & Ubuntu, I get the following test failures: ``` running 4 tests test [codegen] codegen/coercions.rs ... FAILED test [codegen] codegen/stores.rs ... FAILED test [codegen] codegen/loads.rs ... FAILED test [codegen] codegen/function-arguments.


TcpStream fails to connect on pre-resolved socket address. | <short summary of the bug> I tried this code: ``` rust use std::net::{TcpStream, ToSocketAddrs}; fn main() { // all good let mut stream = TcpStream::connect("google.ca:80").unwrap(); // resolving the address works let addr = "google.ca:80".to_socket_addrs() .unwrap() // unwrap re


extern crate foo with use self::foo doesn't work inside a function | EDIT (@steveklabnik) see https://github.com/rust-lang/rust/issues/27626#issuecomment-263955318 This code fails and rustc doesn't tell you why: ``` rust fn main() { extern crate rand; use self::rand::Rng; } ``` ([playpen](http://is.gd/xYyadr)) I think it should at least warn, assu | labels: C-enhancement, A-diagnostics, A-resolve


Investigate dynamic Vec growth strategy for jemalloc hugs | Facebook's alternative C++ STL uses a rather dynamic strategy to ostensibly be friendly for common workloads and jemalloc's size classes. While most of FBVector's stuff is hacking around the fact the move/copy constructors are Awful, this seems applicable to us. See: - https://gi | labels: I-slow, C-enhancement, A-collections, T-libs-api


loads.rs & stores.rs tests are failing with LLVM 3.6.1 | ``` ---- [codegen] codegen/stores.rs stdout ---- error: verification with 'FileCheck' failed status: exit code: 1 command: /usr/lib/llvm-3.6/bin/FileCheck -input-file=x86_64-unknown-linux-gnu/test/codegen/stores.ll /home/sylvestre/dev/debian/rustc.git/src/test/codegen/stores.rs s | labels: A-LLVM


Float expressions confusing with trait method calls | ``` fn main() { // Both asserts give: // 'assertion failed: `(left == right)` (left: `-2`, right: `-3`)' assert_eq!( -2.4_f32.floor(), (-2.4_f32).floor() ); assert_eq!( -2.4_f64.floor(), (-2.4_f64).floor() ); } ``` rustc 1.2.0 (082e47636 2015-08-03) binary: rustc commit-hash: 082


index out of range unexpected panic | I tried this code (my little follow up learning rust and ogl) ``` #[macro_use] extern crate glium; extern crate num; extern crate image; extern crate nalgebra; use std::io::Cursor; fn main() { use glium::{DisplayBuild, Surface}; use nalgebra::*; use num::traits::Float; let displa | labels: I-ICE


Add "How to build documentation" section. | It'd be helpful for people who want make documentation pull requests that aren't just typo's to be able to build the documentation, and preview it themselves. Adding a "How To" about how documentation for the main repo should be built, would be helpful.


Improve documentation of std.io.ErrorKind variants | On the [std.io.ErrorKind](http://doc.rust-lang.org/nightly/std/io/enum.ErrorKind.html) documentation page, there's a list of error kinds along with descriptions of what the kinds mean. I personally got confused by what the _new_ variant `InvalidData` actually means from that desc | labels: E-easy


Rust 'const iter' results in 'for'-errors | having the following code ``` rust fn main() { const iter: i32 = 5; for i in 0..10 { println!("{}", i); } } ``` produces the following error: ``` rust src/main.rs:4:5: 6:6 error: type mismatch resolving ` as core::iter::IntoIterator>::IntoIter == i32`: expected struct `core::ops: | labels: A-macros


Exporting a function as main does not work as expected | ``` mod foo { pub fn bar() { } } pub use foo::bar as main; ``` does not compile due to ``` error: main function not found aborting due to previous error ``` The expected behaviour would be that the compiler treats the global symbol `main` which resolves to `foo::bar` as the main


ERROR:rbml::reader: failed to find block with tag 258 while compiling 1.2 for arm-unknown-linux-gnueabi | While compiling rust 1.2.0 on a Ubuntu 15.04 virtualbox VM for arm-unknown-linux-gnueabi, I ran into a panic compiling src/librbml/libs.rs at line [395](https://github.com/rust-lang/rust/blob/master/src/librbml/lib.rs#L395). My configuration and build commands: ``` ./configure -- | labels: I-ICE, A-metadata


x86 MSVC does not use SSE(2) | @cmr noticed this on IRC. [On `i686-pc-windows-gnu`](https://github.com/rust-lang/rust/blob/master/src/librustc_back/target/i686_pc_windows_gnu.rs) and in fact on all other `i686-*` triples (except iOS, which is technically called `i386-*`), a SSE2-capable microarchitecture is as


Note message after error recommends using inaccessible private fields. | The following code: ``` rust pub mod animal { pub struct Dog { pub age: usize, dog_age: usize, } impl Dog { pub fn new(age: usize) -> Dog { Dog { age: age, dog_age: age * 7 } } } } fn main() { let dog = animal::Dog::new(3); let dog_age = dog.dog_age(); //let dog_age = dog.dog_age


Confusing move behavior | ``` rust struct Foo { bar: u32, } fn main() { let mut foo = Foo { bar: 10 }; let foo2 = foo; // <-- moved here foo.bar = 20; // <-- but still works! println!("{}", foo.bar); // <- failed because `foo` has been moved } ```


"Expected operator, found `/`" when passing operator to macro | ``` rust macro_rules! apply_op { ( $op:tt ) => {{ 4 $op 5 }}; } fn main() { let _ = apply_op!(/); } ``` gives: ``` <anon>:2:24: 2:27 error: expected one of `.`, `;`, `}`, or an operator, found `/` <anon>:2 ( $op:tt ) => {{ 4 $op 5 }}; ^~~ ``` The same thing happens for other oper | labels: A-diagnostics


string interpolation | things like: ``` rust let name = "Anton".to_string(); print!("hello {}",name); ``` are very akward and verbose. What about scala-like string interpolation? ``` rust let name = "Anton".to_string(); print!(s"hello $name"); // s is put before string to tell that it is a string inter


Feedback on Rust Vec<T> documentation from a beginner | Was: https://github.com/rust-lang/rust-www/issues/89, from @gnzlbg, submitted January 19th 2015. --- Hi, I just tried rust for the first time. From the description of the language, I decided to try a dynamic array first, since in my head this is the most important data structure


"source trait is private" error with `writeln!` only when `println!` isn't used | This error is related to https://github.com/rust-lang/rust/issues/22050, not sure if it's a dupe. Some of the following code snippets rely on the [term](https://crates.io/crates/term) library (but the issue seems to be in Rust, not `term`). The following builds fine: ``` rust fn  | labels: E-easy, E-needs-test


try!() on iterator element cause compiler crash | When using the try!() macro, directly on an iterator element. The compiler crashes, and fails to tell what is wrong with the code. I tried this code: ``` rust for try!(element) in elements { // Do stuff here } ``` Cargo crashed when attempting to compile the code. Commenting that | labels: I-ICE


Write::write_fmt causes page fault on a bare metal | My experimental code crashes when running on bare x86_64-metal (page fault when IDT is not yet set), but works perfectly on aarch64. By careful tracing I figured out that the cause of this page fault consists of corrupted address (much higher than 0x200_000, while only the first


object-safe traits can have associated types with unchecked bounds | ## STR ``` Rust trait Foo { type Assoc: PartialEq<Box<Self>>; } impl Foo for u32 { type Assoc = Box<u32>; } fn foo<T: Foo+?Sized>(u: Box<T>, v: T::Assoc) -> bool { &v == &u } fn main() { let bar: Box<Foo<Assoc=Box<u32>>> = Box::new(4); foo(bar, Box::new(5)); } ``` ### Result ```  | labels: A-type-system, I-ICE, A-trait-system, P-high, T-compiler, I-unsound


Update installing-rust.md with the newer release response | Currently, when issuing rustc --version, it provides the updated version; namely, rustc 1.2.0 (082e47636 2015-08-03). Update the docs to reflect this.


Strange compile error | My Code is: ``` rust use std::collections::HashMap; use std::path; use std::fs; use std::error::Error; use std::io::{BufReader, BufRead}; use std::ops::Deref; fn read_code_file() -> HashMap<String, String> { let mut airport_codes = HashMap::new(); let path = path::Path::new("Airp


`rustdoc` panics on unicode character inside code-block | `rustdoc` panics on HORIZONTAL ELLIPSIS inside a code-block ... `````` /// ``` /// All those things … /// ``` `````` ... while it accepts them otherwise : ``` /// /// All those things … /// /// > All those things … /// /// ### All those things … /// /// `All those things …` /// `


`--extern` broken for indirect dependencies | alpha.rs ``` rust pub struct Test; ``` beta.rs: ``` rust extern crate alpha; pub use alpha::Test; ``` gamma.rs ``` rust extern crate beta; pub use beta::Test; ``` Now, run the following ``` mkdir -p bin rustc alpha.rs -o bin/libalpha.rlib --crate-type lib rustc beta.rs -o bin/lib


need more coercions for composed iterator types that have Fns | Rust's problems with returning the complicated types that result from iterator composition are well-known. - See e.g. https://github.com/rust-lang/rfcs/pull/105 - (with possible follow-on tracking at https://github.com/rust-lang/rfcs/issues/518 , though most of the conversation s | labels: A-type-system, C-enhancement, A-inference


Unresolved import error on struct vs unite-like struct | ``` rust pub use m::A; mod m { use super::*; pub struct A; //pub struct A { // a: bool //} } ``` The code compile with first definition of A, but not the second. This may be related to #26873.


Adding Deref impl affects lifetime bounds of other methods | From https://users.rust-lang.org/t/does-implementing-deref-affect-the-lifetime-bounds-of-all-other-methods/ --- Code: ~~http://is.gd/AkyE699~~ http://is.gd/AkyE69 If the Deref is removed, the code compiles. Presumably, the inclusion of the Deref implementation on the trait object | labels: A-type-system, A-lifetimes, E-needs-test, T-compiler, C-bug


Tracking issue for allocation APIs | ## Current status Final incarnation of `std::heap` is being proposed in https://github.com/rust-lang/rfcs/pull/1974, hopefully for stabilization thereafter. Open questions for stabilization are: * Is it required to deallocate with the *exact* size that you allocate with? With the | labels: T-libs-api, B-unstable


Tracking issue for libcore + no_std stabilization | This issue is intended to represent the outstanding issues for stabilizing libcore and allowing its usage on stable Rust. There are a number of features currently associated with libcore: - `core` - `core_char_ext` - `core_prelude` - `core_slice_ext` - `core_str_ext` (note that ` | labels: T-lang, T-libs-api, final-comment-period, B-unstable


Tracking issue for f32/f64 support in libcore | This issue is largely targeted at tracking the state of `core_float` in libcore, but it raises the question of how much floating point support should be in libcore. Right now we don't explicitly depend on many external functions, but a number of functions are exposed as bindings  | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for stabilizing randomness | Long ago we had `std::rand` and nowadays we have `extern crate rand`. This is such core functionality it likely wants to move back into the standard library at some point, and in the meantime this issue serves as a tracking issue for the `rand` feature in the standard library. Th | labels: T-libs-api, B-unstable, C-tracking-issue


Tracking issue for OsStr conversions | This is a tracking issue for stabilizing the `convert` feature in the standard library, which is primarily associated with converting `OsStr` and `OsString` to byte or string types. Due to the length of discussions on #27390 and #27657 this will likely required an RFC to move for | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for DNS in std::net | This is a tracking issue for the `lookup_addr` and `lookup_host` unstable features in the standard library. These are currently the only exposed support for DNS as a public interface. Functions like `TcpStream::connect` already expose the ability to resolve names via passing a st | labels: T-libs-api, final-comment-period, B-unstable, C-tracking-issue


Tracking issue for std::fs::canonicalize | This is a tracking issue for the unstable `fs_canonicalize` feature in the standard library. There are a number of reasons it is not currently stable: - The implementation on Unix isn't technically memory safe. - The implementation on Windows returns some quite odd paths which ar | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for fs::walk_dir | This is a tracking issue for the `fs_walk` unstable feature in the standard library. Some of the open questions currently are: - There are many many ways to walk a directory, and there probably wants to be something like a `WalkBuilder` structure. - The current walking strategy h | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `as_unsafe_cell` stabilization | The `Cell::as_unsafe_cell` and `RefCell::as_unsafe_cell` methods return a reference to the underlying `UnsafeCell` in both cases. It's not clear what the use cases are for these methods and whether they can be achieved in some alternative way. If you are using these methods, plea | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for fs::DirBuilder | This is a tracking issue for the unstable `dir_builder` feature in the standard library. The current purpose of this is to provide access to platform-specific options such as modes on Unix or security attributes on Windows. The current `create_dir` and `create_dir_all` APIs are b | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `drain` stabilization | The `drain` method was originally proposed in [collections reform 2](https://github.com/rust-lang/rfcs/pull/509) and then adjusted in a [follow-up RFC](https://github.com/rust-lang/rfcs/pull/574). The main remaining question for the API is the traits it uses to accept various kin | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `fs_mode` stabilization | The `fs_mode` feature refers to platform-specific constants for file access modes exported in `std::os`. While these constants are OK as-is, we don't have a clear overall vision for which constants should be included in `std::os` or how they should be organized. Before we stabili | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for custom hashers in HashMap | This is a tracking issue for the unstable `hashmap_hasher` feature in the standard library. This provides the ability to create a HashMap with a custom hashing implementation that abides by the `HashState` trait. This has already been used quite a bit in the compiler itself as we | labels: A-collections, T-libs-api, final-comment-period, B-unstable


Tracking issue for `str_utf16` stabilization | The `str_utf16` feature tracks APIs like `str::utf16_units` that support utf16 encoding. These APIs are working well today, but it would be good to have a clear picture of the final state of APIs we'd like to have for various string encodings in `std`, and how that relates to oth | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for Scoped TLS | This is a tracking issue for the unstable `scoped_tls` feature in the standard library. The known open questions about this API are: - Is it useful enough to be stabilized? It doesn't look like there's been much usage yet. - Currently the API only accepts sized type parameters, b | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `thread_local_state` stabilization | This feature allows you to query a thread-local variable for its state: http://static.rust-lang.org/doc/master/std/thread/enum.LocalKeyState.html, which will then tell you what may happen if you try to read from the variable. The functionality is somewhat niche, but occasionally  | labels: T-libs-api, final-comment-period, B-unstable, C-tracking-issue


Tracking issue for static synchronization primitives | This is a tracking issue for the unstable `static_mutex`, `static_condvar`, and `static_rwlock` features in the standard library. Each of these represents a separate `StaticFoo` type (next to the type `Foo`) to provide a synchronization primitive that can be constructed in a stat | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `Rc`/`Arc` stabilization | There are a number of unstable features related to `Rc` and `Arc`, including both weak references and uniqueness. An [RFC to remove weak pointers](https://github.com/rust-lang/rfcs/pull/1232) failed, and the current consensus seems to be to stabilize these APIs after nailing down | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `recover` stabilization | The `recover` function is able, on a single thread, to recover from a panic. There are numerous controversies around this API, including the bounds it applies to its closure, its safety, and its location within `std`. An [open RFC](https://github.com/rust-lang/rfcs/pull/1236) see | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for OpenOptionsExt on Windows | This is a tracking issue for the unstable `open_options_ext` feature in the standard library. Currently Unix has a stable extension trait for setting the mode of a file but Windows has not stabilized any of its functionality. The current set of methods on the Windows extension tr | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `path_prefix` stabilization | The `Path::prefix` method allows you to extract a `Prefix` from a path, if any -- which is relevant only on Windows, where the prefix gives e.g. volume information. It's already possible to get this information through the `components` iterator, so it's not clear whether this add | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for {min,max} on iterators | This is a tracking issue for the unstable `iter_cmp` feature in the standard library. This is the ability to get the min or max elements out of an iterator via a custom closure for comparisons. Some open questions are: - Is `_by` the right suffix here? The stable `<[T]>::sort_by` | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `path_ext` stabilization | The `PathExt` trait provides a number of methods on paths that conveniently connect it to the `std::fs` API. While these methods are largely fine, there is some question as to how many of them there should be; the rationale for the exact selection of methods is currently a bit mu | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for access to Formatter alignment | Tracking issue for the `fmt_flags_align` feature, which is [`fmt::Formatter::align`](https://doc.rust-lang.org/nightly/std/fmt/struct.Formatter.html#method.align) and the associated enum. | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period


Tracking issue for `path_components_peek` stabilization | The `path::Components::peek` method allows you to peek at the next component in the iterator without actually consuming it. There's no strong reason for it to remain unstable, except that the conventions around such methods are a bit unclear. | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for formatting with a radix | This is a tracking issue for the unstable `fmt_radix` feature in the standard library. These functions provide the ability to format a number in an arbitrary radix. Note that base 2, 8, and 10, and 16 are already supported via various formatting flags. Needs a decision about whet | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `as_slice` stabilization | Over time, the way that you convert e.g. a vector to a slice has transformed repeatedly. With deref coercions, it's usually implicit, but there are still some cases where you need to do it explicitly. The `as_slice` method follows the usual conversion conventions, but has been so | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `NonZero`/`Unique`/`Shared` stabilization | We currently have three internal types, `NonZero`, `Unique` and `Shared`, that are very useful when working with unsafe Rust code. Ultimately, the hope is to have a clear vision for semi-high-level, but unsafe programming using types like these. None of the current APIs have gone | labels: T-libs-api, B-unstable, C-tracking-issue


Tracking issue for SIMD support | This is a tracking issue for the unstable `core_simd` feature in the standard library. SIMD support is quite a thorny topic, but it's largely covered in https://github.com/rust-lang/rfcs/pull/1199, being implemented in https://github.com/rust-lang/rust/pull/27169, and @huonw will | labels: T-libs-api, B-unstable, A-SIMD, C-tracking-issue, Libs-Tracked, A-target-feature


Tracking issue for DST coercions (coerce_unsized, unsize) stabilization | [DST coercions](https://github.com/rust-lang/rfcs/pull/982) were the last part of DST to land, and are still undergoing [some changes](https://github.com/rust-lang/rfcs/pull/1234). Before stabilization, at the very least the API surface here needs some scrutiny from the libs team | labels: A-DSTs, T-lang, T-libs-api, B-unstable, B-RFC-implemented, C-tracking-issue


Tracking issue for `borrow_state` stabilization | The `RefCell` API offers a way to determine the state of the borrow, to avoid panics on additional borrowing. It's not clear how useful this API is in practice, but it's otherwise ready for stabilization. ----- **EDIT:** @KodrAus Before stabilization: - [ ] Add a concrete, motiva | labels: T-libs-api, B-unstable, C-tracking-issue


Tracking issue for concrete errors in the standard library | This is a tracking issue for the unstable `str_parse_error` and `utf8_error` features in the standard library. Some various small error types popped up once `FromStr` had an associated error type and haven't been considered too closely for stabilization. Some thoughts are: - Are  | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `IntoCow` stabilization | **NOTE**: `IntoCow` has been deprecated, but you can get the same conversion by using the `Cow::Owned` constructor, like so: `Cow::Owned(vec![1, 2, 3])`. # The `IntoCow` trait is a custom conversion trait for working with `Cow`; the custom nature is needed to deal with trait cohe | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for f{32,64}::from_str_radix | This is a tracking issue for the unstable `float_from_str_radix` feature in the standard library. These functions I believe were added to mirror the functionality on integers, but it's unclear what these functions are actually doing in terms of radixes. There's also a [discussion | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for `iter_order` stabilization | The `iter` module has an `order` submodule for performing comparisons on iterators. Ideally, these would instead just be implementations of e.g. the `PartialOrd` trait, but that trait passes by shared reference, and iterators must be mutated to be compared. It'd be good to explor | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for reentrant mutexes | This is a tracking issue for the unstable `reentrant_mutex` feature in the standard library. Currently this flavor of mutex is not exposed at all in the standard library (it's private in the `sys`module), but it's an often-useful form of a mutex. We should decide whether or not t | labels: T-libs-api, B-unstable


Tracking issue for `Zero`/`One`/`iter_arith` stabilization | We currently have `Zero` and `One` traits that are meant to work with `Add` and `Mul` and support iterator operations like `sum`, as well as the current `step_by` API. It would be good to have a more comprehensive vision for this kind of trait before stabilization; an RFC would b | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for std::slice::bytes | This is a tracking issue for the unstable `slice_bytes` feature in the standard library. This module has some various helper methods for dealing with blocks of bytes in an efficient fashion, but they seem particularly one-off and not necessarily fitting in with the rest of the de | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `step_by` stabilization | Update (@SimonSapin): this is now the tracking issue for an iterator adaptor based on `Iterator::nth`: ```rust pub trait Iterator { fn step_by(self, step: usize) -> StepBy<Self> } ``` The `Step` trait used for making ranges iterators is now tracked at https://github.com/rust-lang | labels: P-medium, E-mentor, T-libs-api, B-unstable, E-help-wanted, C-tracking-issue


Tracking issue for slice_splits | This is a tracking issue for the unstable `slice_splits` feature in the standard library. These functions were added in [RFC 1058](https://github.com/rust-lang/rfcs/pull/1058) and implemented in https://github.com/rust-lang/rust/pull/26966. These probably just need to bake for aw | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for str::match_indices | This is a tracking issue for the unstable `str_match_indices` feature in the standard library. This function should largely be good to go except for the note indicating that the returned iterator should probably yield different types of values to stay consistent with other method | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `push_all` stabilization | The `Vec::push_all` method special-cases pushing a slice onto a vector, and historically has performed much better than using `extend` (depending on how LLVM optimizations are working out). We need to offer a method with maximal performance somehow, but ideally this would come fr | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for type_id stabilization | The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period


Tracking issue for `cell_extras` stabilization | The `Ref` type connected to `RefCell` supports some methods for changing the type of the reference, such as `map` and `filter_map`. While `map` is clearly fully general, `filter_map` is somewhat of a special case hooked into `Option`. To make it fully general would likely require | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `slice_concat_ext` stabilization | The [SliceConcatExt](http://static.rust-lang.org/doc/master/std/slice/trait.SliceConcatExt.html) trait offers methods `concat` and `join` on slices. For somewhat technical reasons, it wasn't possible to make these inherent methods. The methods themselves are stable, but the trait | labels: T-libs-api, B-unstable, C-tracking-issue, finished-final-comment-period, disposition-close, A-slice


Tracking issue for `wait_timeout_with` stabilization | The [`wait_timeout_with` method](http://static.rust-lang.org/doc/master/std/sync/struct.Condvar.html#method.wait_timeout_with) allows you to wait on a `CondVar` with a particular timeout, but also to cancel waiting based on a closure you pass in. It's not clear if this API is bro | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `Reflect` stabilization | The `Reflect` trait is currently unstable. It was intended to narrow the use of things like `Any` for runtime introspection, to help retain parametricity properties. However, with [impl specialization](https://github.com/rust-lang/rfcs/pull/1210) these properties would go away an | labels: T-lang, T-libs-api, final-comment-period, B-unstable


Tracking issue for `clone_from_slice` stabilization | The `clone_from_slice` method clones a slice into another, using the `clone_from` method, which in principle can be more efficient than using `clone`. It's not clear whether this method, or `clone_from`, are seeing any use at all. | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `raw` stabilization (`raw::TraitObject`) | The `std::raw` module exports some representation details for the purposes of transmuting and taking things apart. Stabilizing these means pinning down the representation details forever. One possibility is to instead provide various conversions, rather than asking people to use  | labels: A-trait-system, T-lang, T-libs-api, B-unstable, C-tracking-issue, Libs-Tracked


Tracking issue for `float_extras` stabilization | There are a number of floating point methods that are reexported from cmath, without a strong naming convention on the Rust side, or a clear rationale for which methods are included and which are not. Ideally, someone who works with floating point, and these methods in particular | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `num_bits_bytes` stabilization | The `BITS` and `BYTES` constants for e.g. `i32` are currently unstable, due to lack of clarity around: - Should these be associated constants of the type instead? - Is there a better way to get at these via e.g. `size_of`? cc @eddyb | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `str_char` stabilization | The `str` type offers a number of `char`-oriented methods, many of which can be replaced by uses of `char_indices`. It's not clear how widely used these methods are, or whether there are significant downsides over using `char_indices`. This API area needs a comprehensive re-evalu | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for `wrapping` stabilization | The `std::num::wrapping` module provides a trait, `OverflowingOps`, that permits overflowing arithmetic on primitive types and tells whether an overflow occurred. Other methods, like `saturating_add` and `wrapping_add`, are included directly as inherent methods on these types. It | labels: T-libs-api, final-comment-period, B-unstable


Mistaken warning when working around `E0386` restrictions regarding mutable references in immutable containers. | While writing the detailed diagnostics for `E0386` (cannot assign to data in an immutable container, #24407), I came across a possible mistaken warning. `E0386` is about forbidding mutation of a mutable reference stored in an immutable container: ``` rust let mut x: i64 = 1; let


rustdoc unstable should show feature name and issue | rustdoc currently shows unstable things like the following (for [`Result::expect`](http://doc.rust-lang.org/stable/std/result/enum.Result.html#method.expect)): > Unstable: newly introduced It could also include the name of the feature and a link to the tracking issue, e.g. > Unst | labels: E-easy, T-rustdoc


Tracking issue for CStr => str conversions | This is a tracking issue for the `cstr_to_str` unstable feature in the standard library. These methods are probably ready to just get stabilized as-is. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for collection append methods | This is a tracking issue for the unstable `append` feature in the standard library. It's somewhat unclear if these methods _need_ to be stabilized, but it's also fairly clear that they're not going to change from their current form. They will likely go into FCP soon. cc @Gankro. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for collection split_off methods | This is a tracking issue for the unstable `split_off` feature in the standard library. It's somewhat unclear if these methods need to be stabilized, but it's also fairly clear that they're not going to change from their current form. They will likely go into FCP soon. cc @Gankro. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for VecDeque::retain | This is a tracking issue for the unstable `vec_deque_retain` feature in the standard library. This is probably ready to just be stabilized as-is. cc @Gankro | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for Box::{into_raw, from_raw} | This is a tracking issue for the `box_raw` unstable feature in the standard library. These methods are functionally ready to go but may need to settle on some names. Other candidates (like those that `CString` chose) are `into_ptr` and `from_ptr`. These shouldn't be stabilized un | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for CString::{from_ptr, into_ptr} | This is a tracking issue for the unstable `cstr_memory` feature in the standard library. These methods are likely ready to go as-is modulo naming. Their names should be consistent with `Box::{from_raw, into_raw}` (currently inconsistent). cc #27768 | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for Result::expect | This is a tracking issue for the unstable `result_expect` feature in the standard library. This is likely ready to just be stabilized as-is | labels: T-libs-api, B-unstable


Tracking issue for some Duration-taking functions | This is a tracking issue for some small Duration-taking functions in the standard library, specifically the `park_timeout` and `thread_sleep` functions. Now that `Duration` is stabilized these are likely ready to be stable as-is. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for Condvar::wait_timeout | This is a tracking issue for the unstable `wait_timeout` feature in the standard library. An open question here is whether the tuple return value with a `bool` is appropriate or whether an `enum` of some form should be returned instead. cc @sfackler | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for the socket timeout functions | This is a tracking issue for the unstable `socket_timeout` feature in the standard library. Now that the `Duration` type is stable it may be the case that these methods can just be stabilized as-is. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for slice::{ref_slice, mut_ref_slice} | This is a tracking issue for the unstable `ref_slice` feature in the standard library. These functions seem fairly innocuous but it's also somewhat questionable how useful they are. They're probably ready for either stabilization or deprecation as-is. cc @nikomatsakis | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for converting slice iterators to slices | This is a tracking issue for the unstable `iter_to_slice` feature in the standard library. The `into_vec` adaptor for `vec::IntoIter` was recently removed, and these may also want to be removed. It's somewhat unclear how useful it is to have iterators enhanced with this kind of f | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for viewing Result/Option as slices | This is a tracking issue for the unstable `as_slice` feature in the standard library. These functions enable viewing a `Result<T, U>` and `Option<T>` as some form of `[T]` (both shared and mutably). In each case an array of at most one item will be returned. It's somewhat unclear | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for iter::range_inclusive | This is a tracking issue for the unstable `range_inclusive` feature in the standard library. This will likely be deprecated and removed if https://github.com/rust-lang/rfcs/pull/1192 is accepted. Otherwise this will likely be deprecated and removed in favor of a builder-style int | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for FixedSizeArray trait | This is a tracking issue for the unstable `fixed_size_array` feature in the standard library. This is likely to be deprecated and removed in favor of generic integers one day, and in the meantime there are not many consumers of it. | labels: T-libs-api, B-unstable, C-tracking-issue, finished-final-comment-period, disposition-close, A-const-generics


Tracking issue for placement new | This is a tracking issue for the unstable `placement_new_protocol` feature in the standard library, and `placement_in_syntax`/`box_syntax` in the compiler. (@pnkfelix adds below:) Things to decide / finalize before stabilization: - [ ] placement-in syntax, e.g. `in PLACE { BLOCK  | labels: B-RFC-approved, T-lang, T-libs-api, B-unstable, C-tracking-issue


Tracking issue for <*mut T, *const T>::{as_ref, as_mut_ref} | This is a tracking issue for the unstable `ptr_as_ref` feature of the standard library. These functions allow unsafely converting raw pointers to optional safe references, returning `None` if they're null. I would personally vote for removing these, but there's certainly some usa | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for char::from_u32_unchecked | This is a tracking issue for the unstable `char_from_unchecked` feature of the standard library. This API is relatively new and needs some time to bake, but it's likely to just be stabilized as-is. | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for DebugTuple::formatter | This is a tracking issue for the unstable feature `debug_builder_formatter` in the standard library. This method was add relatively recently, and my thoughts on it are: - It seems odd to have this function only on `DebugTuple` and no other builders. - It does seem reasonable to a | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for location of facade crates | We probably don't want to indefinitely have a large number of facade crates which are all unstable, so we should eventually stabilize these crates, fold them back into the standard library, or find a good middle ground in which they can all reside. The current set of crates consi | labels: T-libs-api, B-unstable, C-tracking-issue


Tracking issue for char encoding methods | This is a tracking issue for the unstable `unicode` feature and the `char::encode_utf{8,16}` methods. The interfaces here are a little wonky but are done for performance. It's not clear whether these need to be exported or not or if there's a better method to do so through iterat | labels: T-libs-api, final-comment-period, B-unstable, E-help-wanted


Tracking issue for Box<str>/String conversions | This is a tracking issue for the unstable `box_str` feature in the standard library. These functions were recently added and probably just need to bake for a bit, but other than that I believe they're ready for stabilization (modulo the naming in https://github.com/rust-lang/rust | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for sorted collection ranges | This covers `btree_range` and `collections_bound`. Both try to address the combinatorics over inclusive/exclusive/none bounds on ordered queries. I am significantly unsatisfied with the current solution, which is `btree.range(Bound(&K), Bound(&K))`. This pushes all the combinator | labels: T-libs-api, final-comment-period, B-unstable, E-help-wanted


Tracking issue for VecDeque Extras | This covers the `deque_extras` blanket feature, which should probably be sharded more in the future. It covers: - `truncate` - `resize` - `as_slices` - `as_mut_slices` - `swap_back_remove` - `swap_front_remove` Some notes: - `truncate` and `resize` are strange because they aren't | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for Vec::resize | This is a tracking issue for the unstable `vec_resize` feature in the standard library. To the best of my knowledge there's no blocker for this beyond "we should decide to have it or not". cc @Gankro | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for str escaping | This is a tracking issue for the unstable `str_escape` feature in the standard library. The open questions I know of here are: - Do we want to support these relatively arbitrary ways to escape strings? Note that these same methods for escaping characters are already stable. - Are | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period


Tracking issue for str::split_at | This is a tracking issue for the unstable `str_split_at` feature in the standard library. These are just mirrors of the slice `split_at` methods so I suspect that they will just be stabilized as-is. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for str::slice_mut_unchecked | This is a tracking issue for the unstable `str_slice_mut` feature in the standard library. The major open question here is to what extent we want to support `&mut str` in the standard library. Currently the support is likely falling short in a number of `&str` vs `&mut str` metho | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for extra linked list methods | This is a tracking issue for the unstable `linked_list_extras` methods in the standard library. cc @Gankro, perhaps you can fill this in some more? The specific methods in question are: - `IterMut::insert_next` - `IterMut::peek_next` | labels: B-RFC-approved, A-collections, T-libs-api, B-unstable, C-tracking-issue, Libs-Tracked


Tracking issue for creating BTree{Map,Set} with a B | This is a tracking issue for the unstable `btree_b` feature in the standard library. cc @Gankro, perhaps you can fill in the details here? | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for unix::FileTypeExt | This is a tracking issue for the unstable `file_type_ext` feature in the standard library. I think this is basically good to go, it'll likely expand over time but otherwise it's pretty self explanatory. | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for consumption into OS handles | This is a tracking issue for the `into_raw_os` feature in the standard library which allows consuming I/O primitives to gain ownership of the underlying resource. I believe this is basically ready to be stabilized as-is. | labels: E-easy, T-libs-api, final-comment-period, B-unstable


Tracking issue for sync::Semaphore | This is a tracking issue for the unstable `semaphore` feature of the standard library. - Should we have this kind of semaphore? - Should we allow negative counts? - Should there be an RAII guard for a "resource"? Decision! | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for Duration::span | This is a tracking issue for the unstable `duration_span` feature of the standard library. Known open questions are: - Is this the right place for this API? - Is this the right name? - Should the closure be able to return a value? - Should various other system clocks be exposed? | labels: T-libs-api, final-comment-period, B-unstable


Tracking issue for channel selection | This is a tracking issue for the unstable `mpsc_select` feature in the standard library. Known points: - The API is unsafe, and should probably never be stabilized. - Servo apparently makes very heavy use of this API, so it can't be removed without replacement currently. - The co | labels: T-libs-api, B-unstable, C-tracking-issue, finished-final-comment-period, disposition-close