Use 'mut' as alias for 'let mut' | The idea of shortening `let mut` to `var` has been discussed many times before, and the general consensus always ends up being that it is not a good idea. I would like to propose something a bit different, so please hear me out. I propose that instead of aliasing `var` to `let mu | labels: E-easy, C-enhancement, A-diagnostics, P-medium, E-mentor, T-compiler


f32::NAN as i128 different between miri and LLVM | ``` fn main() { let f = std::f32::NAN; assert_eq!(f as i128, 0x7fffffffffffffffffffffffffffffffi128); // LLVM assert_eq!(std::f32::NAN as i128, 0i128); // miri } ```


Confusing error message when trying to implement From<GenericLocalType<T>> for Option<T> | I have a local type: ```rust #[derive(Debug, Deserialize)] #[serde(untagged)] enum BadOption<T> { Some(T), None(Value), } ``` and I want to `impl<T> From<BadOption<T>> for Option<T>` but the error message suggests that `T` isn't being used as the type parameter for a local type > | labels: C-enhancement, A-diagnostics, T-compiler, D-confusing


Internal compiler error: can't buffer lints after HIR lowering | Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk [#161](https://github.com/baidu/rust-sgx-sdk/issues/161)) to use latest rust nightly compiler to help the error info more ergonomic by the help of #60561. However, the compiler always panics. Your help would be very much h | labels: I-ICE, T-compiler, C-bug, E-needs-mcve


Confusing error now saying `let` (not `if let`) is an expression, rather than a statement, which contradicts the book | cc @Centril Code first. This code: ``` fn main() { let x = (let y = 6); } ``` [on current stable Rust 1.38](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=db087215a59f29b6c19440c89ddb2484), gives this set of error messages: ``` error[E0658]: `let` express | labels: E-easy, A-diagnostics, E-mentor, T-compiler, E-help-wanted, D-confusing


Cleanup: Deduplicate implementations of `is_{freeze,copy,sized}_raw` | See: https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc/ty/util.rs.html#1045 <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_ASSIGN_START --> This issue has been assigned to @mbStavola via [this comment](https://github.com/rust-lang/rust/issues/65259#issuecomment-540370893). <!--  | labels: E-easy, C-cleanup, T-compiler, E-help-wanted


Tracking issue for RFC 2495, "Minimum Supported Rust Version" | This is a tracking issue for the RFC "Minimum Supported Rust Version" (rust-lang/rfcs#2495). **Note:** There is a separate tracking issue on the Cargo side at: https://github.com/rust-lang/cargo/issues/8072 **Documentation**: https://doc.rust-lang.org/cargo/reference/manifest.htm | labels: B-RFC-approved, B-RFC-implemented, T-cargo, C-tracking-issue


rust can still create a danling pointer? | ``` #[derive(Debug)] struct CustomSmartPointer { data: String, } impl Drop for CustomSmartPointer { fn drop(&mut self) { println!("Dropping CustomSmartPointer with data `{}`!", self.data); } } fn main() { let a = CustomSmartPointer { data: String::from("hewitt") }; let mut ptr =


ICE when re-exporting proc macro from renamed crate (wasm32-unknown-unknown) | The compiler panics when trying to re-export a proc-macro, and the crate that contains this macro is renamed in the `Cargo.toml`: ``` my = { package = "my-proc-macro", path = "./macro" } ``` Fails when targeting `wasm32-unknown-unknown`, haven't tested any other targets though. T | labels: A-resolve, I-ICE, A-macros, T-compiler, C-bug


Why the return value was not dropped | ``` #[derive(Debug)] struct CustomSmartPointer { data: String, } impl Drop for CustomSmartPointer { fn drop(&mut self) { println!("Dropping CustomSmartPointer with data `{}`!", self.data); } } fn create_object(name: &str) -> CustomSmartPointer { let a = CustomSmartPointer {data:


Label shadowing causes a warning that cannot be allowed | ```rust macro_rules! m { ($a:expr) => { 'label: for _ in 0..1 { $a; } } } fn main() { m!(m!(1)); } ``` causes the following warning: ``` warning: label name `'label` shadows a label name that is already in scope --> src/main.rs:3:9 | 3 | 'label: for _ in 0..1 { | ^^^^^^ | | | fir | labels: A-lints, T-compiler, C-bug


compiler fails to understand generics | The following code won't simply compile. Is this an intended behavior? ```rust trait Finite { const MAX_CASE: usize; fn identifier(&self) -> usize; } pub struct Array<T: Finite, U>([U; T::MAX_CASE]); ``` minimized code replicating error ```rust trait A { const M: usize; } struct


src/librustc_codegen_ssa/callee.rs is redundant | Per @eddyb, this file contains wrappers which don't do much. It seems like they should perhaps be inlined and the module deleted? | labels: C-cleanup, A-codegen, T-compiler


GDB cast raw pointer to &str | The `&str` type is not available in `rust-gdb`. When debugging using `rust-gdb`, local variables with `&str` type are pretty printed. ``` (gdb) p my_string_local $6 = "my string" (gdb) ptype my_string_local type = struct &str { data_ptr: *mut u8, length: usize, } ``` I expect tha | labels: A-debuginfo, P-medium, T-compiler


request: Make `unix::net::SocketAddr` create methods public | ## Motivation Recently [tokio-rs/mio](https://github.com/tokio-rs/mio/) needed support for creating the `std::os::unix::net::SocketAddr` type. While the type is currently public, it is not possible to create one as both creation methods are private: * [SocketAddr::new](https://gi | labels: T-libs-api, C-feature-request


Inconsistent auto-reborrowing behavior of generic functions | Look at this piece of code: ```rust fn f<T>(x: T, y: T) {} fn main() { let x = &mut 0i32; let y = &mut 1i32; f(x, y); let z = &mut *y; println!("{} {} {}", x, y, z); } ``` From the internet, I get the impression that generic functions will not auto-reborrow if the type of paramet


atomic::Ordering "same as LLVM's"? Seems wrong. | @jonas-schievink [pointed out](https://github.com/rust-lang/rust/issues/32976#issuecomment-540777070) that our `atomic::Ordering` docs say > Rust's memory orderings are the same as LLVM's. That's not really correct though... at least according to the Nomicon, we [use the C11 memo | labels: A-LLVM, T-lang, A-docs, C-bug


E0599 error message may suggest syntactically invalid fix | [Full code in Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3b1a6a68ae4db990762e4a542fbf052a) Missing a trait bound for the trait that defines `fn foo` below: ```rust fn do_stuff<T : Bar>(t : T) { // Note the space before the colon in `T : Ba | labels: T-compiler, C-bug, A-suggestion-diagnostics, D-invalid-suggestion


Incorrect "explicit lifetime name needed" error | ```rust struct Nested<K>(K); trait X<'a, K: 'a> { fn foo<'b, L: X<&'b Nested<K>>>(); } ``` produces: ``` error[E0637]: `&` without an explicit lifetime name cannot be used here --> src/lib.rs:4:19 | 4 | fn foo<'b, L: X<&'b Nested<K>>>(); | ^^^^^^^^^^^^^^^^ explicit lifetime name  | labels: A-diagnostics, A-lifetimes, T-compiler, C-bug


"Consider adding an explicit lifetime bound" doesn't take into account existing bounds | ```rust trait X { fn foo(&self) {} } fn p3<'a, 'b, T: 'b>(v: T) -> Box<dyn X + 'a> where T: X { Box::new(v) } ``` produces: ``` error[E0309]: the parameter type `T` may not live long enough --> src/lib.rs:4:5 | 3 | fn p3<'a, 'b, T: 'b>(v: T) -> Box<dyn X + 'a> where T: X { | -- h | labels: A-diagnostics, T-compiler, C-bug, A-suggestion-diagnostics


Lifetimes are inconsistently printed with backticks | ```rust fn foo<'a>(u: &'a usize) -> impl IntoIterator<Item = usize> + 'a { std::thread::spawn(|| { println!("{}", u); }); vec![] } ``` displays: ``` error: cannot infer an appropriate lifetime --> src/lib.rs:2:24 | 2 | std::thread::spawn(|| { | _____------------------_^ | | | | | | labels: E-easy, A-diagnostics, T-compiler, D-inconsistent


RISC-V: Inline assembly ecall assumes return value in incorrect register | The following 32-bit RISC-V Rust code ```rust pub unsafe fn allow_ptr(major: usize, minor: usize, slice: *mut u8, len: usize) -> isize { let res; asm!("li a0, 3 ecall" : "=r" (res) : "{x11}" (major), "{x12}" (minor), "{x13}" (slice), "{x14}" (len) : "memory" : "volatile"); res }  | labels: A-inline-assembly


compiler error building arrow on rustc 1.40.0-nightly on mac | ```$ ~/code/example cargo build Compiling arrow v0.15.0 error: internal compiler error: src/librustc_traits/normalize_erasing_regions.rs:42: could not fully normalize `fn() -> usize {std::mem::size_of::<<T as datatypes::ArrowPrimitiveType>::Native>}` thread 'rustc' panicked at 'B | labels: I-ICE, E-needs-mcve


Rust platform size (round 2) | Reopening this issue as its not fixed. On my last post in July the size was 294 MB: https://github.com/rust-lang/rust/issues/61978#issuecomment-509259209 comically, its actually larger now at 347 MB: https://static.rust-lang.org/dist/rust-nightly-x86_64-pc-windows-gnu.msi | labels: C-enhancement, T-compiler, I-heavy


`rustc_data_structures::static_assert!(false)` does not error | `1.40.0-nightly 2019-10-09 20cc75272619cc452e3a` The following does not error locally / on the playground https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9dde03338a31e2f40491a66dc3a18761 ```rust #![feature(rustc_private)] extern crate rustc_data_structure | labels: T-compiler, C-bug


Refactor: deduplicate "can this unwind?" logic | Currently, we have two separate codepaths to decide if a function needs an abort-on-panic shim and if it gets the `nounwind` attribute. This risks them getting out of sync -- and indeed they are out-of-sync right now, but there's lots of opposition to fix that critical bug, so I  | labels: C-cleanup, T-compiler


also read cargo.toml | https://doc.rust-lang.org/cargo/faq.html#why-cargotoml ## "Sorting files often puts capital letters before lowercase letters" could you please provide your analysis on how you count "often"? cause its not with coreutils 8.31, `ls`: ``` $> touch foo Foo bar Bar $> \ls bar Bar foo


`cargo check`-invoked Rustc 10x slower since `nightly-2019-10-03` | Starting `nightly-2019-10-03`, Rustc ~~**hangs forever**~~ is about 10x slower while building my project (Linux x86-64). It works fine on `nightly-2019-10-01` and earlier versions. In between, `nightly-2019-10-02` has an ICE. I am only invoking `cargo check`. See below for the IC | labels: T-compiler, C-bug, I-hang, E-needs-mcve


performance of saturating_mul can be improved by removing branches | While playing with `saturating_mul` to see if it can be made branchless and thus a const fn (sorry @RalfJung ;) ), I found that the performance of signed `saturating_mul` can actually be improved. I tested two implementations: 1. ```rust pub fn saturating_mul(a: i32, b: i32) -> i | labels: A-LLVM, I-slow, T-compiler, C-bug


aarch64 windows backend forces panic=abort | The [aarch64-pc-windows-msvc](https://github.com/rust-lang/rust/blob/master/src/librustc_target/spec/aarch64_pc_windows_msvc.rs#L8) and [aarch64-uwp-windows-msvc](https://github.com/rust-lang/rust/blob/master/src/librustc_target/spec/aarch64_pc_windows_msvc.rs#L8) targets force p | labels: A-runtime, C-enhancement, O-Arm, T-compiler, O-windows-msvc


Spurious `...` at the end of code lines on some trimmed code snippets | We now trim overly wide code snippets using `...` before and after as appropriate to signify the cut code. I've observed some cases on spans with labels that the last three characters of the snippet are incorrectly replaced with `...`. | labels: A-diagnostics, T-compiler, C-bug, E-needs-mcve


Messed up docs for std::task::Waker | This should be an easy one, but the docs for `std::task::Waker` look like this: <img width="998" alt="image" src="https://user-images.githubusercontent.com/634666/66693186-3496fc00-ec5b-11e9-9b80-a98609b0d15a.png"> But it should probably just say `Send` and `Sync` not `trait@Send | labels: E-easy, T-libs-api, A-docs, C-bug


reopen https://github.com/rust-lang/rust/issues/52377 for 1.38 rust and it is not appear on 1.37 | i found the https://github.com/rust-lang/rust/issues/52377 bug when used new 1.38.0 rust


Error E0594 is not described in docs | Error E0594 is not described in docs https://doc.rust-lang.org/nightly/error-index.html#E0594 ```rust fn main() { let v = vec![1u16; 10]; let p: &[u16] = &v; p[0] = 3; } ``` ([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9aefb4be4f107328211


Unhelpful error message because of inner line doc | The code ```rust fn main() { let x = 0; let y = x.max(1) //!foo .min(2); } ``` I get this error: ```bash error: expected one of `.`, `;`, `?`, or an operator, found `//!foo` --> src/main.rs:3:22 | 3 | let y = x.max(1) //!foo | ^^^^^^ expected one of `.`, `;`, `?`, or an operator  | labels: C-enhancement, A-diagnostics, A-parser, T-compiler


rustdoc: Prefixing parent modules to distinguish between items in cases where item names would otherwise be ambiguous | ## Motivation I often run into an issue when reading through rendered documentation where many types exist with the same name and it is unclear which type is being referred to in a function signature or type declaration. Two simple, common examples of this are the `Result` and `E | labels: T-rustdoc, C-feature-request


Unnecessary comparison and conditional branch | This is a reopening of #37114 which was fixed in 1.28.0 but seems to have regressed again since 1.30.0. ```rust pub fn foo(v: &mut Vec<i32>) { let len = v.len(); assert!(len > 1); v[len - 2] += 1; v.pop(); } ``` The asm for 1.38 is ```asm example::foo: push rax mov rax, qword ptr | labels: A-LLVM, I-slow, T-compiler, C-bug


3rd party objects missing from nightly-2019-10-12 | ``` $ rustup toolchain add nightly-2019-10-11 $ rustup toolchain add nightly-2019-10-12 $ rustup target add --toolchain nightly-2019-10-11 x86_64-fortanix-unknown-sgx $ rustup target add --toolchain nightly-2019-10-12 x86_64-fortanix-unknown-sgx $ ls .rustup/toolchains/nightly-20 | labels: regression-from-stable-to-nightly, P-high, O-windows-gnu, T-bootstrap, O-musl, C-bug


Tracking issue for "minimize the rust-std component" | This tracks the issue for doing the stuff mentioned in https://github.com/rust-lang/rust/pull/64823. Also relevant: - https://github.com/rust-lang/rust/issues/61978 - https://github.com/rust-lang/rust/issues/62486 - https://github.com/rust-lang/rust/issues/65335 - https://github. | labels: T-bootstrap, T-infra, C-tracking-issue, T-release


rust-lldb fails to load on LLDB 8.0.0 | When I run `rust-lldb` I get the following error: ``` $ rust-lldb target/debug/myprogram (lldb) command script import "/Users/zmitchell/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/etc/lldb_rust_formatters.py" error: module importing failed: loading unimplemented ``` | labels: A-debuginfo, P-medium, T-compiler, T-dev-tools


const fn ICE on nightly | The following ICE's on nightly only: ```Rust struct ArrayType<T>(T); impl <T> ArrayType<T> { const ARRAY: [T; 0] = []; } pub const fn bug<T>() -> &'static T { &ArrayType::<T>::ARRAY[0] } fn main() { bug::<i32>(); } ``` <details> <summary>Backtrace:</summary> ``` [ERROR rustc_mir: | labels: I-ICE, regression-from-stable-to-nightly, T-compiler, C-bug, A-const-eval, glacier


Compiling can take hours. | I've heard that rustc is slow, but I'm actually running into 30 to 120 minute compile times. I only installed rustc yeasterday: rustc 1.38.0 (625451e37 2019-09-23) on Debian Buster. I've tried cloning a couple of game engines from github to compare - Piston, gglz, glium plus a ra


unable to build on windows when "optimize = false" | When "optimize" in `config.toml` is set to `false`, windows build msvc is unable to build properly. It's due to the limitation of 65535 objects in the linker object. see following error: ``` 316abf8bcc4ba1.rlib" "C:\\Users\\guanq\\AppData\\Local\\Temp\\rustcbLuaNn\\libsyntax_pos-


Remove disambiguator from intra doc link text | ```rust /// Trait: [`trait@Name`], fn: [`fn@Name`] pub struct S; pub trait Name {} #[allow(non_snake_case)] pub fn Name() {} ``` This is currently rendered as: > <img src="https://user-images.githubusercontent.com/1940490/66709897-4a232900-ed22-11e9-9069-0ed584e86df5.png" width=" | labels: T-rustdoc, E-medium, C-bug, A-intra-doc-links


`miri` no longer builds after rust-lang/rust#64873 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64873, I observed that the tool miri has failing tests. A follow-up PR to the repository https://github.com/rust-lang/miri is needed to fix the fallout. cc @popzxc, do you think you would have tim | labels: T-compiler


Output filename collisions and ICE with  'cargo doc' on 1.38.0 | ## Summary I was attempting to run `cargo doc --open` at the top level of a Cargo workspace, which resulted in several warnings regarding output filename collisions for `lexical-core`, `proc_macro2`, `quote`, `syn`, and `unicode-xid` (https://github.com/rust-lang/cargo/issues/631 | labels: T-rustdoc, I-ICE, C-bug


Lint `bare_trait_objects` doesn't warn on traits used as types in paths | Example: ```rust trait Method { fn method() {} } trait Tr {} impl Method for Tr {} // warning: trait objects without an explicit `dyn` are deprecated fn main() { Tr::method; // No warning } ``` According to the logic of the lint there should be a suggestion to rewrite `Tr::method | labels: A-lints, T-compiler, C-bug, A-edition-2018