Symbol names may not correctly account for optimization level differences between crates | On investigating https://github.com/rust-lang/wg-cargo-std-aware/issues/32 I've managed to reduce this down to: ``` $ cat foo.rs pub fn foo() { bar::<usize>(); } pub fn bar<T>() { baz(); } fn baz() {} $ cat bar.rs extern crate foo; pub fn bar() { foo::foo(); } $ rustc --crate-typ | labels: A-linkage, A-codegen, T-compiler, C-bug


Incorrect doc for checked_duration_since | "... or None if that instant is earlier than this one" should be "... or None if that instant is *later* than this one" | labels: E-easy, A-docs


Missed niche opportunity in simple nested enum | ``` pub enum Foo { A, B, C, } pub enum Bar { Foo(Foo), D, E, } pub enum Foo2<T> { A(T), B(T), C(T), } pub enum Bar2<T> { Foo(Foo2<T>), D(T), E(T), } fn main() { use std::mem::size_of; dbg!(size_of::<Bar>()); // = 1 dbg!(size_of::<Bar2<()>>()); // = 1 dbg!(size_of::<Bar2<u8>>());


manifest path to bootstrap/Cargo.toml does not exist, when it does | I do not know what is going on when I am building rust from source. what is going on is that I run `python x.py build` and it caches `rust-std-beta-i686-pc-windows-gnu` for whatever reason even though I've set my target in config.toml to be `x86_64-pc-cygwin` so I'd think it shou | labels: T-bootstrap, E-needs-mcve


Ffi safe lint ICE with type alias impl trait | ```rust #![feature(type_alias_impl_trait)] type A = impl Fn(); fn ret_closure() -> A { || {} } extern "C" { fn a(_: A); } fn main() {} ``` ``` error: internal compiler error: src/librustc_lint/types.rs:858: Unexpected type in foreign function thread 'rustc' panicked at 'Box<Any>' | labels: I-ICE, T-compiler, A-impl-trait, C-bug, F-type_alias_impl_trait


Error with -Z time-passes | ``` $ rustc --version rustc 1.39.0-nightly (0b36e9dea 2019-09-09) $ export RUSTFLAGS="-Z time-passes" $ cargo build error: failed to parse the cfg from `rustc --print=cfg`, got: ___ lib___.rlib lib___.so lib___.so lib___.a lib___.so /home/erlend/.rustup/toolchains/nightly-x86_64- | labels: T-compiler


Linking issue with Rust 1.37.0 | See [build log](https://gist.github.com/vitvakatu/0e76378d0977e6e6dfd5fb5e29473179). It looks like name mangling doesn't work correctly when linking with a dynamic library which is also depends on `libstd`. The application structure is the following: 1. Large `dylib` crate `java_ | labels: A-linkage, P-high, T-compiler, regression-from-stable-to-stable, C-bug


toolstate: allow toolstate x->build_fail in rollup PRs | I was trying to implement this myself but was not sure about implementation details, so making a ticket... Currently, a PR that modifies a tool and does not change it to "test pass" will fail. If we allowed "test pass" -> "build fail", "build fail" -> "test fail", and "build fail | labels: C-enhancement, T-infra, T-dev-tools


debuginfo/pretty-uninitialized-vec fails with `Cannot access memory at address 0x7fffff7fe000` | ``` ---- [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs stdout ---- NOTE: compiletest thinks it is using GDB with native rust support NOTE: compiletest thinks it is using GDB version 8003000 error: gdb failed to execute status: exit code: 1 command: "/usr/bin/gdb" "-q | labels: A-testsuite, A-debuginfo, P-high, T-compiler, C-bug


decrease compilation time


question: when there will a Cranelift backend will available


sender Cannot exit while using nested | When I crawled the web pages with rust and curl, I needed to handle the redirected connections, so I created channels to handle the target, but when all the channels were finished, the program didn't quit and was still waiting I tried drop(), but it didn't work the code: ```rust


Rename `Kind` | A `Kind` is not really a kind: it's a term (e.g. a particular type, a particular lifetime or a particular value). However, "`Term`" is overloaded as terms are usually values of particular types (which is just one case here). `KindedTerm` has been suggested. | labels: C-cleanup, I-needs-decision, T-compiler


Rename `.sty` field on `TyS` | `.kind` makes more sense, but could be confusing, as it's not a [type-theoretic kind](https://en.wikipedia.org/wiki/Kind_(type_theory)). There's also the issue of having inconsistent ways to name a field containing a `*Kind`, e.g. `.node` and `.kind`. It would be good to make the | labels: C-cleanup, I-needs-decision, T-compiler, S-waiting-on-bikeshed


Nightly segfaults in release mode on armv7-unknown-linux-gnueabihf | Building any binary in release mode on `armv7-unknown-linux-gnueabihf` with `nightly-2019-09-09` results in segmentation fault: ```sh $ cargo new foo && cd foo && cargo +nightly build --release Created binary (application) `foo` package Compiling foo v0.1.0 (/tmp/foo) error: Coul | labels: I-crash, O-Arm, T-compiler, C-bug


Tricky error with `rustc-std-workspace-core` crate. | I'm not very sure whether this is a bug or not. But let me write down the reproduction steps. I'm using the newest stable. Cargo.toml: ``` [package] name = "dummy" version = "0.0.1" edition = "2018" [dependencies] core = { version = "1.0", package = "rustc-std-workspace-core"} ``


"variant is never constructed" lint appears to be incorrect? | This code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c03d4fa0a396d0476637d39c43bda0c2)) causes a "variant is never constructed" lint, even though the variant is constructed in the `FromStr` implementation: ```rust use std::str::FromStr; | labels: A-lints, T-compiler, C-bug


`miri` no longer builds after rust-lang/rust#64354 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64354, 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 @Centril, do you think you would have ti | labels: P-medium, T-compiler


`extern crate foo as core` breaks resolution in macros | Broken in a recent nightly. Reproducer ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b2ebe9fed3b69a7eaef700018e5a9b51)): ```rust extern crate futures as core; fn bar() { let _ = format!("{}", 42); } ``` Gives the following: ``` error[E0433


ICE encountered in 1.37 stable borrowck | reproduction branch: https://github.com/spacejam/sled/tree/tyler_ice_ice_baby the last commit is the one-line-change that induces the panic rustc 1.37.0 (eae3437df 2019-08-13) running on x86_64-unknown-linux-gnu ``` λ cargo build --verbose Fresh unicode-xid v0.2.0 Fresh semver-pa | labels: I-ICE, A-borrow-checker, T-compiler, C-bug


Failure to install cargo package | When attempting to install a binary via cargo, I got a build failure. I tried this code: `cargo install fd-find` I expected to see this happen: Successful installation of fd. Instead, this happened: ``` cargo install fd-find [4:18:39] Updating crates.io index Installing fd-find v | labels: I-ICE, A-metadata, T-compiler, C-bug


Rustdoc generates illegal "<div>" inside "<pre>" with traits | Similar to the previous bugs I've filed in this regard with illegal html: In: 1.39.0-nightly (34e82a7b7 2019-09-10) The following trait definition: ```rust #[cfg_attr( feature = "external_doc", doc(include = "CacheFieldCollection.md") )] #[cfg_attr( not(feature = "external_doc"), | labels: T-rustdoc, C-bug


Document endianess of octets function on ipv4addr/ipv6addr | The docs of the octets function on [ipv6addr](https://doc.rust-lang.org/stable/std/net/struct.Ipv6Addr.html#method.octets) and on [ipv4addr](https://doc.rust-lang.org/stable/std/net/struct.Ipv4Addr.html#method.octets) don't tell about the endianess. Network or host order? <!-- TR | labels: C-enhancement, T-libs-api, A-docs


Additional methods for TcpStream to provide more sockopts | Dear all, I'm writing a small TCP-based time-measuring tool and use the `std::net::TcpStream`. It turned out that I want to manipulate additional options via `setsockopt()`, but this is not available in the stable API of https://github.com/rust-lang/rust/blob/master/src/libstd/ne | labels: T-libs-api, C-feature-request


Consider async blocks on lifetime errors | [The following incorrect code](https://github.com/bluejekyll/trust-dns/pull/849/files#diff-5cbe22b68a836c7213c624099dedb640R182) ```rust // For QoS, this will only accept one message and output that // receive all inbound messages // TODO: this should match edns settings loop { l | labels: A-diagnostics, A-borrow-checker, T-compiler, A-async-await, AsyncAwait-Polish, AsyncAwait-Triaged


"Don't know the field number in this context" | ##### src/lib.rs: ```rust struct S(#[attr] u8); ``` Stable, and nightly-2019-09-09: ```console error[E0658]: the attribute `attr` is currently unknown to the compiler and may have meaning added to it in the future --> src/main.rs:1:10 | 1 | struct S(#[attr] u8); | ^^^^^^^ | = not | labels: A-attributes, I-ICE, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


Error diagnostic suggests syntactically invalid code | For the following code ([Playground link]): ```rust fn foo<'a>(u: &'a usize) -> impl IntoIterator<Item = usize> + 'a { std::thread::spawn(move || { println!("{}", u); }); vec![] } ``` `rustc` provides the following error and suggestion: ``` error: cannot infer an appropriate life | labels: A-diagnostics, T-compiler, C-bug, A-suggestion-diagnostics, D-invalid-suggestion


Spurious "found two different crates with name `alloc`" errors in PR builder | - https://github.com/rust-lang/rust/pull/64378#issuecomment-530412814 - https://github.com/rust-lang/rust/pull/64429#issuecomment-531692042 | labels: T-compiler, A-spurious, T-infra, C-bug


async functions fail to move values into generated futures in the latest nightly | This simple async function fails to compile on the newest nightly: https://github.com/sfackler/rust-postgres/blob/2cc5bbf21b654c26bfd8b1e80b1e5c7cbd81235f/tokio-postgres/src/lib.rs#L163-L172 ``` error[E0597]: `config` does not live long enough --> tokio-postgres/src/lib.rs:171:5  | labels: T-compiler, C-bug, A-async-await, AsyncAwait-Polish


Async function return type inference fails without an ending return | I have a function of the signature `async fn run() -> Result<!, Box<dyn std::error::Error>>`. It ends with a loop that, as you may infer, never returns `Ok`. The inference for code generation failed, and the various compiler errors said that my function actually returned `()`. | labels: T-compiler, A-inference, C-bug, A-async-await


rustdoc crashes parsing yet another strange doc-comment on 1.37 | I had a similar issue on 1.36 that seemed to have been fixed: https://github.com/rust-lang/rust/issues/62571 That fix looks like it went into 1.37, but I'm getting a crash running on a similar doc comment once again. Here is the offending doc-comment ``` #[doc = " | _ \\ __ _ _ _


(1<<64) can not be precisely represent by f64  in rust (in c, it is ok) | ```rust fn main() { let a: f64 = 2.0f64.powi(64); println!("{}", a); let a: f64 = 18446744073709551616.0f64; println!("{}", a); // wii output // 18446744073709552000 // 18446744073709552000 } ``` ```c #include <stdio.h> int main() { double a = 18446744073709551616.0; float b = 18 | labels: T-libs-api, C-bug


enum variants as expr in macro repetitions | I don't know if this is a bug or not, but I can't seem to get my macro rules to work. It doesn't seem to take enum variants in macro repetitions. Error is: ```` error: arbitrary expressions aren't allowed in patterns --> src/main.rs:34:22 | 34 | "Con" => AbilityType::Con, | ^^^^^


ICE FulfillmentError in trait codegen | When trying to use generic function with capnproto structs the compiler fails to infer types correctly. I failed to distil the problem to a smaller size. Capnproto generates code that implements traits like this ` impl <'a> ::capnp::traits::Owned<'a> for Owned { type Reader = Rea | labels: A-codegen, I-ICE, E-needs-test, T-compiler, C-bug


behavior  about 18446744073709552000f64 is very different in `const`, `let`, `cargo run`, `rustc` | This code ```rust use std::u64; fn main() { const A: f64 = 18446744073709552000.0; println!("{}", A as u64); let b: f64 = 18446744073709552000.0; println!("{}", b as u64); println!("{}", 18446744073709552000.0f64 as u64); } ``` if save it in `1.rs` and `rustc 1.rs && ./1`, the ou


debuginfo: Line-tables-only mode emits much more debuginfo than Clang | We probably could emit less debuginfo when compiling with `-Cdebuginfo=1` than we do at the moment. Clang 8.0 emits a lot less debuginfo when compiling with `-gline-tables-only`, with debuginfo not containing any `DW_TAG_subprogram` entries; while stepping through the code with g | labels: C-cleanup, A-LLVM, A-debuginfo, T-compiler, C-feature-request


libstd build without backtrace feature broken | Likely because of https://github.com/rust-lang/rust/pull/64154. ``` error[E0432]: unresolved import `crate::sys_common::backtrace` --> sysroot_src/src/libstd/backtrace.rs:98:24 | 98 | use crate::sys_common::backtrace::{output_filename, lock}; | ^^^^^^^^^ could not find `backtrace


Dead code isn't checked | The following code compiles, runs, and outputs `42` even though it probably shouldn't: ```Rust fn main() { 'a: while break 'a == { let mut s = String::from("hahaha"); let first_move = s; let second_move = s; std::thread::spawn(|| { s.push('!'); }); std::thread::spawn(|| { s.push( | labels: T-compiler, C-bug


`re_rebalance_coherence` doesn't properly account for fundamental types | As part of an effort to stabilize the `re_rebalance_coherence` RFC (#63599), I was creating tests trying to get more coverage of all possible scenarios, and I found that we don't seem to be handling fundamental types in the way that the RFC specifies. In particular this test is p | labels: A-trait-system, T-compiler, I-unsound, C-bug, requires-nightly, F-re_rebalance_coherence


The compiler should be more helpful when trait bounds are not met. | Here's a reduced testcase: ``` use std::sync::Arc; struct Foo; #[derive(Clone)] struct Bar<T>(Arc<T>); fn main() { let a = Bar(Arc::new(Foo)); let b = a.clone(); } ``` This fails to compile with: ``` error[E0599]: no method named `clone` found for type `Bar<Foo>` in the current s | labels: A-diagnostics, A-trait-system, T-compiler, D-confusing


Confusing `owned_box` error message since nightly-2019-09-04 | Test Program: ```rust // lib.rs #![no_std] pub fn foo() { pub struct Writer; write!(Writer, ""); } ``` Error message on nightly [_9af17757b 2019-09-02_] and before: ``` error[E0599]: no method named `write_fmt` found for type `foo::Writer` in the current scope --> src/lib.rs:5:5  | labels: E-easy, A-diagnostics, E-mentor, T-compiler, E-help-wanted, C-bug


Lifetime errors on nightly-2019-09-11 but not nightly-2019-09-10 | The code below will compile without warnings on `nightly-2019-09-10`, but returns a lifetime error on `nightly-2019-09-11` and later. ```rust #[derive(Debug)] struct A<'a> { inner: Vec<&'a str>, } struct B {} impl B { async fn something_with_a(&mut self, a: A<'_>) -> Result<(), S | labels: A-lifetimes, T-compiler, A-async-await, AsyncAwait-Polish


`clippy-driver` no longer builds after rust-lang/rust#63420 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#63420, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rust-clippy is needed to fix the fallout. cc @spastorino, do you think | labels: T-compiler


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


Unification fails when type alias impl trait is used in non-return position | The following code fails to compile, but I believe this should be a supported use-case under https://github.com/rust-lang/rfcs/pull/2515 (and https://github.com/rust-lang/rust/issues/63063): ```rust #![feature(type_alias_impl_trait)] type X = impl Iterator<Item = u64> + Unpin; st | labels: A-type-system, T-compiler, A-inference, C-bug, F-type_alias_impl_trait


`EmitterWriter::get_max_line_num` works incorrectly | **TL;DR:** [`EmitterWriter::get_max_line_num`](https://github.com/rust-lang/rust/blob/master/src/librustc_errors/emitter.rs#L1037) unconditionally returns `self.get_multispan_max_line_num(span)` no matter what is contained in `children`. Longer explanation: let's take a look at t | labels: A-diagnostics, T-compiler, C-bug


rustc panic with `inconsistent resolution for a macro` for proc macro imported different name for wasm target. | # Context I compile with `cargo check --target=wasm32-unknown-unknown` for a project with a proc macro imported with a different name as such: ```toml [dependencies] curve = { package = "srml-staking-npos-reward-curve", path = "../npos-reward-curve"} // proc macro ``` and it fail | labels: A-resolve, I-ICE, A-macros, A-cross, T-compiler, C-bug


ICE: borrowck/check_loans: assertion failed: `self.bccx.region_scope_tree.scopes_intersect(...)` | err : ``` D:\work\rust\web_api_rust>cargo build Compiling web_api_rust v0.1.0 (D:\work\rust\web_api_rust) warning: unused variable: `x` --> src\response_builder.rs:13:20 | 13 | pub fn file_server(x:&str) { | ^ help: consider prefixing with an underscore: `_x` | = note: #[warn(unu | labels: I-ICE, E-needs-test, P-medium, A-borrow-checker, T-compiler, regression-from-stable-to-stable


Foreign type tests not covering all operations | For example foreign type pointer comparison is not tested. Also `&(*val).0` where field `0` of `*val` is a foreign type is not tested. As a last thing pointer to `*mut ForeignType` casting it not tested. These were all cases which were mishandled in [rustc_codegen_cranelift](http | labels: A-testsuite, C-enhancement, A-FFI, E-needs-test, T-compiler, requires-nightly


Tracking issue for `cmp::{min_by, min_by_key, max_by, max_by_key}` | Tracking issue for the `cmp_min_max_by` feature, which adds the `min_by` / `min_by_key` / `max_by` / `max_by_key` functions to `std::cmp`. PR: #64047 | labels: T-libs-api, B-unstable, C-tracking-issue, Libs-Tracked


as_ne_bytes for primitive types | Recently I've encountered a problem, when I wanted to return a slice of bytes in an integer: ```rust fn to_bytes(num: &u32) -> &[u8] { &u32::to_le_bytes(*num) } ``` (This is an oversimplification of the original code, which is generic over every integer type along with other stuf | labels: T-libs-api, C-feature-request


Suggestion: say "field is never read" instead of "field is never used" | As of rustc 1.37.0, this code: ```rs pub struct Owl { tree: u16 } fn exist(tree: u16) -> bool { tree > 0 && tree <= 3 } impl Owl { pub fn find(tree: u16) -> Option<Owl> { if exist(tree) { Some(Owl { tree }) } else { None } } } fn main() { Owl::find(1); } ``` gives the warning: `` | labels: E-easy, C-enhancement, A-diagnostics, T-compiler


The "unused manifest key" warning doesn't print or halt the publishing with `cargo publish` | Normally if you have a manifest key that cargo doesn't understand many of the commands will print a warning ``` D:\dev\cargo-gba>cargo build warning: unused manifest key: package.repsitory ``` However, if you use `cargo publish` not only does the accidental key not halt the publi


Spurious new Send requirement in async block | This is minimized from code that was working with nightly-2019-09-10 but broken on nightly-2019-09-11. https://github.com/rust-lang/rust/compare/0b36e9dea...34e82a7b7 ```rust use std::future::Future; use std::pin::Pin; fn f<T>(_: &T) -> Pin<Box<dyn Future<Output = ()> + Send>> {  | labels: T-lang, T-compiler, A-async-await, AsyncAwait-Polish


`rls` no longer builds after rust-lang/rust#60584 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#60584, I observed that the tool rls no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rls is needed to fix the fallout. cc @jonas-schievink, do you think you would ha | labels: T-compiler


Rc/Arc: get rid of "value" terminology | The Rc docs use the term "value" to refer to an `RcBox` instance (and similar for `Arc`). That's IMO a bad use of terminology: A "value" is something like "5" or "true" that does not have an identity beyond its mathematical interpretation; an `RcBox` has a *location* so that even | labels: A-docs


question: how can i look at macro expansion


Tracking issue for RFC 2582, `&raw [mut | const] $place` (raw_ref_op) | This is a tracking issue for the RFC "an operator to take a raw reference" (rust-lang/rfcs#2582), feature(raw_ref_op). **Steps:** - [x] Implement the RFC (see [this comment](https://github.com/rust-lang/rust/issues/64490#issuecomment-531579111) for a detailed checklist) - [x] Adj | labels: B-RFC-approved, T-lang, C-tracking-issue, requires-nightly, F-raw_ref_op, S-tracking-needs-summary


In WSL(Window Subsystem Linux) environment, can't run compiled binary because of Invalid argument error(22) | I use WSL2 ubuntu 18.04, kernel version ```4.19.43-microsoft-standard ```. My WSL $HOME is C drive, so I install rust in C drive(```/home/myname```). But my Rust Worspace is D drive, so I write source file ```main.rs``` in D drive. And this is the result: ``` DESKTOP-750B375:/mnt | labels: O-linux


Spurious "unused lifetime parameter" warning with async function | ```rust #![warn(unused_lifetimes)] async fn async_fn(&ref mut s: &[i32]) {} //~ WARN lifetime parameter `'_` never used ``` <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_ASSIGN_START --> <!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"gilescope"}$$TRIAGEBOT_ASSIGN_DATA_END --> <!-- TRIAGEBO | labels: A-lints, T-compiler, C-bug, A-async-await


Unclear interaction between const generics and coherence checking | Consider the following code: ```rust trait Foo { const VAL: usize; } trait MyTrait {} trait True {} struct Is<const T: bool>; impl True for Is<{true}> {} impl<T: Foo> MyTrait for T where Is<{T::VAL == 5}>: True {} impl<T: Foo> MyTrait for T where Is<{T::VAL == 6}>: True {} ``` Co | labels: E-needs-test, T-lang, C-bug, A-const-generics, requires-nightly, F-const_generics


reached the type-length limit while instantiating `std::thread::LocalKey::<std::syn...e, ()}]>>]], std::vec::Vec<i32>>` | # Code https://github.com/kpp/futures-async-combinators/blob/master/examples/stream.rs ```rust use futures::executor; use futures_async_combinators::stream::*; fn main() { let stream = iter(1..=3); let stream = map(stream, |x| x + 1); let stream = map(stream, |x| x * 2); let coll | labels: A-type-system, T-compiler, C-bug, A-async-await, E-needs-bisection, AsyncAwait-Triaged


num(f64) >u64::MAX cast to u64 has no panic | ```rust fn main() { let a = std::u64::MAX; let b = a as f64; let c = b as u64; let d = std::u64::MAX as f64 as u64; println!("{}, {}, {}, {}", a, b, c, d); } ``` This program has no panic. `u64::MAX` can not be repesented by 64bit num(IEE756) precisely, so `u64::MAX` as `f64` wil


ICE when const evaluating UB | This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc @RalfJung ), though we should benchmark the perf considerations around that first. Alternatively we can jus | labels: I-ICE, T-compiler, C-bug, A-const-eval


Backtracing pretty print regression? | I was investigating some backtracing stuff, and I noticed that backtraces look like this: ```text stack backtrace: 0: backtrace::backtrace::trace_unsynchronized at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.37\src\backtrace\mod.rs:66 1 | labels: A-debuginfo, T-libs-api, O-windows-msvc, C-bug


async fn drop order for temporaries in return expression does not match sync | This asynchronous function: ```rust async fn foo_async(x: D, y: D) { helper_async(&D()).await // ^^^ temporary D } async fn helper_async(v: &D) { } ``` will drop first y, then x, then the temporary D. However an equivalent synchronous function ([playground]) would drop the tempor | labels: P-high, T-lang, T-compiler, A-async-await, AsyncAwait-Polish


ICE with const_generic + associated type + double return statement | <short summary of the bug> I tried this code: ``` #![feature(const_generics)] #![feature(const_generic_impls_guard)] use core::array::LengthAtMost32; struct Foo<const D: usize> { state: Option<[u8;D]>, } impl<const D: usize> Iterator for Foo<{D}> where [u8;D]: LengthAtMost32, { t | labels: I-ICE, T-compiler, C-bug, A-const-generics, F-const_generics


rustbuild: ensure single location for -Dwarnings | https://github.com/rust-lang/rust/pull/64316 will move us back a bit due to regressing on not handling external/internal tools differently but we should be able to recover from that relatively easily. This issue tracks said work. | labels: P-low, T-bootstrap


const_generics ICE when propagating const parameter within inherent implementation | The following compiles: ```rust #![feature(const_generics)] pub fn x<const I: usize>() {} pub fn y<const I: usize>() { x::<{I}>(); } ``` [playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=d5a905f7a12dd19a13c074e9960f654b) And so does: ```rust  | labels: I-ICE, T-compiler, C-bug, A-const-generics, A-lazy-normalization, requires-nightly


rustdoc: missing docs for core::ptr::{copy, copy_nonoverlapping, write_bytes} | The `copy`, `copy_nonoverlapping` and `write_bytes` methods are exposed both via `core::ptr` and `std::ptr`. In fact, `std::ptr` as just a re-export of `core::ptr`. However, when comparing the two pages, [`core::ptr`](https://doc.rust-lang.org/nightly/core/ptr/index.html) is miss | labels: T-rustdoc, C-bug


No new nightly for 2019-09-17 | Seems like no nightly was released today. That might be related to https://github.com/rust-lang/rust/pull/64451? Unfortunately I don't think I have access to the logs. Cc @pietroalbini @rust-lang/infra | labels: T-infra, C-bug


Please include rustup in the stand-alone installers | **Describe the problem you are trying to solve** I installed Rust using a stand-alone installer, but then I could not install additional Rust components. **Describe the solution you'd like** The stand alone installers should include Rustup, and anything else that installs using `


mips-linux-musleab is broken again because it uses the wrong crt for static pie | somewhen between nightly-2019-08-30 and nightly-2019-09-15 the link call was changed to "-static" "-pie" but the crt in mips-linux-musleabi has't changed. it should be rcrt, but instead links the one intended for call via libc via .interpr result is segv in dlstart the correct so | labels: O-MIPS, O-musl


Latest nightly STATUS_ILLEGAL_INSTRUCTION | On the latest nightly, the following code exits with `STATUS_ILLEGAL_INSTRUCTION` when compiled in release mode: ```rust fn main() { (0..8).map(|_| std::thread::spawn(move || { let mut i = 0; loop { i += 1; } })).for_each(|x| x.join().unwrap()); } ``` It also happens on the playg | labels: T-compiler, I-unsound, C-bug


azure: CI doesn't fail if msys2 fails to install | The "Install MSYS2" step of [this build](https://dev.azure.com/rust-lang/rust/_build/results?buildId=8318&view=logs&j=4bc7ef66-8a59-503f-fa7a-b9533d6853d5) failed, but the build kept going and failed later with obscure errors. We should fix this so that if msys2 installation fail | labels: O-windows-gnu, T-infra, C-bug


Suggest dereferencing boolean reference when used in 'if' | The following code: ```rust fn take_bool(val: bool) {} fn main() { let a = &true; if a { println!("Hello!"); } take_bool(a) } ``` gives the following errors: ``` error[E0308]: mismatched types --> src/main.rs:5:8 | 5 | if a { | ^ expected bool, found &bool | = note: expected type | labels: E-easy, A-diagnostics, T-compiler, C-feature-request, A-suggestion-diagnostics, D-papercut


Nonsensical suggestion when trying to move value in 'for' expression into closure | This code: ```rust fn main() { let orig = vec![true]; for _val in orig {} let _closure = || orig; } ``` gives the following error: ``` error[E0382]: use of moved value: `orig` --> src/main.rs:4:20 | 2 | let orig = vec![true]; | ---- move occurs because `orig` has type `std::vec:: | labels: T-compiler, C-bug, A-suggestion-diagnostics


Ommiting "C" in `extern "C" fn` in derive input causes spans to get lost. | For some reason ommiting the `"C"` in `extern "C" fn` causes the spans to get lost in error messages. I've created [this repository](https://github.com/rodrimati1992/fn_abi_span_issue) to demonstrate it,simply git clone it and try to build the `using_proc_macro` crate. The `proc_ | labels: E-easy, A-parser, E-mentor, A-macros, T-compiler, C-bug


the trait std::error::Error is not implemented for getrandom::error::Error | | I am seeing this issue when building rust libstd unit test: error[E0277]: the trait bound getrandom::error::Error: std::error::Error is not satisfied --> /folk/prj-rust-dev/bpang/ala-diab-pb19l/fix_bugs/latest/.cargo/git/checkouts/rand-cc8f5b7ec2d3b6d9/64a4000/rand_core/src/er ro | labels: T-bootstrap, E-needs-mcve


Invalid bound suggestion for argument-position impl trait | The following code: ```rust fn is_send<T: Send>(val: T) {} fn use_impl_sync(val: impl Sync) { is_send(val); } ``` gives the following error: ``` error[E0277]: `impl Sync` cannot be sent between threads safely --> src/lib.rs:4:5 | 1 | fn is_send<T: Send>(val: T) {} | ------------- | labels: A-diagnostics, A-trait-system, T-compiler, A-impl-trait, C-bug, A-suggestion-diagnostics


Can the Sized bound be removed from Pin::set ? | https://doc.rust-lang.org/beta/src/core/pin.rs.html#599-604 I am looking closely at pinning for the first time and noticed that set requires the target to be sized. This feels like an unnecessary restriction to me. An unsized read or write is simply a no-op, and it's possible to


How to generate SEH code | Hello! I am developing a Windows driver and need some SEH code. These codes are implemented in C as follows: ```c do { __try { ProbeForWrite(address, length, 1); break; } __except (1) { if (GetExceptionCode() == STATUS_GUARD_PAGE_VIOLATION) { continue; } return false; } } while (


Survey on Pull Request Prioritization | Dear Pull Requests integrators, We are an international group of researchers investigating Pull Requests management activities. We implemented an automated approach, named CARTESIAN, for prioritizing Pull Requests (PRs) received by an open-source project according to the likeliho


Confusing error messages when there are version conflicts | ``` Checking cfg-if v0.1.9 Checking byteorder v0.5.3 Checking slab v0.4.2 Checking libc v0.2.62 Checking byteorder v1.3.2 Checking log v0.4.8 Checking iovec v0.1.2 Checking positioned-io v0.2.2 Checking bytes v0.4.12 Checking lengine v0.1.0 (/Users/kaima/src/lengine) error[E0277]


String.find("") returns 'Some(0)' when searching for the empty string; expected 'None'. | Hey, Ferris. Thanks for Rust. I was surprised by the result of following code, though... fn main() { let s = "Ferris".to_string(); println!("{:?}", s.find("F")); println!("{:?}", s.find("e")); println!("{:?}", s.find("r")); println!("{:?}", s.find("Q")); println!("{:?}", s.find("


Confusing 'unreachable code' error message when macro is involved | This code: ```rust macro_rules! early_return { () => { return () } } fn main() { return early_return!(); } ``` Gives the following warning: ``` warning: unreachable expression --> src/main.rs:8:5 | 8 | return early_return!(); | ^^^^^^^^^^^^^^^^^^^^^^ | = note: #[warn(unreachable_ | labels: C-enhancement, A-diagnostics, A-macros, T-compiler


Unnecessary improper_ctypes warning for extern "Rust" | The following code generates an `improper_ctypes` warning: ```rust extern "Rust" { fn foo(dest: &mut [u8]) -> Result<(), Error>; } ``` I would expect this sort of warning for an `extern "C"` declaration, but it seems incorrect for an `extern "Rust"` declaration. Am I misunderstan | labels: A-lints, T-compiler, C-bug


RFC: Better/Shorter syntax to declare multiple variables | When we have multiple variable to be declared, we need to write something like this: ```Rust let (mut a, mut b, mut c, mut d) = (false, false, false, false); ``` There are two obvious factorizations: The first part is to factorize the `mut` decorator, so to be `let mut (a, b, c,  | labels: needs-rfc


Huge increase of size of std between 2019-07-07 and 2019-07-08 | ``` curl -sI https://static.rust-lang.org/dist/2019-07-0{7,8}/rust-std-nightly-x86_64-unknown-linux-gnu.tar.gz | rg content-length content-length: 82970771 content-length: 211283629 ``` this is a difference of around 120MiB :/ `librustc` alone has been increased by 60Mib that nig


compiler rejects to use self in match arm | Hi, I have the following Code [(Playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c436b46fba25c33930edf4f984feec38) ```rust struct S { first: usize, second: usize, } impl S { fn matches(&self, v: usize) -> &'static str { match v { self.first =>


-C target-feature/-C target-cpu are unsound | In a nutshell, target-features are part of the call ABI, but Rust does not take that into account, and that's the underlying issue causing #63466, #53346, and probably others (feel free to refer them here). For example, for an x86 target without SSE linking these two crates shows | labels: A-codegen, P-medium, T-compiler, I-unsound, C-bug, A-ABI


Compiler crashes during borrow checking. | ```rust struct Data<'a> { data: [u8; Self::SIZE], } impl<'a> Data<'a> { const SIZE: usize = 12; } ``` ``` Compiling playground v0.0.1 (/playground) error: internal compiler error: src/librustc_mir/borrow_check/nll/universal_regions.rs:741: cannot convert `ReEarlyBound(0, 'a)` to  | labels: I-ICE, A-associated-items, A-borrow-checker, T-compiler, C-bug


SIGILL when statically linking with libc++.a on MacOS | I've a Rust project that dynamically links to `libc++` which I'm trying to statically link. Unfortunately building this project on MacOS results in a SIGILL error. I've simplified the project to the following minimal test case: https://github.com/basvandijk/sigill-error/ Building | labels: A-linkage, O-macos, T-compiler, C-bug


Omitting struct field name in cast | ```rust #[derive(Debug)] struct Example { value : u32 } fn main() { let value : i32 = 100; let example = Example { value : value as u32 // cannot remove the "value :" }; println!("{:#?}", example) } ``` ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2


Compiler panic when yielding array element from non-generator | Steps to reproduce: 1. Run `cargo new --lib crash`. 2. Replace `src/lib.rs` with this content: ``` #![feature(generators)] pub fn crash(arr: [usize; 1]) { yield arr[0]; } ``` 3. Run `RUST_BACKTRACE=full cargo +nightly build --verbose` to get this output: ``` Compiling crash v0.1. | labels: I-ICE, E-needs-test, T-compiler, C-bug, A-coroutines, F-coroutines


Rust should not link sanitizer runtimes unconditionally | I've noticed today that apparently Rust adds sanitizer runtimes such as the ASan runtime during linking and I found this runtime inside a static archive. As far as I know, these runtimes should not be part of static archives or DSOs, they should only be linked when creating an ex | labels: A-linkage, T-compiler, A-sanitizers, C-bug


Async struct method, <_'> lifetime shadowing | Hello, I ran into a problem using `<'_>` lifetime with async struct methods, here is the example: struct Foo<'a> { swag: &'a i32 } impl Foo<'_> { async fn bar(&self) -> i32 { 1337 } } The error is: `error[E0496]: lifetime name `'_` shadows a lifetime name that is already in scope | labels: A-lifetimes, T-compiler, C-bug, A-async-await, AsyncAwait-Polish


How to handle reservation impls in rustdoc / error messages | I've opened this issue for discussion on how to handle reservation impls (see https://github.com/rust-lang/rust/issues/64631) in rustdoc and how to handle their error messages. | labels: A-trait-system, T-lang, requires-nightly, F-rustc_attrs


async functions with `unimplemented!()` are marked as unreachable | can reproduce with ```rust async fn example(){ unimplemented!() } ``` results in ``` warning: unreachable expression --> src/main.rs:1:19 | 1 | async fn example(){ | ___________________^ 2 | | unimplemented!() 3 | | } | |_^ | = note: `#[warn(unreachable_code)]` on by default ```  | labels: A-lints, T-compiler, C-bug, A-async-await


ICE with return outside of function body | The following ICE's on stable, beta and nightly: ```Rust enum Bug { V1 = return [0][0] } ``` <details> <summary>Backtrace:</summary> ``` error: internal compiler error: src/librustc/ty/context.rs:556: node_type: no type for node `expr [0] (hir_id=HirId { owner: DefIndex(12), loca | labels: I-ICE, P-medium, T-compiler, regression-from-stable-to-stable, C-bug


Invalid `unreachable_code` in `async fn`. | From Rust `nightly-2019-09-16` to `nightly-2019-06-18`, something has caused the following code to start throwing an unreachable expression warning. Changing it from an `async fn` to an `fn` throws no warnings. ```rust async fn read_until(r: &mut std::net::TcpStream, byte: u8) ->


Drop implementations not being called on panic with Fat LTO. | Hi, It looks like calls to `Drop::drop()` are getting removed when using `lto = "fat"` for a release build. It doesn't seem to occur with `lto = "thin"` or `lto = "no"`. I've got a test case here: https://github.com/cstorey/fat-lto-drop-repro, which can be reproduced like this: ` | labels: A-destructors, P-high, T-compiler, regression-from-stable-to-stable, C-bug


Rustc panics while compiling gstreamer in RLS | RLS cannot build my project, which uses gstreamer. Compiling it normally with rustc works fine. `rustc 1.39.0-nightly (eceec57f7 2019-09-18)` `x86_64-unknown-linux-gnu` Affected project for reference: https://gitlab.gnome.org/World/Shortwave I launched RLS manually with `RUST_LOG | labels: I-ICE, P-high, T-compiler, A-save-analysis, C-bug, E-needs-mcve


ICE: enum discriminant depends on generic arguments | Following code ICEs on today's nightly (97e58c0d3 2019-09-20): ```rust enum Foo { A = foo(), B = foo(), // <- error: internal compiler error: src/librustc/ty/mod.rs:2400: enum discriminant depends on generic arguments } const fn foo<T>() -> isize { 0 } ``` What's peculiar is that | labels: E-needs-test, T-compiler, C-bug, A-const-eval


Rust Language Server panicked at 'Box<Any>', | Using repo https://github.com/amethyst/amethyst-starter-2d.git @ fd8bff9ea61 `rustc 1.39.0-nightly (9b9d2aff8 2019-09-19)` `cargo 1.39.0-nightly (3596cb86b 2019-09-19)` `rls 1.39.0 (d9aa23a 2019-09-15)` I start `RUST_BACKTRACE=1 rls --cli` in `$ .../amethyst-starter-2d` and get:


Outdated `--explain` text for E0432 "An import was unresolved." | See [E0432][1] for the current text. [1]: https://doc.rust-lang.org/error-index.html#E0432 It currently includes: « Paths in `use` statements are relative to the crate root. To import items relative to the current and parent modules, use the `self::` and `super::` prefixes, respe | labels: A-resolve, T-compiler, A-docs, C-bug


Compiler crash when using RLS | Trying to use RLS in neovim (https://github.com/autozimu/LanguageClient-neovim/issues/889#issuecomment-533800654) ``` {"message": "src/librustc/ty/context.rs:211: node type <B>::Item (hir_id=HirId { owner: DefIndex(246), local_id: 15 }) with HirId::owner DefId(0:246 ~ rayon[3354]


Wrong infered type when an additional constrain added | In the function `f` I have to specify `bool` explicitly while `f` differs from `g` in constrains only: ```rust use rand::Rng; use rand::distributions::{Distribution, Standard}; fn f<S, R>(rng: &mut R) -> bool where R: Rng, Standard: Distribution<S>, { rng.gen::<bool>() } fn g<R>( | labels: A-trait-system, T-compiler, A-inference, C-bug


proc-macro param attrs dropping first attrs in impl fns | I have been able to reproduce https://github.com/rust-lang/rust/issues/64282. If an `fn` inside an `impl` has a param attr on the first parameter, no matter how many, they are not visible in the `TokenStream`. Repro repo: https://github.com/bbqsrc/params-attribute-example Source: | labels: A-attributes, A-macros, P-high, T-compiler, C-bug


Incorrect description of std::prelude name resolution in standard library docs | The [documentation for `std::prelude`][1] states: [1]: https://doc.rust-lang.org/std/prelude/index.html > On a technical level, Rust inserts > > ``` > extern crate std; > ``` > > into the crate root of every crate, and > > ``` > use std::prelude::v1::*; > ``` > > into every modul | labels: A-resolve, T-lang, A-docs, C-bug


Request: add an impl for `f32::try_from(i32)` | It appears that there's no `TryFrom` support on the `f32` type. | labels: T-libs-api, C-feature-request


Two function generic type bounds creates nonsense | This is rather silly -- ``` pub fn poll_events<F: FnMut(Event)>(input_component: &mut Input, window: &mut Window, callback: F) where F: FnMut(Event, &mut Window), { ``` This function will compile except that no one can call it. If you only put in one parameter, it yells to have t


rustc panicked in RLS. "node type <G>::NodeId (...) cannot be placed in TypeckTables with local_id_root" | Not sure if there are similar issues, so I open a new one. In my project https://gitlab.com/gentoid/oxyfy/merge_requests/7 I updated deps (see [the diff](https://gitlab.com/gentoid/oxyfy/merge_requests/7/diffs?diff_id=55967431&start_sha=ef363f13ee24afe36fa22dc7c131cd9bc9c278cb))


ICE when `cargo doc` on `lexical-core`: attempted .def_id() on invalid res: Err | <short summary of the bug> I tried this code: Running `cargo doc` on a project that has `lexical-core 0.6.2` as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: `error: internal compiler error: src/librustc/hir/def | labels: T-rustdoc, A-resolve, I-ICE, A-visibility, A-macros, P-high


ICE with const_generic and integration test | Searched a bit, but did not find the same issue. When using const_generics and trying to get an integration test (or benchmark) to run, the compiler ICEs. I tried this code: src/lib.rs: ``` #![feature(const_generics)] pub struct Foo<const D: usize> { pub coords: [u8; D], } pub fn | labels: I-ICE, A-metadata, T-compiler, C-bug, A-const-generics, requires-nightly


cmp::max changed behavior in nightly | This program ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8cac9661ef1e135fc25d94f33027c9f0)) changed behavior between https://github.com/rust-lang/rust/compare/97e58c0d3...1dd188489. And broke bindgen as a result in funny ways. ```rust us


Compiler option to augment implicitly typed variables in the code with explicit type information | Hi, Type inference is nice. You can write code faster since you don't have to change type annotations all over the place when you change the type of one thing somewhere. On the other hand, I also think that in some cases it takes more time to grok implicitly typed code, especiall


Unused variable warning is emitted on trait method with default implementation | https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1229cc645454ceb61ca781b7ad4a6116 If you have a default implementation of a trait inline with the declaration, in which you don't use a parameter, the compiler will warn about the unused variable and suggest t | labels: C-enhancement, A-lints, T-lang


Request: Lossy way to move `Vec<u8>` into a `String` | If you have a `Vec<u8>` of utf8 data there's three ways to get a `String`: * `from_utf8(vec: Vec<u8>) -> Result<String, FromUtf8Error>` * `from_utf8_lossy(v: &'a [u8]) -> Cow<'a, str>` * `unsafe fn from_utf8_unchecked(bytes: Vec<u8>) -> String` There doesn't appear to be any way  | labels: T-libs-api, C-feature-request


`rustc` v1.37.0 freezing when passed `--emit` | I am distributing `rust 1.37.0` (obtained through `rustup`) inside of an Alpine linux-based container for cross-compiling software for a large number target architectures. While I have successfully managed to install `rustc` in such a way that I can compile (using `rustc --target | labels: A-driver, T-compiler, C-bug, I-hang


error: internal compiler error: src/librustc_metadata/decoder.rs:483: entry: id not found: DefIndex(86) in crate aljabar with number 15 | Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: ``` extern crate aljabar; use aljabar::{matrix, vector}; #[cfg(test)] mod tests { use super::*; #[test] fn identity() { let pixel = vector![0,255,255,15]; let kernel = matrix![ [0,0,0 | labels: A-metadata, T-compiler, C-bug, A-const-generics, requires-nightly


Clarify when dependencies are linked | The reference documents that [exern crate](https://doc.rust-lang.org/reference/items/extern-crates.html) has some documentation on linkage of dependencies, but appears to relate to Edition 2015 (or at least not mention linking without `extern crate`). We are considering use of `e | labels: A-linkage, C-enhancement, T-compiler, A-docs


Incorrect error message for byte literal with single quotes | When creating a byte literal with single quotes, like `b'hello\0'`, The error message says: ``` error: character literal may only contain one codepoint --> src/wire_protocol/operations.rs:101:37 | 101 | assert_eq!(Bson::Binary(4, b'12345').byte_length().unwrap(), 10); | ^^^^^^^ h | labels: E-easy, C-enhancement, A-diagnostics, E-mentor, T-compiler


repr attributes can be applied at module level | Spot what's wrong with this code: ```rust #![repr(C)] struct Foo(i32); extern "C" { fn foo(x: Foo); } fn main() {} ``` ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fda6cbd1d9bcae478712b342a354ee1d)) For some reason, top-level `#![repr(..)] | labels: A-attributes, T-compiler, C-bug


ICE 'index out of bounds: the len is 0 but the index is 0', src/librustc_typeck/check/pat.rs:729:23 | commit that introduced ICE: https://github.com/najamelan/pharos/commit/fa9b467ad928d4c1b42cef9637e44915e816ab82 The ICE happens on `cargo check`. The most fundamental change here I imagine is introducing `continue` inside the match... <details><summary>Backtrace</summary> <p> ``` | labels: E-easy, A-diagnostics, I-ICE, regression-from-stable-to-nightly, T-compiler, C-bug


Parallel compiler jobserver management strategy | I tested out a full crate build of the Cargo crate graph in release mode with a parallel rustc compiler today but it unfortunately regressed the build time relative to nightly by about 20%! The cause of the regression appears to be an enormous amount of time spent in the kernel,  | labels: I-compiletime, T-compiler, A-parallel-compiler


GAT impl with type parameter causes ICE, even without feature enabled | This also applies to stable rust, since it still ICEs without the feature gate, though of course on stable there's no way to encounter it without having another error due to the feature not being enabled. It's similar to #60654 but with type parameters instead of lifetime paramet | labels: I-ICE, T-compiler, C-bug, requires-nightly, F-generic_associated_types, glacier


Incorrect note for expected type in E0271 when using an associated type | With the following code: ``` #[derive(Debug)] struct Data {} fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) { for item in iterator { println!("{:?}", item) } } fn main() { let v = vec![Data {}]; do_stuff(v.into_iter()); } ``` the diagnostic (in nightly & stable) wrongl | labels: A-diagnostics, T-compiler, C-bug, D-incorrect


Missing backslash in std::ascii::escape_default docs due to faulty rustdoc rendering | In the [documentation for std::ascii::escape_default](https://doc.rust-lang.org/std/ascii/fn.escape_default.html) the doc comment fragment ```Double quote is escaped as `\"`.``` is incorrectly rendered as > Double quote is escaped as `"`. (note the missing backslash) instead of t | labels: T-rustdoc


Lint `unreachable_pub` got easily confused by multiple items in a single `pub use ...` statement | This code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6f6d3006c4df35712474dc8fa6ab8442)) trips `unreachable_pub` lint (while being completely legit). ```rust #![deny(unreachable_pub)] pub use self::m1::{Item1, Item2}; mod m1 { pub use sel | labels: A-lints, A-visibility, T-compiler, C-bug


move of mutably borrowed content results in a 'use-after-move' bug | Having played around with rust I encountered something I consider to be violating rust's ownership rules and manifests as a dreaded _use-after-move_ bug. I managed to reduce the error to the next example of a linked list where use-after-move manifests as an endless loop. Maybe an


ICE when using target_feature with a const | The following code snippet triggers a ICE: ```rust #[target_feature(avx2)] const FOO: usize = 7; ``` `rustc 1.37.0 (eae3437df 2019-08-13) running on x86_64-unknown-linux-gnu` Bug was found on playground | labels: A-type-system, I-ICE, P-high, T-compiler


stray "not covered" diagnostic in JSON output | Since #64271, the E0005 error has begun emitting a strange "not covered" span in the JSON output. This does not appear in the normal "human" rendered output. Sample code: ```rust #![allow(unused)] fn main() { let x = Some(1); let Some(y) = x; } ``` With `--error-format=json`, thi | labels: A-diagnostics, P-low, T-compiler, C-bug


Issue with #[used] static being removed | ``` #[derive(Copy, Clone, Eq, PartialEq, Debug)] enum CRP { #[used] CRP0 = 0x00000000, // All functions enabled #[used] CRP1 = 0x12345678, // SWD disabled, partial update enabled, except sector 0 #[used] CRP2 = -0x789ABCDF, // 0x87654321, // SWD disabled, full erase only #[used]  | labels: E-needs-mcve


error: cannot find derive macro `Copy` in this scope | I am seeing this issue when building latest rust with latest libc: ``` error: cannot find derive macro Copy in this scope --> /folk/prj-rust-dev/bpang/V7LIBC-997/dev/.cargo/git/checkouts/libc-d1297d136f47e864/3a9e5d0/src/unix/linux_like/linux/gnu/b64/x8 6_64/align.rs:1:10 | 1 | #


Rustc should show an unused_attribute warning when #[inline] is used on trait methods without body | Re: https://github.com/rust-lang/rust/issues/47475 https://github.com/rust-lang/rust-clippy/pull/2367#issuecomment-358255935 > I think this should some day be caught by the unused_attribute lint from rustc | labels: C-enhancement, A-lints, A-trait-system, T-compiler


`clippy-driver` no longer builds after rust-lang/rust#64766 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64766, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rust-clippy is needed to fix the fallout. cc @Centril, do you think yo | labels: T-compiler


build.rs:  `rerun-if-env-changed` should mean "changed compared to last execution of the same kind" (check vs build/run) | Currently, it seems that build.rs scripts share the same environment when run by `cargo build`/`cargo run` and `cargo check`. This is a problem which leads to unnecessary rebuilds of `libsqlite3-sys` whenever I have `cargo watch -x run` running in cmd.exe, when I then do `cargo c


Declarative macros can create infinite glob import cycles | The following code results in `A` being cyclicly glob imported from `x` into `y` and back with a different identifier (it gains a new mark on each import). ```rust #![feature(decl_macro)] pub macro m($i:ident, $j:ident) { mod $i { pub use crate::$j::*; pub struct A; } } m!(x, y); | labels: I-ICE, E-needs-test, T-compiler, A-decl-macros-2-0, requires-nightly, F-decl_macro


Cargo fails building `image` on osx nightly | See this build job: https://travis-ci.org/image-rs/image/jobs/589672851 There is no backtrace or error, just: > thread 'main' panicked at 'index out of bounds: the len is 2 but the index is 2', src/tools/cargo/src/cargo/util/cpu.rs:152:29 It has already reproduced a second time o


Suggestion: Option::take_if() | Suggestion: Adding `Option::take_if()`. It takes a predicate (similar to filter, but for conditional `.take()`): ```rust pub fn take_if<P>(&mut self, predicate: P) -> Option<T> where P: FnOnce(&T) -> bool { match self { Some(x) if predicate(x) => self.take(), _ => None, } } ``` | labels: T-libs-api, C-feature-request


ICE when combining wrong syntax with Unicode string literal | In syntactically erroneous inputs, non-ASCII string literals can cause a compiler panic. Being a dilettante with fingers used to C++, I tried to initialize a struct without calling its `new` method, and it so happened that I was passing it a non-ASCII string. This gave me a compi | labels: A-resolve, I-ICE, A-Unicode, E-needs-test, P-medium, T-compiler


`miri` no longer builds after rust-lang/rust#64785 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64785, 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 @Manishearth, do you think you would hav | labels: P-medium, T-compiler


error: internal compiler error: unexpected panic: inconsistent resolution for a macro | Compiling this: https://github.com/scullionw/eseabuddy/tree/compiler_bug ``` #[macro_use] extern crate pypack; use pypack::{rust_embed, RustEmbed, RustEmbedExt}; #[derive(RustEmbed)] #[folder = "dist/"] struct Python; fn main() { Python::dump_and_exec(); } ``` Results in an ICE:  | labels: A-resolve, I-ICE, A-macros, P-high, T-compiler, C-bug


Should warn when trying to cast between a fat pointer and a non-fat pointer | Please see the following piece of code (I came up with when discussing in our Rust group): ```rust use std::boxed::Box; use libc::c_void; fn main() { show_ptr(get_ptr()); } fn get_ptr() -> *mut c_void { let x = vec!["Hello".to_string(), "World".to_string()].into_boxed_slice(); Bo


`clippy-driver` no longer builds after rust-lang/rust#64513 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64513, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rust-clippy is needed to fix the fallout. cc @varkor, do you think you | labels: P-medium, T-compiler


Add a lint to force adding at least one test for each error code? | A lot of error codes currently don't have ui tests nor long error explanation, therefore we cannot know if they're still thrown by the compiler which isn't an ideal situation... Should we add lint/check for this? cc @rust-lang/compiler | labels: C-enhancement, A-lints, T-compiler


Internal compiler error but only when running under rls | I wasn't sure if it was right to report this here or elsewhere, so here it is for now... Trying to compile [Hagrid](https://gitlab.com/hagrid-keyserver/hagrid.git) with `rustc 1.39.0-nightly (6ef275e6c 2019-09-24)` works, but running the `rls --cli` from the same toolchain result | labels: I-ICE, P-high, T-compiler, A-save-analysis


-rpath argument passed even when disabled in target | This occurs specifically when building libcore, libstd, liballoc, etc. for Emscripten, as observed in https://github.com/rust-lang/rust/pull/63649. A workaround was added upstream in https://github.com/emscripten-core/emscripten/pull/9475, but we would be able to remove that work | labels: A-linkage, T-compiler, C-bug


`x.py check` should support `--tests` and `--all` | `cargo check` supports these flags, but it seems `x.py` does not. This means issues in tests can be overlooked, as in https://github.com/rust-lang/rust/pull/64813#issuecomment-535729781. | labels: C-enhancement, T-compiler, T-bootstrap, T-infra


Compiler error message is confusing | I don't know what caused this error. Sorry, I can't provide simple code to reproduce it. ![rust-compiler-error](https://user-images.githubusercontent.com/21213088/65736836-0b308900-e10f-11e9-9a1a-c6ef879fbc4a.jpg) ``` bash $ rustup show Default host: x86_64-apple-darwin installed | labels: A-diagnostics, T-compiler, C-bug, E-needs-mcve, D-confusing


1.38: internal compiler error running `cargo clippy` on project with `mysql_common` dependency | ``` ... Checking mysql_common v0.18.0 error: internal compiler error: src/librustc/ty/context.rs:516: node_type: no type for node `expr 5 (hir_id=HirId { owner: DefIndex(228), local_id: 255 })` thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:644:9 note: run with


Failed to run `cargo rustc --profile=check -- -Zunstable-options --pretty=expanded` on simple code with comments | Code: ```rust fn main() {} /* */ ``` Command (used to expand macros): ```shell RUST_BACKTRACE=full cargo rustc --profile=check -- -Zunstable-options --pretty=expanded ``` Result: ``` thread 'rustc' panicked at 'assertion failed: `(left == right)` left: `2`, right: `1`', src/libsy | labels: I-ICE, T-compiler, C-bug, requires-nightly


Segfault when using rust inside a go program | This is really a weird bug that occurs on one of our program, i managed to make a reproducable example under this repository: https://github.com/joelwurtz/segfault-golang-with-rust This only happens when calling a specific function on the https://github.com/servo/html5ever librar | labels: C-bug, E-needs-mcve


Rust beta crash when running cargo clippy with index out of bound error on travis ci osx | Rust beta currently crash out when cargo clippy in run on travis CI. https://travis-ci.com/iamsauravsharma/cargo-trim/jobs/239695854#L121 If I am correct this issue was fixed by #64774 over nightly but it didn't land over beta rust branch so beta rust is still failing on travis C


`remap-path-prefix` is not convenient to use in .cargo/config for privacy | Let's say when building your executable for release, you have this goal: Maximum privacy, strip all paths associated with the build machine from the release executable. Requirements: - it should be doable with no cmd line flags (just a fixed `.cargo/config`) - it should work rega | labels: A-driver, C-enhancement, T-compiler, T-cargo, C-feature-request, A-reproducibility


`clippy-driver` no longer builds after rust-lang/rust#64813 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64813, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rust-clippy is needed to fix the fallout. cc @varkor, do you think you | labels: T-compiler


Misleading documentation in `std::option` module | The current [`std::option` module](https://doc.rust-lang.org/std/option/index.html#options-and-pointers-nullable-pointers) states, that > Rust's pointer types must always point to a valid location; there are no "null" pointers. Which is obviously wrong. There are no null referenc | labels: A-docs, C-bug


ICE: Associated constant and impl trait | When the associated constant of an impl trait is referenced it creates an ICE: ```rust trait AssociatedConstant { const DATA: (); } impl<F, T> AssociatedConstant for F where F: FnOnce() -> T, T: AssociatedConstant, { const DATA: () = T::DATA; } impl AssociatedConstant for () { co | labels: I-ICE, E-needs-test, P-medium, A-associated-items, T-compiler, A-impl-trait


Should async/await be strict keywords? | My impression is that `async` and `await` should be strict keywords. They are currently marked as "unused" or "reserved" ([unused](https://github.com/rust-lang/rust/blob/6d07874e883ae4334b42ef3ab04cc3f52ee711ee/src/libsyntax_pos/symbol.rs#L1093-L1095), [unstable](https://github.c | labels: A-diagnostics, T-lang, T-compiler, C-bug, A-async-await


push() onto const Vec is doing nothing, no warning either | ```` rustc 1.39.0-nightly (6ef275e6c 2019-09-24) binary: rustc commit-hash: 6ef275e6c3cb1384ec78128eceeb4963ff788dca commit-date: 2019-09-24 host: x86_64-unknown-linux-gnu release: 1.39.0-nightly LLVM version: 9.0 ```` ````rust fn main() { const X: Vec<i32> = Vec::new(); X.push(3 | labels: C-enhancement, A-lints, T-lang, T-compiler, A-const-eval


ICE "unexpected region in outlives inference: ReEmpty" | Internal compiler error `unexpected region in outlives inference: ReEmpty` when missing `Self` bound on struct. Reproducible on stable/beta/nightly on [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b57d05596def04acd1f181d43b33ce). Also, no | labels: A-lifetimes, I-ICE, P-high, T-compiler, C-bug


Need to cherry pick LLVM support for wasm exceptions | [This LLVM commit](https://github.com/llvm/llvm-project/commit/5c3cdef84b82464756bb571c13c31cf7773860c3) makes Emscripten's LLVM backend exception handling scheme work with aggregate types returned by value. This commit needs to be included in Rust's LLVM fork in order to re-enab | labels: A-LLVM, T-compiler, O-asmjs, O-emscripten


src/librustc/ich/impls_ty.rs:209: ty::TyKind::hash_stable() - can't hash a TyVid _#1t. | The following ```rust #![feature(const_generics)] struct A<T, const N: usize>([T; N]); impl<T, const N: usize> A<T, {N}> { fn bar() -> Self { panic!() } fn foo() -> Self { A::bar() } } fn main() { println!("Hello, world!"); } ``` gives ``` warning: the feature `const_generics` is | labels: I-ICE, T-compiler, A-incr-comp, C-bug, A-const-generics, requires-nightly


rustc assertion failure (librustc_codegen_llvm/consts.rs:459) | I'm not sure this has already been reported, but I ran into this today. Unfortunately I don't have a good idea what's causing it, it suddenly appeared after refactoring some code. Deleting `target` and building from scratch did not help. ``` thread 'rustc' panicked at 'assertion  | labels: O-macos, A-codegen, I-ICE, O-x86_64, T-compiler, C-bug


Trait bound not satisfied when using trait constant in array expression | The following code fails on `nightly`/`beta`/`stable` ```Rust trait Trait { const SIZE: usize; } fn foo<T>(v: &T) where T: Trait { [0i32; <T as Trait>::SIZE]; } ``` with the following error: ``` error[E0277]: the trait bound `T: Trait` is not satisfied --> src/lib.rs:6:12 | 6 | [ | labels: A-lazy-normalization


`clippy-driver` no longer builds after rust-lang/rust#64864 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64864, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rust-clippy is needed to fix the fallout. cc @Centril, do you think yo | labels: P-medium, T-compiler


async dyn Trait type deduction | For standart functions rust deduct conversion from `Box::new(something)` to `Box<dyn Trait_name>`, but in async we need use `as Box<dyn Trait_name>`: ```rust pub trait Trait: Send {} #[derive(Default)] struct Test; impl Trait for Test {} pub fn test() -> Box<dyn Trait> { Box::new


linking of libtest failed | Probably regressed in #64324 (Fix mixing crates with different `share_generics`) ``` $ rustc -V rustc 1.40.0-nightly (084beb83e 2019-09-27) $ git clone https://github.com/bjorn3/rustc_codegen_cranelift.git $ cd rustc_codegen_cranelift $ git checkout 44792f108949048c8945a29e6eee6a | labels: A-linkage, O-macos, P-high, T-compiler, regression-from-stable-to-beta, A-libtest


Detect match arm guard preceded by `|` in the parser | Detect and recover [the following incorrect code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=81fbc7b20fd10c78f5078956c0dcee50): ```rust enum E { A, B, } fn main() { match E::A { E::A | E::B | // This pipe or operand shouldn't be here if true => {} _  | labels: C-enhancement, A-diagnostics, A-parser, P-low, T-compiler, A-suggestion-diagnostics


error: internal compiler error: src/librustc/ty/context.rs:513: node_type: no type for node `expr 8 (hir_id=HirId { owner: DefIndex(3061), local_id: 87 })` | Running `cargo clippy` on a [scryer-prolog]() Rust project with a latest master (commit https://github.com/mthom/scryer-prolog/commit/5ec4dfedb0f7f2440316dc02792869ca45b91df0) checkout makes compiler fail: ``` scryer-prolog on  master took 26s [i] ℤ RUST_BACKTRACE=full cargo cli | labels: I-ICE, T-compiler, C-bug


Support AutoFDO (sample-based PGO) | AutoFDO is a variant of PGO with less compile-time tradeoff. A few modifications are needed on rustc side to make it possible: - "profile-sample-use": a LLVM option to load the profile. This is very similar to "profile-use" and can be trivially implemented. - "debug-info-for-prof | labels: A-LLVM, A-codegen, T-compiler, C-feature-request


Rust playground Favicon | I'm not sure that this is the right place to post this issue, but let's try. The actual Rust Playground https://play.rust-lang.org/ doesn't have a Fivicon and it looks really bad in the bookmark bar. If there aren't any specific issue with it, is it possible to add one?


rust-1.38: bootstrap linker=clang: error: failed to run custom build command for `ryu v1.0.0` // Caused by: process didn't exit successfully: `.../work/rustc-1.38.0-src/build/bootstrap/debug/build/ryu-deb3460cf2bb47d1/build-script-build` (signal: 11, SIGSEGV [...] | ``` running: /tmp/portage/dev-lang/rust-1.38.0/work/rust-stage0/bin/cargo build --manifest-path /tmp/portage/dev-lang/rust-1.38.0/work/rustc-1.38.0-src/src/bootstrap/Cargo.toml --verbose --locked --frozen Compiling proc-macro2 v0.4.30 Compiling unicode-xid v0.1.0 Compiling syn v0 | labels: T-compiler, T-bootstrap, C-bug


VecDeque constant time reverse? | The only way to reverse a `VecDeque` is to call `swap` to do an in-place reversal, which is O(n). My understanding is that `VecDeque` is implemented as a ring buffer which means we should be able to implement reverse in constant time with no element swaps by changing the directio | labels: A-collections, T-libs-api, C-feature-request


ICE building Apache Arrow PR in `librustc_traits/normalize_erasing_regions.rs:42` | See https://travis-ci.org/apache/arrow/jobs/591264273 for failed build ``` 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 'ru | labels: I-ICE, A-trait-system, regression-from-stable-to-nightly, A-associated-items, P-high, T-compiler


have simpler diagnostic when passing arg to closure and missing borrow | playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9f1e00046f513d4d9da8790042e52ca9 Code: ````rust struct MyStruct { age: u32 } fn run<F: Fn(&MyStruct) -> bool>(func: F, data: &MyStruct) -> bool { func(&data) } fn main() { let m = MyStruct { age:  | labels: C-enhancement, A-diagnostics, E-mentor, A-closures, T-compiler, A-suggestion-diagnostics


Suggested fix does not account for operator precedence | This fails (as expected): ``` fn foo() -> String { 1 + 2 } ``` However, the help message is wrong: ``` error[E0308]: mismatched types --> src/lib.rs:2:5 | 1 | fn foo() -> String { | ------ expected `std::string::String` because of return type 2 | 1 + 2 | ^^^^^ | | | expected stru | labels: E-easy, T-compiler, C-bug, A-suggestion-diagnostics


Can't return value from inside an if statement without return keyword | Minimal working example: ```rs fn test(recurse: bool) -> i32 { if recurse { // This should return value of `test(false)` from the function // Instead, it gives us an error that says "expected (), found i32" test(false) } 0 } fn main() { print!("{}", test(true)); } ``` Error messa


Tracking issue for `const extern fn` and `const unsafe extern fn` | This is a tracking issue for implementing and stabilizing defining a `const extern fn` and `const unsafe extern fn` - [X] Add a test according to https://github.com/rust-lang/rust/pull/64906#issuecomment-539902772 (added in https://github.com/rust-lang/rust/pull/68370) ### Stabil | labels: A-FFI, T-lang, B-unstable, C-tracking-issue, A-const-eval, F-const_extern_fn


Provide more information about call stack in case of stack overflow during compilation | Compiling code with custom macros ``` RUST_BACKTRACE=full cargo build ``` results in ``` thread 'rustc' has overflowed its stack fatal runtime error: stack overflow error: could not compile `tests`. Caused by: process didn't exit successfully: `rustc --edition=2018 --crate-name t | labels: A-diagnostics, T-libs-api, C-feature-request


Unhelpful trait bound diagnostic hint for arbitrary self types | Playground: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=3d9fb14075d8fb9de8dea454fbb663e9 <details> <summary>Code</summary> ``` #![feature(generator_trait)] use std::ops::{Generator, GeneratorState}; struct GeneratorIterator<T> { generator: T, } impl<T | labels: A-diagnostics, T-compiler, C-bug, F-arbitrary_self_types, D-invalid-suggestion


`saturating_add` doc is not clear enough | Godbolt link: https://godbolt.org/z/9rm4jF So I expect these two functions has the same assembly: ```rust pub fn foo(a: i32, b: i32) -> i32 { a.saturating_add(b) } pub fn bar(a: i32, b: i32) -> i32 { match a.checked_add(b) { Some(v) => v, None => i32::max_value(), } } ``` But the | labels: C-enhancement, A-docs


ICE: const eval error with an empty slice. | This code: ```rust pub struct Slice<'a, T>(&'a [T]); impl<'a, T: 'a> Slice<'a, T> { pub const EMPTY: Self = Slice ({ let v: &[T] = &[]; v }); } ``` Errors on `rustc 1.40.0-nightly (22bc9e1d9 2019-09-30) running on x86_64-unknown-linux-gnu` with this message: ``` Compiling playgro | labels: A-type-system, I-ICE, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


Mixed signals from errors about trait const fns | I was trying to define a trait method as const, but it turned out in an error, which, according to [RFC911](https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md) is a design decision, and the [tracking issue for const fn](https://github.com/rust-lang/rust/issues/57 | labels: C-enhancement, A-diagnostics, A-trait-system, T-compiler, A-const-eval


rustc panic on pattern matching when no unit type instance is specified | I forgot to add () inside Some(): ``` fn main() { match Some(()) { Some() => (), None => (), } } ``` Got panic: ``` $ RUST_BACKTRACE=full cargo build Compiling crash v0.1.0 (/tmp/crash) thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', src/librust


tidy should skip RLS files | tidy should skip RLS files or even more, it should probably skip untracked files. ``` [santiago@galago rust1 (make-place-builder)]$ ./x.py test -i --stage 1 --keep-stage 1 src/tools/tidy Updating only changed submodules Submodules updated in 0.02 seconds Finished dev [unoptimized | labels: T-bootstrap, T-infra


Cannot await in scope that contains call to format! | As part of #64477, it was identified that the following code no longer compiles (https://github.com/rust-lang/rust/issues/64477#issuecomment-531882958): ```rust async fn foo(_: String) { } fn bar() -> impl Send { async move { foo(format!("{}:{}", 1, 2)).await; } } ``` This is as  | labels: C-enhancement, T-lang, T-compiler, A-async-await, AsyncAwait-Triaged


Crater runs for Rust 1.39.0 | cc @rust-lang/release | labels: S-waiting-on-review


ICE while compiling hyper (`StableHasher: unexpected region '_#0r`) | Hyper fails to compile on Rust master (702b45e40) ``` error: internal compiler error: src/librustc/ich/impls_ty.rs:100: StableHasher: unexpected region '_#0r ``` <details> ``` $ RUST_BACKTRACE=1 cargo +master check Checking hyper v0.13.0-alpha.2 (/home/manishearth/mozilla/Git/hyp | labels: I-ICE, regression-from-stable-to-nightly, T-compiler, C-bug, A-coroutines


Const eval incorrectly computes that mutable param is zero | The following code results in a const eval divide by zero error, when it cannot actually error at runtime: ```rust pub fn foo(mut n: i32) { if n < 0i32 { n = 0i32 } if n > 0i32 { dbg!((1i32) / n); } } ``` https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ee | labels: T-compiler, C-bug, A-const-eval


The behaviour of `librustc_errors::Handler::reset_err_count` seems to contradict its documentation | The function: https://github.com/rust-lang/rust/blob/702b45e409495a41afcccbe87a251a692b0cefab/src/librustc_errors/lib.rs#L473 Citing the doc comment for this function: ```rust /// NOTE: *do not* call this function from rustc. It is only meant to be called from external /// tools


ICE: StableHasher: unexpected region '_#0r | ``` error: internal compiler error: src/librustc/ich/impls_ty.rs:100: StableHasher: unexpected region '_#0r thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:912:9 stack backtrace: 0: 0x7ff79606ba94 - backtrace::backtrace::libunwind::trace::had03042f494c8644 at /c


Bad page rendering with js disabled | For example in here: https://docs.rs/slab/0.4.2/slab/struct.Slab.html No sections is shown because they're hidden by default. It should be overloaded with noscript so that they show by default in such case. | labels: T-rustdoc


Tracking issue for unsizing casts in const fns | Right now we don't allow unsizing casts (array -> slice or type -> dyn Trait) in const fns on stable. While we can't allow unsizing to `dyn Trait` until we've figured out trait bounds in const fns, we can easily allow unsizing casts for slices, there's no reason not to have them. | labels: T-lang, B-unstable, C-tracking-issue, A-const-eval


FCP for toolstate changes | Manual FCP for this change. Please leave a comment if you can't tick the box due to lack of permissions or, preferably, ping me on Discord/Zulip (`@simulacrum`). The [PR](https://github.com/rust-lang/rust/pull/64977) has a more detailed explanation of this change, but the general | labels: T-bootstrap, disposition-merge


Regression in spacing of left margin in diagnostics | ```rust struct A; // // // // // // // fn main() { let _: () = A; let _: () = B; } ``` #### `$ cargo +nightly-2019-10-01 check` This is the correct output. ```console error[E0425]: cannot find value `B` in this scope --> src/main.rs:11:17 | 11 | let _: () = B; | ^ help: a unit st | labels: A-diagnostics, regression-from-stable-to-nightly, C-bug


Inconsistent `const_err` on index access to array in polymorphic functions | Stable currently allows indexing an array with invalid constant indices in polymorphic functions without warnings. A recently nightly change has apparently changed this behaviour into an error. The following builds on stable without warnings but errors on nightly: ```rust pub fn


`IndirectlyMutableLocals` analysis is unsound in the presence of unsafe code | #64470 added an `IndirectlyMutableLocals` analysis to track whether a local could possibly be mutated through a pointer at a given point in the program. However, this analysis overlooked the fact that a shared reference to a `Freeze` field of a struct could be converted to a shar | labels: T-compiler, I-unsound, C-bug, A-const-eval


Entire program seems to be optimized away | I've come across a situation where the presence or absence of a comment changes the program behavior. With the comment present, the program does exactly what I expect (prints a bunch of stuff). Without the comment, the program does nothing and terminates with exit code 0. I have  | labels: T-compiler, regression-from-stable-to-stable, E-needs-mcve


Updating Cargo.lock can result in dependency cycle | Bumping few packages can result in dependency cycle. Single command reproducer: ``` $ cargo update --aggressive -p cargo Updating crates.io index Updating git repository `https://github.com/rust-lang/cargo` error: cyclic package dependency: package `compiler_builtins v0.1.19` dep


Point at duplicated dot in method access | [The following incorrect code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=afabf424606627e723a6faed1bcde8e9) ```rust struct Type { option: Option<Vec<u8>> } impl Type { fn method(&self) -> Option<Vec<u8>> { self.option..as_ref().map(|x| x) } } fn main | labels: C-enhancement, A-diagnostics, P-low, T-compiler


Internal Compiler Error When Making Requests With Hyper | I've been staring at this error all day long and finally decided to file a report for it, so here we are. I'm attempting to make a request using identical code to the [hyper client.rs example](https://github.com/hyperium/hyper/blob/master/examples/client.rs), but I continue to ge


Possible beta to nightly regression (from | Possible regression from beta-1.39 to nightly-1.40, exposed by [`tonic`](https://github.com/hyperium/tonic) I tried this code (using the [rust nix overlay](https://github.com/mozilla/nixpkgs-mozilla/blob/master/rust-overlay.nix)): ``` $ cd tonic $ nix-shell -p latest.rustChannels


error: unused attribute const_fn_union with incr-comp | Every time I try to recompile the compiler using incremental compilation with `./x.py build -i --stage 1 --keep-stage 1 src/libstd` I get the following error ... ``` error: unused attribute --> src/libcore/slice/mod.rs:66:5 | 66 | #[allow_internal_unstable(const_fn_union)] | ^^^^ | labels: T-compiler, A-incr-comp, C-bug, WG-incr-comp, A-const-eval


Allow building for hard-float targets in RISC-V | Currently Rust does not support compiling/linking with LLVM's `-target-abi=lp64d` option, which enables the hard-float ABI in riscv64. This feature is necessary for Rust interop with C code on hard-float targets. | labels: A-cross, T-compiler, C-feature-request, O-riscv


type parameter `A/#0` (A/0) out of range when substituting (root type=Some(*const A)) substs=[] | Minimal example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=814876c654b0b3ad162d52ba64064b02 ``` error: internal compiler error: src/librustc/ty/subst.rs:557: type parameter `A/#0` (A/0) out of range when substituting (root type=Some(*const A)) substs | labels: A-type-system, I-ICE, A-FFI, P-medium, T-compiler, C-bug


regression in 2019-10-01 nightly | I will try to make a reproduction later, but just wanted to open an issue now. The code worked when compiling with the beta and the prior nightly. ``` error: internal compiler error: src/librustc/ich/impls_ty.rs:100: StableHasher: unexpected region '_#0r thread 'rustc' panicked a


libsyntax JSON output bytes counts ignore CRLF normalization | Recently there was a change in rustc to normalize newlines (CRLF -> LF) early during processing (#62948). This caused a change in the JSON output offsets. While the line/column values were unaffected (since they do not include the newlines in the counts), the `byte_start`/`byte_e | labels: A-parser, T-compiler, C-bug


An ICE when awaiting an async method. | I tried this code: ```rust struct Struct; async fn a() { Struct.method().await; } impl Struct { async fn method(&self) {} } ``` ## Meta `rustc --version --verbose`: ``` rustc 1.40.0-nightly (702b45e40 2019-10-01) binary: rustc commit-hash: 702b45e409495a41afcccbe87a251a692b0cefab


`SocketAddr{V4,V6}` or `Ip{V4,V6}Addr` should have `ANY`/`any` constructor | A commonplace difference between Windows and other targets is that to bind to "all" interfaces, you need to use `LOCALHOST` on Windows and `UNSPECIFIED` everywhere else. We should make this easy via e.g. associated methods like these: ``` SocketAddrV4::any(port) SocketAddrV6::any | labels: T-libs-api, C-feature-request


ICE: src/librustc_lint/types.rs:858: unexpected type in foreign function: T | ```rust fn _f<T>() { extern "C" { static _a: *const T; } } ``` backtrace: ``` Compiling playground v0.0.1 (/playground) error: internal compiler error: src/librustc_lint/types.rs:858: unexpected type in foreign function: T thread 'rustc' panicked at 'Box<Any>', src/librustc_error | labels: A-lints, I-ICE, A-FFI, P-medium, T-compiler, C-bug


Intermittent failure in src/test/ui/reify-intrinsic.stderr | The test `src/test/ui/reify-intrinsic.stderr` appears to be intermittently changing its output. Usually, it prints: `unsafe extern "rust-intrinsic" fn(_) -> _ {std::intrinsics::transmute::<_, _>}` but sometimes it prints: `unsafe extern "rust-intrinsic" fn(_) -> _ {std::mem::tran | labels: A-pretty, A-resolve, T-compiler, C-bug, A-reproducibility


an empty `:vis` doesn't work in trait declaration | I want to create a macro that generate `fn`s that use in both `impl Item...` and `trait TraitName`. In `trait`, `pub` must be omitted, but in `impl SomeStruct` I need `pub`, so the macro need a `$vis:vis` like this: ```rust macro_rules! create_method { ($vis:vis $name:ident) => { | labels: A-parser, A-visibility, A-macros, T-lang, C-feature-request


restrict type parameter `Self` error is unclear. | The following example code yields an error: ``` struct Demo { a: String } trait GetString { fn get_a(&self) -> &String; } trait UseString { fn use_string(&self) { println!("{:?}", self.get_a()); } } impl GetString for Demo { fn get_a(&self) -> &String { &self.a } } impl UseString | labels: A-diagnostics, T-compiler, A-suggestion-diagnostics, D-invalid-suggestion


UI Tests that check ICEing thread names break with `parallel-compiler = true` | When I run `./x.py test` locally on a clean checkout of master with `parallel-compiler = true`, I see a couple of failures that seem to be related to the name of the rustc thread which ICEd in the tests. I turned parallel-compiler off, reran the test command, and the tests passed | labels: E-easy, I-ICE, P-high, T-compiler, C-bug, A-parallel-compiler


Tracking issue for `Span::mixed_site` | This is a tracking issue for `Span::mixed_site` API providing direct access to `macro_rules` hygiene to proc macros. Introduced in https://github.com/rust-lang/rust/pull/64690. | labels: A-macros, T-lang, T-libs-api, B-unstable, C-tracking-issue


Build with pure LLVM toolchain on Linux | Hello, I'm creating a Linux distribution that does not use GCC and use LLVM/Clang and their libraries by default (libc++, libc++abi, compiler-rt and libunwind). No libstdc++ or gcc installed. The distribution is based on musl as well. I'd like to build rust with that pure LLVM to | labels: A-LLVM, T-bootstrap, C-feature-request


Type Inference issue with Option<Box<dyn Trait>> | My current project uses a wrapper struct that wraps every occuring error in a struct that has a field of the type Option<Box<dyn std::error::Error>>. During implementation of the From<*> traits I encountered the issue shown in the picture: ![Screenshot 2019-10-02 at 20 12 35](htt


line num capped to 2 digits in errors | ``` error[E0282]: type annotations needed for `std::result::Result<(), E>` --> sysroot_src/src/libtest/lib.rs:1627:42 | 16| let result = Ok(testfn()); | ------ consider giving `result` the explicit type `std::result::Result<(), E>`, with the type parameters specified ... 16| Err( | labels: A-frontend, A-diagnostics, T-compiler, C-bug


`incremental = true` as the default in config.toml? | I'm curious whether it would make sense for `incremental = true` to be the default for rustbuild in the absence of another setting. Per @eddyb on IRC: ``` 07:53 <eddyb> it used to be bad for a bit until a few months ago (that is, it would produce a very slow compiler) but nowaday | labels: C-enhancement, A-incr-comp, T-bootstrap, T-infra


x86_64-unknown-linux-musl: bad linker for target and unknown __fprintf_chk symbol | I'm trying to build a static musl target from source. I'm using the source release for 1.38.0. Here's the build config for `x.py`: ``` configure: build.rustc := /nix/store/31dk8a6ai75pgf19irr360qakqcx898m-ru ... configure: build.cargo := /nix/store/w3prpvk1rmw24lhci2kpc0xn9rmzf7z | labels: A-linkage, T-compiler, T-bootstrap, T-infra, O-musl, C-bug


Suggest &mut T for &T and vice versa for missing trait bound if applicable | As seen on [Twitter](https://twitter.com/khyperia/status/1179518655790374912?s=19): Missing trait does not hint (im)mutable reborrowing, at least in that specific case. | labels: C-enhancement, A-diagnostics, A-trait-system, T-compiler, A-suggestion-diagnostics


Port rust python scripts to python3 | Since python2 support will stop at the end of the year, I think it's time to move on. Will send the PR tomorrow. | labels: C-cleanup, T-bootstrap, T-infra


Error while building rustc on Windows MSVC (cl.exe returns 2) | Building with x.py on Windows, I already have Rust working thru rustup, but I wanted to build a patched rustc. However this error comes before stage1 begins and is related to cl.exe not compiling something I haven't touched; I made sure to update all the submodules with git and s | labels: A-LLVM, O-windows-msvc, T-bootstrap


`x.py test` generates several `dot` files in the source directory root | ``` definite_init_indirect.dot maybe_init_indirect.dot maybe_uninit_indirect.dot mut_borrowed_locals_indirect.dot ``` If they are necessary, then they should be generated somewhere inside the build directory. cc @ecstatic-morse | labels: T-compiler, T-bootstrap, C-bug


unboxed_closures syntax is not consistent | https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=02e56c54b3189d4098e6dc06550461e5 ```rust #![feature(unboxed_closures)] trait A<Args>: FnMut<Args> { } impl<Args, T: FnMut<Args>> A<Args> for T {} trait B {} fn a() -> Box<dyn A() -> ()> { // <- this works! B


TokenStream manipulations are 1000x too slow | Context: https://github.com/illicitonion/num_enum/pull/14 Switching a proc macro from being token-based to operating on strings with just a final conversion from string to TokenStream can be a 100x improvement in compile time. If we care that people continue to write macros using | labels: C-enhancement, I-compiletime, A-macros, T-compiler


`rls` no longer builds after rust-lang/rust#65076 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#65076, I observed that the tool rls no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rls is needed to fix the fallout. cc @tmandry, do you think you would have time  | labels: P-high, T-compiler


`rustfmt` no longer builds after rust-lang/rust#65076 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#65076, I observed that the tool rustfmt no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rustfmt is needed to fix the fallout. cc @tmandry, do you think you would ha | labels: P-high, T-compiler


Ephemeral borrow on a RefCell that extracts a Copy struct member in func argument position does not drop the borrow before making the funcall | Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=be4dfa9fda3dbe2c8ccb42c3785bd658 This code panics and I do not think it should. ```rust use std::cell::RefCell; use std::rc::Rc; #[derive(Clone, Copy)] struct Item(u32); #[derive(Clone)] struct In


Add support for `-Ztimings` to `x.py` | Cargo's new experimental `-Ztimings` flag is really cool. See [here](https://gistpreview.github.io/?74d799739504232991c49607d5ce748a) for sample output. It would be great to add support for this to `x.py`. It would help a lot with #65031. I tried and failed to get `-Ztimings` wor | labels: T-compiler, T-bootstrap, T-cargo, C-feature-request


Star Import Precedence Regression in Beta | The goblin tests started failing in beta because there seem to be a change in order for how star imports are applied. This PR changes the imports so nothing shadows any more: https://github.com/m4b/goblin/pull/184 Annoyingly I cannot produce an isolated test case that shows this  | labels: A-resolve, P-medium, T-compiler, regression-from-stable-to-beta, C-bug, E-needs-bisection


Is panic message stabilized? | Can I parse output from a program "**thread** 'main' **panicked at** '**called** `Result::unwrap()` on an `Err` value: ()" to detect what panic has occurred?


`clippy-driver` no longer builds after rust-lang/rust#65087 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#65087, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository https://github.com/rust-lang/rust-clippy is needed to fix the fallout. cc @Centril, do you think yo | labels: T-compiler


ptr::offset should explicitly clarify 0-sized offset semantics | https://doc.rust-lang.org/std/primitive.pointer.html#method.offset I can't remember the past arguments we definitely had about this, but it would be nice to explicitly call out the answer in the docs. As a relevant example, Vec::into_iter currently unconditionally computes the "e | labels: C-enhancement, T-lang, T-libs-api, A-docs


Invalid identifier in proc_macro causes ICE | lib.proc-macro: ```rust #[proc_macro] pub fn foo( item: proc_macro::TokenStream, ) -> proc_macro::TokenStream { let ident = Ident::new("?", Span::call_site()); item } ``` bin: ```rust foo!{} ``` build: ``` thread 'rustc' panicked at '`"?"` is not a valid identifier', src\libsynta


Compiling a file with a non-ASCII name with `--error-format=short` enabled makes error messages contain excessive spaces after "filename:line:column" | Consider the following rust source (in `test.rs`): ```rust fn main() { println!("hello world } ``` It is obvious that it has syntax error. It also seems obvious that the generated error shouldn't depend on name of file except noting the name of file. However, it doesn't happen in | labels: A-diagnostics, A-Unicode, T-compiler, C-bug


ICE: macro expansion using `expr` fragment as identifier | Regression from stable to nightly ```rust macro_rules! mac { ($eval:expr) => { let mut $eval = (); }; } fn foo() { mac! { does_not_exist!() } } ``` backtrace ``` thread 'rustc' panicked at 'visit_mac disabled by default', src/libsyntax/mut_visit.rs:210:9 stack backtrace: 0: backt | labels: A-diagnostics, I-ICE, A-parser, A-macros, T-compiler, regression-from-stable-to-beta


Many is_ascii_ methods are slower than they have to be | I noticed this `is_ascii` check: https://github.com/rust-lang/rust/blob/618768492f0c731fcb770dc2d178abe840846419/src/libcore/char/methods.rs#L1078 and wondered why it's there. Then someone told me it's there because of the `as u8`. If you pass a non-ASCII char, the `as u8` would  | labels: I-slow, C-enhancement, T-libs-api


link_section attribute misleadingly allowed on modules and impls | The `#[link_section]` attribute seems to be allowed on modules and impl blocks, but it will not do anything. I would expect either all functions/statics within the module/impl to be placed into the specified link_section, but this does not happen. Code used: ``` #[link_section =  | labels: A-linkage, A-attributes, T-compiler, C-bug


Middle size, 80 000 lines, project but very slow, 5 hours, compilation | This code is the [MAVLink ](https://mavlink.io/en/) protocol handler, and generated by one of the MAVLink specification. It is **C/Rust** mixed project, so to compile it you will need **Rust** , **CC** an any **C** compiler. To check how slow **rustc** is, [check this out ](https | labels: E-needs-test, I-compiletime, T-compiler, C-bug


VecDeque: add with_exact_capacity | I've tried this code: ```rust let vd = VecDeque::with_capacity(1024); dbg!(vd.capacity()); ``` The observed behavior is `vd.capacity() = 2047` It would be great if there was a call like `fn with_exact_capacity<T>(capacity: usize) -> Result<VecDeque<T>, ()>` that would return a `V | labels: A-collections, T-libs-api, C-feature-request


SIGSEGV in LLVM | I was trying to compile some x86 early boot code and encountered a SIGSEGV in LLVM: ``` * thread #4, stop reason = EXC_BAD_ACCESS (code=1, address=0x18) * frame #0: 0x00000001061cca13 librustc_codegen_llvm-llvm.dylib`(anonymous namespace)::MachineLICMBase::IsLoopInvariantInst(llv | labels: I-crash, A-LLVM, T-compiler, C-bug


check_mod_item_types query times regressed bigly | There is a crate inside of Fuchsia whose compile times increased from ~500ms to ~120s in the last month of Rust compiler updates. It hasn't been easy so far to provide a minimal example, but I will keep working at it. Some bisecting revealed that it actually consisted of two perf | labels: I-compiletime, P-high, T-compiler, regression-from-stable-to-beta, C-bug, A-async-await


rustfix: Autofix try! macro in edition lint to use `?` operator | Now `try!` macro has been deprecated in #62672. I think it's time to automatically fix `try!(expr)` to `expr?` in edition lint. | labels: A-lints, A-diagnostics, T-lang, C-feature-request, A-suggestion-diagnostics, A-edition-2018


Trait bound is ignored | I have a simple program below that is trying to call `poll_next` on a `T: Stream`. The compiler seems to ignore the trait bound, and suggests adding the exact trait bound that is already in use. This is using the current **beta** rust version: `rustc 1.39.0-beta.5 (fa5c2f3e5 2019 | labels: A-diagnostics, A-trait-system, T-compiler, C-bug, F-arbitrary_self_types, D-confusing


#[non_exhaustive] variants are not detected to be redundant | Say I have the following enum in crate `b`: ```rust #![feature(non_exhaustive)] pub enum Enum { Unit, #[non_exhaustive] Struct { x: bool } } ``` And I match on it in crate `a`: ```rust #![deny(unreachable_patterns)] match Enum::Unit { Enum::Struct { .. } => {} Enum::Struct { .. } | labels: T-compiler, C-bug, requires-nightly, F-non_exhaustive


Nightly async fn ICE | The following ICE's in nightly: ```Rust async fn copy() -> Result<()> { Ok(()) } ``` <details> <summary>Backtrace:</summary> ``` Compiling playground v0.0.1 (/playground) error[E0107]: wrong number of type arguments: expected 2, found 1 --> src/lib.rs:1:20 | 1 | async fn copy() - | labels: I-ICE, T-compiler, C-bug, A-async-await, AsyncAwait-Polish, AsyncAwait-Triaged


Implement std::iter::FromIterator<char> for Box<str> | This would allow to construct a Box<str> from an iterator, example: ```let string: Box<str> = (0..5).map(|_| '☺').collect();``` <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_ASSIGN_START --> This issue has been assigned to @Duddino via [this comment](https://github.com/rust-lang/rust/i | labels: A-collections, T-libs-api, C-feature-request


rustdoc fails to account for `-Clinker` and `-Clink-arg` when building tests | I’m working on a fairly peculiar system at the moment where the default linker (`cc`) is not able of linking properly, and thus I set the following environment variables ``` export RUSTFLAGS="-Clinker=clang -Clink-arg=--target=$HOST_TARGET" export RUSTDOCFLAGS="-Clinker=clang -Cl | labels: A-linkage, T-rustdoc, C-bug, A-doctests


Async-related type error messages defy expectations (in span location) | Consider for example this code (using `hyper-0.13.0`): ```rust use std::net::{Ipv4Addr, Ipv6Addr, SocketAddr, SocketAddrV4, SocketAddrV6, TcpListener}; #[derive(failure::Fail, Debug)] enum Error { #[fail(display="Cannot bind to port {}", _1)] CannotBind(#[cause] std::io::Error, u | labels: A-diagnostics, T-compiler, C-bug, A-async-await, AsyncAwait-Polish, AsyncAwait-Triaged


`fetch_add` in atomic integers won't check for overflow | Since the default Rust semantics is to check for overflows in debug, maybe `fetch_add` and `fetch_sub` should check for overflows (in debug), and we should provide `fetch_wrapping_add` and `fetch_wrapping_sub`? Or, if we don't want to introduce breaking changes, we should at leas | labels: C-enhancement, T-libs-api, A-docs


ICE: thread 'rustc' panicked at 'Box<Any>' | This occurred when running `cargo clippy` on a workspace with around 40 child crates. I have not included the full log, for corporate security reasons, but I can probably provide more specific information on request. ``` ... Checking tokio-tcp v0.1.3 Checking tokio-udp v0.1.3 Che | labels: I-ICE, T-compiler, T-dev-tools, C-bug


deprecated proc_macro trigger warning on build library | Use `deprecated` attribute on a procedural macro function doesn't work like expected: it triggers a warning message also when library is building and not just in call place. I know that the `deprecate` attribute support is not landed in stable but this warning is present in all c | labels: E-easy, A-lints, E-mentor, A-macros, T-compiler, C-bug


DWARF for legacy enum incorrect | With test-case gdb.rust/simple.exp (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.rust/simple.rs;hb=HEAD) we run into gdb testsuite failure reported here ( https://sourceware.org/bugzilla/show_bug.cgi?id=25048 ). This is on openSUSE Leap 15.1 | labels: A-debuginfo, T-compiler, C-bug


Change in macro output between 1.37.0 and 1.38.0 | The following code changed output between Rust 1.37.0 and 1.38.0: ```rust macro_rules! call_a_or_b_on_tail { ((a: $a:expr, b: $b:expr), call a: $($tail:tt)*) => { $a(stringify!($($tail)*)) }; ((a: $a:expr, b: $b:expr), call b: $($tail:tt)*) => { $b(stringify!($($tail)*)) }; ($ab:


Provide a way to disable rustdoc keyboard shortcuts | Some people have custom OS or browser-level shortcuts, providing a way to disable these makes it easier for them | labels: T-rustdoc


Potentially swap arrow keys and tab in rustdoc keyboard shortcuts | Currently rustdoc's keyboard shortcuts use Tab to cycle between the tabs at the top of search results, and the arrow keys for moving through search results. It's much more common for Tab and Shift + Tab  | labels: T-rustdoc, A-rustdoc-ui, A-rustdoc-search


Occasional spurious codegen test failures | Occasionally when running tests, I get these failures: ``` [codegen] codegen/issue-45222.rs [codegen] codegen/issue-45466.rs [codegen] codegen/swap-small-types.rs [codegen] codegen/vec-iter-collect-len.rs [codegen] codegen/vec-optimizes-away.rs ``` My current workaround is to del | labels: A-testsuite, T-compiler, A-spurious, C-bug


Tracking issue for `#![feature(entry_insert)]` | This is a tracking issue for the `Entry::insert_entry` method on HashMap and BTreeMap introduced in https://github.com/rust-lang/rust/pull/60142#issuecomment-487416553. - [x] Implementation for HashMap: #64656 - [x] ~~Stabilised in 1.59: #90345~~ Re-stabilised in 1.83: #130290 -  | labels: A-collections, T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period


Compiler should not omit associated type in compile error message | ## Environment - Rust: Nightly 2019-10-07 ## Repro 1. Open https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=933123bb14852662962ab5bf5f2073c8 2. Click run ```rust struct X<'a>(&'a mut i32); impl<'a> Iterator for X<'a> { type Item = &'a i32; fn next(&mut sel | labels: A-diagnostics, T-compiler, C-bug, D-confusing


DebugMap::finish panics if a value returns fmt::Error | ```rust use std::fmt; struct ErrorFmt; impl fmt::Debug for ErrorFmt { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { Err(fmt::Error) } } struct A { field: ErrorFmt, } impl fmt::Debug for A { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_map() .entry(&"fie | labels: T-libs-api, C-bug


Internal lint: Ban `pub` re-exports | Suggested lint name: `rustc::pub_reexport`. When given something like the following, reject it (as a lint): ```rust pub use syntax_pos::symbol; ``` cc https://github.com/rust-lang/rust/issues/49509 -------------------------- Me and @Mark-Simulacrum were discussing library-ificati | labels: C-enhancement, A-lints, T-compiler, T-bootstrap


Don't cc rust-lang/compiler for toolstate changes | While it's important to keep on top of regressions to the toolstate, most of the time these issues are fixed quickly, by the author of the PR that caused the regression, or someone else. With GitHub notifications being difficult enough to keep up with as it is, being mentioned on | labels: E-easy, C-enhancement, T-compiler, T-infra, T-dev-tools