Tracking issue for `#![feature(maybe_uninit_extra,const_maybe_uninit_write)]` | This is a tracking issue for the RFC "Deprecate `uninitialized` in favor of a new `MaybeUninit` type" (rust-lang/rfcs#1892). This issue specifically tracks the following unstable methods: ```rust impl<T> MaybeUninit<T> { pub unsafe fn assume_init_read(&self) -> T { ... } pub unsa | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, requires-nightly


Tracking issue for `#![feature(maybe_uninit_ref)]` | This is a tracking issue for the RFC "Deprecate `uninitialized` in favor of a new `MaybeUninit` type" (rust-lang/rfcs#1892). This issue specifically tracks the following unstable methods: ```rust impl<T> MaybeUninit<T> { pub unsafe fn assume_init_ref(&self) -> &T { ... } pub unsa | labels: T-lang, T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period


Tracking issue for `#![feature(maybe_uninit_slice)]` | This is a tracking issue for the RFC "Deprecate `uninitialized` in favor of a new `MaybeUninit` type" (rust-lang/rfcs#1892). Most of this has been stabilized, this issue now only tracks the below unstable methods. ### Public API ```rust impl<T> [MaybeUninit<T>] { pub unsafe fn as | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, requires-nightly


Implement @argsfile to read arguments from command line | Many tools, such as gcc and gnu-ld, support "args files" - that is, being able to specify @file on the command line. Implemented in https://github.com/rust-lang/rust/pull/63175 This implements a straightforward form where each argument is on a separate line in a text file. This a | labels: A-driver, T-compiler, C-tracking-issue, disposition-merge, finished-final-comment-period, A-CLI


SIGSTKSZ may be too small to handle stack overflow exact CPU model and the Linux version | [This ticket shows](https://bugs.python.org/issue21131) that python's test_faulthandler.test_register_chain() crashed on ppc64 and ARM64 on Linux 3.10 and newer. It seems that rust has the [same problem](https://github.com/rust-lang/rust/blob/c43d03a19f326f4a323569328cc501e86eb6d | labels: T-libs-api


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


Cleanup: Use `#[rust_intrinsic]` and nix `rust-intrinsic` et. al | Per @eddyb's suggestion (https://github.com/rust-lang-nursery/reference/pull/652#discussion_r314206468): > Not sure these should be documented, we've been meaning to remove all 3 for years... > cc @oli-obk at least for intrinsics we could maybe have an intermediary stage where we | labels: C-cleanup, T-compiler, A-intrinsics


Removing the exact lint count from the readme? | Addition and deprecation of multiple lints in a short period of time has regularly caused merge conflicts because of the exact lint count at the top of the README: `There are 310 lints included in this crate!` Does anyone feel like the exact count is worth having? Removing the ex


CStr::from_ptr should be documented to not allow strings bigger than isize::MAX | In #53784, `slice::from_raw_parts` was documented to not allow slices larger than `isize::MAX` bytes. However, `CStr::from_ptr` is not documented to have the same requirement, despite allowing the user to obtain a slice larger than `isize::MAX` bytes with its `to_bytes` method. | labels: C-enhancement, A-FFI, A-docs


Combination of TAIT and ATB does not allow projection (unsatisfied bound) | This should pass but does not: ```rust // check-pass #![feature(associated_type_bounds)] #![feature(type_alias_impl_trait)] fn main() {} trait Bar { type Assoc; } trait Thing { type Out; fn func() -> Self::Out; } struct AssocIsCopy; impl Bar for AssocIsCopy { type Assoc = u8; } i | labels: T-compiler, C-bug, F-type_alias_impl_trait, F-associated_type_bounds


Rust treat Self as dynamic when it shouldn't | Here is a sample code: ```rust trait Inner<S> {} trait MyTrait { fn something<I: Inner<Self>>(i: I); } ``` Which fails to compile with > error[E0277]: the size for values of type `Self` cannot be known at compilation time --> src/lib.rs:4:5 | 4 | fn something<I: Inner<Self>>(i: I | labels: A-trait-system, A-associated-items, T-compiler, C-bug, requires-nightly, F-associated_type_defaults


Incorrectly-/Un-spanned error with `type Out = Box<dyn Bar<Assoc: Copy>>;` | With the following, the error appears in the wrong place (1), while it should be at (2). ```rust //~ ERROR the trait bound `std::string::String: std::marker::Copy` is not satisfied // (1) --^ #![feature(associated_type_bounds)] fn main() {} trait Bar { type Assoc; } trait Thing { | labels: A-diagnostics, A-associated-items, T-compiler, C-bug, F-associated_type_bounds


document that target features are unsafe | When discussing https://github.com/rust-lang/rust/issues/63466 in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the `-Chelp` and in the [rustc book](https://doc.rust-lang.org/rustc/i | labels: P-medium, T-compiler, A-docs


Confusing error message with lifetime in trait | [Given](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=381d0b8ca9363a314dd16bef11da7c4d): ```rust #![feature(async_await)] trait Foo<'a> {} async fn foo<T: Foo>() { unimplemented!(); } ``` ``` error[E0637]: `&` without an explicit lifetime name cannot be | labels: A-diagnostics, A-lifetimes, A-trait-system, T-compiler, regression-from-stable-to-stable, C-bug


Stabilize RFC 2451, re-rebalance coherence | # Stabilization Proposal I am writing to propose we stabilize the implementation of [RFC 2451], "re-rebalancing coherence" ([tracking issue]). [RFC 2451]: https://rust-lang.github.io/rfcs/2451-re-rebalancing-coherence.html [tracking issue]: https://github.com/rust-lang/rust/issue | labels: T-lang, disposition-merge, finished-final-comment-period, F-re_rebalance_coherence


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


1.37 source component packaging looks different from previous versions | Hi, Apologies if reporting this here isn't the most appropriate place, but thought someone else may run into it as well. It appears there're some material differences in how the Rust 1.37 release is packaged, namely around the source download. The [tarball](https://static.rust-la | labels: T-infra, C-bug


SIGSEGV on arm | Hello. I've been directed to create a issue here after a talk on one of the rust discord servers. Hopefully I got right. So I'm trying to compile one of my projects on a Raspberry Pi. ``` nightly-armv7-unknown-linux-gnueabihf (default) rustc 1.38.0-nightly (c43d03a19 2019-08-14)  | labels: I-crash, O-Arm, T-compiler, C-bug


Handle partial initialization correctly in generators | Problem: consider something like the following, ```rust let gen = || { let _x = (yield 5; panic!()); }; ``` This can result in a local saved in our generator of type `((), !)`, which is partially initialized across the yield. In the layout code we claim that fields are all fully  | labels: C-enhancement, T-compiler, A-MIR, A-coroutines, A-async-await, AsyncAwait-Triaged


Confusing error message when a trait bound is unsatisfied due to lack of mutability | In this code, `fp` should have been declared as a mutable reference, and the compiler gives you a nice clear error message saying so: ```rust use std::env::args; use std::fs::File; use std::io::{stdout, Write}; fn main() { let mut args = args(); let _ = args.next(); let dest = ar | labels: C-enhancement, A-diagnostics, A-trait-system, T-compiler


Short-circuit behavior and order in expressions results in 15x performance difference? | I have just started playing with Rust again via Project Euler Problem 4 and I noticed some interesting short-circuit behavior in expressions. In the two functions below, `v2()` is approximately 15 times faster than `v1()` just due to the ordering in the `if`. It's great that ther


[llvm build] Host compiler must support std::atomic | I cannot build rustc locally with commit f7af19c279. The build log is: ```bash % ./x.py test src/test/ui --pass check Updating only changed submodules Submodules updated in 0.06 seconds Finished dev [unoptimized] target(s) in 0.21s Building stage0 std artifacts (x86_64-unknown-li | labels: T-compiler, T-bootstrap


C FFI functions have incorrect signatures in wasm bundle when targeting wasm32-unknown-unknown | We have a crate called `mruby-sys` which uses the `cc` crate to build a C static library. Building this library fails to link when building the `wasm32-unknown-unknown` target due to function signature mismatches. When using the same build process for the C code with clang-8, the | labels: A-FFI, T-compiler, O-wasm


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


Wasm bundle for sys crate with FFI exports is empty | I'm trying to compile [`mruby-sys`](https://github.com/artichoke/artichoke/tree/master/mruby-sys) to wasm. `mruby-sys` builds a C static library using the `cc` crate. `cc` generates two wasm files, one of which I can't read with `0000004: error: bad magic value` error. The other  | labels: A-FFI, T-compiler, O-wasm, C-bug


`RangeToInclusive` code-generation much worse than equivilent `RangeTo` | I have two copies of the exact same code, one using `for _ in 0..65` and the other using `for _ in 0..=64`. The `0..65` one optimizes down to very simple code, however the `0..=64` version ends up emitting a large amount of unnecessary code. --- # RangeTo example ```rust pub fn a | labels: I-slow, A-codegen, E-needs-test, T-compiler, C-bug


Macro-generated macro can no longer be called | The following crate no longer compiles as of the most recent nightly. The relevant commit range is f7af19c27...bdfd698f3. Mentioning @petrochenkov @matthewjasper because #63535 sounds relevant – is this an intentional change? #### Cargo.toml ```toml [package] name = "repro" | labels: A-resolve, A-macros, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


Causing stack overflow by calling to_string in Display trait implementation | As a mentor on exercism.io I came across the following code: ``` impl Display for Clock { fn fmt(&self, f: &mut Formatter<'_>) -> Result { write!(f, "{}", self.to_string()) } } ``` This causes a stack overflow: The reason for that being that **to_string** is automatically impleme | labels: C-enhancement, A-lints, T-lang, T-compiler


Expose llvm.ptrmask intrinsic | LLVM recently added a ptrmask intrinsic, intended for use with tagged pointers: https://llvm.org/docs/LangRef.html#llvm-ptrmask-intrinsic It allows masking off bits from a pointer without going through ptrtoint/inttoptr and breaking alias analysis in the process. We might want to | labels: A-LLVM, T-lang, T-libs-api, T-compiler


Deduplicate closures | https://github.com/rust-lang/rust/pull/62429 manually deduplicated monomorphizations of closures. We should automate this during building instead of requiring users to do it manually. Ideally we'll revert the parts of #62429 that made things less readable as the last step of clos | labels: C-enhancement, A-codegen, A-closures, T-compiler, A-MIR, I-heavy


dist-x86_64-freebsd fails when building with debug assertions | Steps to reproduce: 1. Run `src/ci/docker/run.sh dist-x86_64-freebsd` (note that `DEPLOY=1` is *not* set, which is why we don't see this on Azure) 2. Observe the following ICE ([full log](https://gist.github.com/Aaron1011/244ec6c1126e433767e117b7d22186fe)): ``` Building stage1 st | labels: I-ICE, T-compiler, C-bug


Fn coercion rules seem inconsistent | Consider the following code (which compiles; [playground](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=8902809bc4f0bf6a0752131d9695eda9)): ``` fn f(_: usize) { unimplemented!(); } fn main() { let err = Err(()); f(err.unwrap_or_else(err_exit)); unreach


Panic in 'safe' extern "C" causes SIGILL | Investigating a SIGILL in a _safe_ library of ours I could reduce the crash to the following code: ```rust #![deny(unsafe_code)] extern "C" fn crash() { panic!("End of the world"); } fn main() { // This works ... std::panic::catch_unwind(|| panic!("Oh no")); // This will cause a


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


rustc crash with type alias of impl trait | I cannot provide a simple repro yet. But what I did is mostly define a type alias of an impl trait and use it as generic parameter of another type. And here is the stack trace ``` error: internal compiler error: src/librustc/traits/coherence.rs:523: ty_is_local invoked on unexpec | labels: A-type-system, I-ICE, A-trait-system, T-compiler, A-impl-trait, C-bug


Redundant semicolons are parsed as an empty tuple semicolon statement | ```rust fn foo() { let _ = 3;;;; } ``` Given the above example, the rustc parser used to silently drop the redundant semicolons (`;;;`) from the AST. However, recently the parse has changed how it treats the redundant semicolons - they are now parsed as a semicolon statement with | labels: A-parser, T-compiler, C-bug


#![macro_use] triggers unused attributes warning | Replacing `#[macro_use] mod foo;` with `#![macro_use]` inside foo.rs triggers unused attribute warning even if it is necessary. Using rustc 1.39.0-nightly (2111aed0a 2019-08-17). | labels: A-lints, A-resolve, A-macros, T-compiler, C-bug


hygiene: cannot find macro `foo!` in this scope | This code ([playpen]) compiles on stable but not on nightly and beta: ```rust macro_rules! foo { () => { "foo" }; } macro_rules! bar { () => { foo!() }; } fn main() { println!(bar!()); } ``` [playpen]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8b3bc | labels: A-resolve, A-macros, T-compiler, regression-from-stable-to-beta, C-bug


gfx_device_gl 0.16.1 broken on latest nightly | Caused by #63613. To be precise the https://github.com/rust-lang/rust/pull/63613/files#diff-c915449964a130718bd732c4f035b2cfR101 change. It basically does: ```rust extern crate gfx_core as core; format!(...); ``` Because `format!` uses `::core::format_args` to refer to `format_ar | labels: A-resolve, A-macros, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


Diagnostics could be better for unclosed delimiters | Depending on where the unclosed delimiter is in the file, you can get dozens or even hundreds of meaningless errors after the unclosed delimiter. Since terminals display the last output from a program, this means that the actual error gets completely buried. This afternoon I had  | labels: C-enhancement, A-diagnostics, A-parser, T-compiler, WG-diagnostics, D-papercut


core::ffi::c_void is marked as "stable since 1.1", but it was added in 1.30 | The title says it all really. * Missing `ffi` entirely: https://doc.rust-lang.org/1.29.0/core/ * Present in the new `ffi` module: https://doc.rust-lang.org/1.30.0/core/ffi/index.html | labels: A-FFI, A-stability, T-libs-api, C-bug


ICE caused by using a const_generic fn from a trait or impl | A function that compiles and runs successfully outside of a trait causes an ICE when it's in a trait. The expectation is that this should work similarly to other generics on trait functions--while they will prevent a trait object reference, they should otherwise be allowed. (On [ | labels: I-ICE, T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


Invalid value lint not firing | @RalfJung why is the invalid value lint not firing here? https://github.com/glium/glium/blob/9248e31f8bb76e972021c4d73ee53c59ecfe0364/src/context/mod.rs#L727 The type of the input param to that function is `extern "system" fn(u32, u32, u32, u32, i32, *const i8, *mut std::ffi::c_v


Compiler suggests unnecessary try into | I updated a dependency and the type of a struct field changed from an `i32` to a `u16`. I am assigning a `u16` value to this struct field. Before, I was calling `i32::from` to convert the `u16` to an `i32`. With the upgrade this is unnecessary since the field and the value are bo | labels: E-easy, C-enhancement, A-diagnostics, P-medium, T-compiler, C-bug


rustc suggests invalid syntax for missing method on `impl Trait` parameter | [Given:](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ea23b1a629ffaed2249b6680002d47f1) ```rust trait Foo {} trait Bar { fn hello(&mut self) {} } fn test(foo: &mut impl Foo) { foo.hello(); } ``` rustc outputs: ``` error[E0599]: no method named `hello`  | labels: T-compiler, A-impl-trait, C-bug, A-suggestion-diagnostics


window.hashchange is not a function | When selecting Rust source code with either the latest stable or the latest nightly, the following is seen: ``` main-20190703-1.36.0-a53f9df32.js:1 Uncaught TypeError: window.hashchange is not a function at set_fragment (main-20190703-1.36.0-a53f9df32.js:1) at HTMLDocument.docume | labels: T-rustdoc, C-bug


Debug implementaton for `&(x: impl Debug)` should prepend `&` | dbg! is not displaying the type correctly for reference objects/variables. Comment here: https://www.reddit.com/r/rust/comments/cp8y58/hey_rustaceans_got_an_easy_question_ask_here/ex76hhq/ Code here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ed9fb664 | labels: C-enhancement, T-libs-api


rustdoc renders re-exported `async fn`s incorrectly | Relates to #58027, but this is the case where an async fn is re-exported by another crate. The docs for the original function shows `async fn` but the re-export shows `fn -> impl Future`. Example: - [Original function](https://docs.rs/tokio-sync/0.2.0-alpha.2/tokio_sync/mpsc/stru | labels: T-rustdoc, C-bug, A-async-await, AsyncAwait-Polish


Suggest setting associated types on type errors | [The following code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4c099411a96bcca3c01e682ca92e8175) is missing a constraint for `TryInto<Error=TryIntoError>`: ``` use std::convert::TryInto; struct TryIntoError; struct X; impl TryInto<usize> for X { typ | labels: C-enhancement, A-diagnostics, P-medium, A-associated-items, T-compiler, A-suggestion-diagnostics


E0267 is used twice in different `struct_span_err` calls | The following code https://github.com/rust-lang/rust/blob/1e02bc62bc72d2145a9f11c740714a1a5d94e2b4/src/librustc_passes/loops.rs#L175-L184 Should either assign a new error code to the `AsyncClosure` case, or move the common code to a closure and call it from those two branches to  | labels: E-easy, C-cleanup, T-compiler


Create a deterministic `FxHashMap` wrapper | It should not provide iteration support, but only insert/remove/get/get_mut and convertion to a sorted vec. We should then use it where possible This could prevent accidentially causing hashmap related non determinism in most cases. _Originally posted by @bjorn3 in https://github | labels: E-easy, C-cleanup, C-enhancement, P-medium, T-compiler, A-reproducibility


[bug] async specialization is not parsed | The `async` keyword doesn't seem to currently work with specialization (namely `default fn`). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from @dtolnay in dtolnay/async-trait#25: ```rust macro_rules! item { ($i:item) => {} } ite | labels: A-parser, T-compiler, A-specialization, C-bug, A-async-await, requires-nightly


Strange E0505 error ... is this a bug? | Hey Folks, So, I've been fuzz testing `rustc` nightly using a range of generated programs and am digesting the findings. This one stood out to me: ``` fn main() { let mut x = 1; { let mut y = &mut x; y = y; y; } x; } ``` This currently reports an E0505 on the playground and Rust  | labels: T-lang


Silence `unused_import` warning on unresolved import | `use Foo::*;` will cause the following output: ``` error[E0432]: unresolved import `Foo` --> src/lib.rs:1:5 | 1 | use Foo::*; | ^^^ use of undeclared type or module `Foo` warning: unused import: `Foo::*` --> src/lib.rs:1:5 | 1 | use Foo::*; | ^^^^^^ | = note: `#[warn(unused_impor | labels: C-cleanup, C-enhancement, A-diagnostics, T-compiler


offline docs doesnot show symbols proper on firefox | The offline docs does not show symbols properly such as navigation to previous page, next page, table of content, change theme, search and print this book in firefox browser only. tried > rustup docs --book opened docs in firefox. //version > rustc --version --verbose rustc 1.37.


missing specialization: `<serialize::json::Encoder as SpecializedEncoder<syntax_pos::symbol::Ident>>::specialized_encode` not overridden | The following code when compiled with `-Z ast-json` causes ICE: ```rust pub fn main() { let a = ["1", "lol", "3", "NaN", "5"]; let element: Option<i32> = a.iter().filter_map(|s| s.parse().ok()).next(); assert_eq!(element, Some(1)); } ``` Error: ```rust % RUST_BACKTRACE=1 cargo ru | labels: I-ICE, T-compiler, A-specialization, C-bug, requires-nightly


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


Incorrect overflowing literals error with saturating_sub | ```rust fn main() { assert_eq!(i8::min_value(), -128i8); println!("{}", -128i8.saturating_sub(-1)); } ``` ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=17140f6c272a402083da3ce128c17221)) Errors: ``` Compiling playground v0.0.1 (/playground) | labels: C-enhancement, A-lints, T-compiler


Misspelled test name "ui/non-interger-atomic.rs" | ```diff -ui/non-interger-atomic.rs +ui/non-integer-atomic.rs ``` | labels: E-easy, A-testsuite, C-bug


[Feature request] Compiler might automatically pick a concrete type for generic Option<T> | Hello Rust developers, My versions are: - rustc: `1.37.0 (eae3437df 2019-08-13)` - Cargo: `1.37.0 (9edd08916 2019-08-02)` Currently this does not compile: ```rust use std::path::Path; fn test<P>(_: Option<P>) where P: AsRef<Path> {} fn main() { test(None); } ``` Error message: `` | labels: T-lang, needs-rfc


Suggest removing `self` import when not in a list | ```rust use std::self; // error[E0429]: `self` imports are only allowed within a { } list ``` we should offer the suggestion to remove `::self`, as this is likely what the user intended. <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_ASSIGN_START --> This issue has been assigned to @mib | labels: E-easy, C-enhancement, T-lang, T-compiler, A-suggestion-diagnostics


Tracking issue for `linux_syscall` | PR: #63745 Unresolved questions: - [ ] Should we add syscalls to `core` or keep only in `std`? - [ ] Do we still need the workaround for `syscall6` on x86? | labels: O-linux, T-lang, T-libs-api, B-unstable, C-tracking-issue


Check stdout/stderr of run-pass run portion | We currently check the compiler's output, but it's sometimes useful to check that the run-pass test itself is outputting the same as before. In particular, @tmandry expressed a desire to test libtest in this fashion. Taking a look at the code, we probably want to add another head | labels: A-testsuite, E-mentor


stable rustc panics on adding/removing `dyn` before a trait in a proc macro | I was doing a small change to someone's crate, and encountered a crash. The weird thing is also that the crash is fixed by doing simple `cargo clean`, i.e. the problem was probably not in the code, but in the way `rustc` (or `cargo`) handles it between runs. rustc 1.37.0/rustc 1. | labels: I-ICE, T-compiler, A-incr-comp, C-bug, E-needs-mcve


Implementation of Ord for integers is suboptimal | The current implementation of `Ord::cmp` for integral types results in less than optimal code. Currently the implementation looks something like this: ```rust fn cmp(&self, other: &$t) -> Ordering { if *self == *other { Equal } else if *self < *other { Less } else { Greater } } ` | labels: E-easy, I-slow, C-enhancement, E-mentor, T-libs-api, E-help-wanted


Custom diagnostic for bad `mut` in pattern with sub-bindings | Given (as brought up in https://github.com/rust-lang/rust/pull/63693#discussion_r315926681 CC @Centril): ``` pub fn main() { struct Foo { x: isize } let mut Foo { x: x } = Foo { x: 3 }; } ``` [We currently emit a parse error](https://play.rust-lang.org/?version=stable&mode=debug& | labels: C-enhancement, A-diagnostics, P-low, T-compiler, A-suggestion-diagnostics


Panic while running rustdoc on polonius-engine | I get a panic ~in beta~ at least as far back as 1.31 while attempting to compile the documentation in [rust-lang/polonius](https://github.com/rust-lang/polonius) (seems to stem from polonius-engine) ``` $ RUST_BACKTRACE=full cargo doc --open Documenting polonius-engine v0.9.0 (/h | labels: T-rustdoc, I-ICE, C-bug


Are all AVX-512 SIMD functions and types available in Rust `std::arch` module? | Hello! We are developing our game engine (esp. deserialization and noise generation part) in Rust, which theoretically can make good use of modern SIMD features. There could be relevant x86 CPUs available in market with latest AVX-512 instructions, and as we may concern Rust shou | labels: A-SIMD


[Const generics] thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued' | The code simply does "not" compile, because compiler crashes. I tried this code: ```rust #![feature(const_generics)] fn test<const A: &'static str, const B: &'static str>() { println!("{} {}", A, B); } fn main() { test::<"Hello", "World">(); } ``` Which is expected to compile wit | labels: I-ICE, T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


Temporary values do not outlive a direct await | ```rust struct Test(String); impl Test { async fn borrow_async(&self) {} fn borrow(&self) {} fn with(&mut self, s: &str) -> &mut Self { self.0 = s.into(); self } } async fn test() { // error[E0716]: temporary value dropped while borrowed Test("".to_string()).with("123").borrow_as | labels: A-lifetimes, T-lang, A-async-await


rustc 1.37.0 panic | While running clippy rustc panicked. The code is here https://github.com/AxelNennker/indy-sdk/tree/vcx_clippy To reproduce: - `git clone https://github.com/AxelNennker/indy-sdk` - `git checkout vcx_clippy` - `cargo clippy --manifest-path vcx/libvcx/Cargo.toml -- -W clippy::style


Compiler symbol resolution works when it shouldn't | So here is the code that works when it shouldn't: ```rust let m = unsafe { mem::transmute::<&mut [u8], &mut [u32]>(&mut chunk) }; #[cfg(target_endian = "big")] for j in 0..16 { M[j] = M[j].swap_bytes(); } ``` And this doesn't work, as expected. ```rust let m = unsafe { mem::trans


Ref parameter incorrectly decorated with `noalias` attribute | The following library: ```rust use std::cell::*; pub fn break_it(rc: &RefCell<i32>, r: Ref<'_, i32>) { // `r` has a shared reference, it is passed in as argument and hence // a barrier is added that marks this memory as read-only for the entire // duration of this function. drop( | labels: A-codegen, T-lang, T-libs-api, I-unsound, C-bug


Miscompilation under target-cpu >= haswell | This example fails when compiled with `target-cpu` "haswell" or more recent: ```toml [dependencies] aes-soft = "=0.3.3" ``` ```rust use aes_soft::{block_cipher_trait::BlockCipher, Aes128}; fn main() { let plain = [127, 0, 0, 1, 174, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]; let key = [0; | labels: A-LLVM, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, I-unsound


`as_slice` -> `as_str` in the docs | `core::str::Str.as_slice()` has been renamed to `as_str()` as discussed in https://github.com/rust-lang/rust/issues/14433, but the old name is still referenced in the docs: https://github.com/rust-lang/rust/blob/18630677cf6c7ac50e6786c504b35bc09501dbe2/src/libstd/primitive_docs.r | labels: E-easy, C-enhancement, A-docs


unimplemented macro doesnt compile with RPIT | I believe the following should compile but doesn't. ``` trait Foo {} fn bar() -> impl Foo { unimplemented!() } ``` I get the following error: ``` --> src/main.rs:7:13 | 7 | fn bar() -> impl Foo { | ^^^^^^^^ the trait `Foo` is not implemented for `()` | = note: the return type of  | labels: T-lang, C-feature-request, A-impl-trait


thread 'rustc' panicked at 'no entry found for key', src/libcore/option.rs:1166:5 | ``` thread 'rustc' panicked at 'no entry found for key', src/libcore/option.rs:1166:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. thread '<unnamed>' panicked at 'assertion failed: `(left == right)` left: `LLVMing`, right: `Codegenning`', src/lib


&str->String in the docs | This chunk was supposedly copy-pasted as is from `std::str::from_utf8` https://github.com/rust-lang/rust/blob/bdfd698f37184da42254a03ed466ab1f90e6fb6c/src/liballoc/string.rs#L430-L432 It should read A String ([`String`]) is made of bytes | labels: E-easy, A-docs


[1.38] `#[bench]` accepted on stable but not beta | Initially reported by @e-oz [here](https://github.com/rust-lang/rust/issues/50297#issuecomment-523657376). [[playground](https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=b006497caba8892a0350a517d49c7a2d)] ```rust fn main() { println!("Hello, world!"); } #[ben | labels: A-stability, P-high, T-lang, regression-from-stable-to-beta, T-dev-tools, A-libtest


Confusing E0425 error when referencing undefined name with ::foo | Test program: ```rust fn foo() { println!("foo") } fn main() { ::foo() } ``` This produces the following error messages: ``` error[E0425]: cannot find function `foo` in the crate root --> src/main.rs:4:7 | 4 | ::foo() | ^^^ not found in the crate root help: possible candidate is  | labels: A-diagnostics, A-resolve, T-compiler, C-bug


rustc panic when trying to unwrap DistinctSources | When trying to compile the tests for my [code](https://github.com/software-opal/archivelib-rs/tree/compiler-bug-1.37) I get this error: ``` thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: DistinctSources(DistinctSources { begin: (Real("tests/macros.rs"),  | labels: I-ICE, A-macros, A-borrow-checker, T-compiler, A-NLL, C-bug


ICE trying to compile libstd with -Zmir-opt-level=3 | ``` error: internal compiler error: src/librustc_mir/transform/inline.rs:677: Return place is (*_28), not local thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:643:9 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ec | labels: I-ICE, T-compiler, A-MIR, C-bug, requires-nightly


RustDoc: remove the redundant unstable option "--linker" | while working on https://github.com/rust-lang/rust/issues/63638 i have noticed the there is a conflict between the "-C linker" and the "--linker" option where the later overrides the former. but as the `--linker` flag is unstable I think that it shall be removed as is it confusin | labels: C-cleanup, T-rustdoc


rustdoc crashes on nightly nightly-2019-08-22 | `cargo doc` crashes on nightly (`nightly-2019-08-22`) and also on stable (`1.37.0`) with "nightly" features turned on via `RUSTC_BOOSTRAP=1`. It does not trigger on stable without `RUSTC_BOOTSTRAP=1` flag. Here is the output I'm getting: ``` thread 'rustc' panicked at 'could not  | labels: T-rustdoc, I-ICE, C-bug


impl Display for Path | It's deliberate that to date Path does not impl Display. It's a conservative stance that says that because the conversion to utf8 can be lossy, there isn't necessarily one obviously correct way to display a path. I'd like to revisit that decision, in the interests of convenience. | labels: T-libs-api


How to disable rust runtime stack_overflow check | Hi community, I was using [GEM5](http://gem5.org/Main_Page) architecture simulator to run Rust binaries. However, GEM5 simulator does support syscall sigaltstack, which is called by libstd/sys/unix/stack_overflow.rs further by libstd/rt.rs (sys::stack_overflow::init()). I was won | labels: T-libs-api, C-feature-request


Cross-compile of rust fails in 1.36.0 and 1.37.0 | I'm habitually doing cross-builds of the various rust NetBSD targets, in addition to the native amd64 target (cross-build host). The normal procedure I've followed and which works with 1.35.0, now fails in 1.36.0 and 1.37.0 inside the LLVM build with: ``` [ 1%] Building CXX objec | labels: A-LLVM, A-cross, O-netbsd, T-bootstrap, C-bug


dli_saddr may be const | The various NetBSD ports declare `dli_saddr` as ``` const void *dli_saddr; /* Symbol address */ ``` This gives rise to the need for the following patch to avoid "cast discards qualifier" warnings, which might be ("was" in my case) configured to act as an error: ``` --- src/llvm-p


Automatic dark theme doesn't work | Requested in #61079 and implemented in #61236, the automatic theme switching doesn't seem to do anything: If I visit <https://doc.rust-lang.org/nightly/std/> while the system is in dark mode, I can see in the developer tools that the `<html>` element has the style `content: "dark | labels: T-rustdoc, C-bug


temporary lifetime around await is (maybe) unexpectedly short | So @sfackler pointed out something to me. The problem @sfackler reported was that temporary lifetimes around `await` were too short. The effect was that `foo(&[123]).await` would give an error where `foo(&[123])` would not (in sync code). My assumption was that this was caused by | labels: T-lang, T-compiler, A-async-await, AsyncAwait-Polish


message-format=short output is unnecessarily hard to read | The `--message-format=short` option is a very convenient way to get a condensed error output from cargo when the same/similar errors occur at many places in a code base. Unfortunately, the current output with this option uses bold/color to place the emphasis on the wrong parts of | labels: C-enhancement, A-diagnostics, T-compiler


rustc panic: Inner macro with loop-label inside closure. | https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3bc7b5bf33f55dbb70550fb8f4b6804c | labels: I-ICE, T-compiler, C-bug


struct containing array of size given in Self and slice causes compiler panic | A struct containing an array and a reference to a slice causes the compiler to panic if the array size is defined in the impl block. The issue also occurs for smaller array sizes. - Size in impl (panics): https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=6 | labels: I-ICE, A-associated-items, A-borrow-checker, T-compiler, A-NLL, C-bug


Is the comment re. unstable-book in `src/libsyntax/feature_gate/active.rs` still relevant? | See https://github.com/rust-lang/rust/pull/63824#discussion_r316941434. The comment currently exists in `src/libsyntax/feature_gate.rs` but is being moved in the PR above to `src/libsyntax/feature_gate/active.rs`. cc @oli-obk | labels: I-needs-decision, T-lang, T-compiler, A-docs


compiler | my english is not good , So let's say by example. let x = if {}{};//error:^ expected if condition here let x = if{()}{};//error : ^^ expected bool, found () let x = if{return ()}{}:its correct and condition evaluated to false.but i think -> error:^^ expected bool, found () if it


`use foo::{self, ...}` doesn't import macro `foo!` | When there is a macro and a module with the same name, `use foo::{self, Bar}` syntax imports the module `foo`, but not the macro `foo!`. So you are forced to use this: ```rust use crate::foo; use crate::foo::Bar; ``` It is especially annoying because rustfmt automatically merges  | labels: A-resolve, T-lang


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


Don't print expression result for dbg!() when expr is literal | ```rust fn main() { dbg!("Hello, world!"); } ``` Should give: ``` [src/main.rs:2] "Hello, world!" ``` Instead of: ``` [src/main.rs:2] "Hello, world!" = "Hello, world!" ``` This should be possible by adding a macro rule matching `$val:literal` before the rule matching `$val:expr`.


rustc could not initialize thread_rng (on pre-getrandom Linux kernel) | <short summary of the bug> nushell: https://book.nushell.sh/en/installation / no on-point issues seen here -- searched for "nushell" Tried to build nushell from source and it required "nightly" rust. Didn't know how to install that, so I used "cargo install nu" I expected to see  | labels: O-linux, I-ICE, P-high, T-compiler


Lint for unused unstable feature gates | I've seen two codebases now that used to have unused feature gates: * https://github.com/libra/libra/commit/2f44be56a14492be236ec30925dec3d5e31342ad (this commit was in july while duration_float stabilized in August) * https://github.com/libra/libra/commit/e263fbdc1dd83305d9962d0 | labels: A-lints, A-stability, T-lang, C-feature-request


Compile message contains reference to an identifier not used by the erraneous code | rustc 1.37.0 (eae3437df 2019-08-13) Repo: https://github.com/svenschmidt75/Rust Commit: https://github.com/svenschmidt75/Rust/commit/23ec34211661c8f77c040b751500c86157f01305 When building, I get error message ``` Compiling ann v0.1.0 (/home/svenschmidt75/Develop/Rust/NeuralNetwor | labels: C-enhancement, A-diagnostics, T-compiler, A-inference


Impl HasDataLayout and HasTargetSpec for T where T: HasTyCtxt | labels: E-easy, C-enhancement, T-compiler


Niche-filling layouts are picked over tagged ones even when detrimental. | This prints the values in comments: ```rust use std::num::NonZeroU8; pub enum Foo { A(NonZeroU8, u32), B } pub enum Bar { A(u8, u32), B } fn main() { use std::mem::size_of; dbg!(size_of::<Foo>()); // = 8 dbg!(size_of::<Option<Foo>>()); // = 12 dbg!(size_of::<Option<Option<Foo>>>( | labels: I-slow, C-enhancement, T-compiler, A-layout


Subpar error when lifetime checking for `dyn Trait` evaluates to `'static` | ``` fn foo<T>(x: &Vec<T>) -> Box<dyn Iterator<Item=&T>> { Box::new(x.iter()) } fn main() { let x: Vec<usize> = vec![1, 2, 3]; let _ = foo(&x); } ``` the `rustc` output is ``` error[E0495]: cannot infer an appropriate lifetime for lifetime parameter in function call due to conflic | labels: C-enhancement, A-diagnostics, A-lifetimes, T-compiler, A-NLL, NLL-diagnostics


ICE trying to run cargo clippy on hello world lib.rs | I just tried running `cargo clippy` on the exercism rust track hello world (https://exercism.io) I tried this code: Here are the contents of the folder I'm trying to run it on: https://github.com/nico-abram/rust_test_exercism I expected to see this happen: Clippy. Instead, this h | labels: I-ICE, T-compiler, T-cargo, C-bug, E-needs-mcve


Add missing code examples on Iterator trait | labels: C-enhancement, A-docs, A-iterators


rust build/compile on solaris 11.4 | Hi Team, we are not able to compile rust source on solaris 11.4. Can you please share correct documentation/steps/source/binary..etc for solaris 11.4. Thanks in advance!! Regards, Gopalakrishnan


Raw identifier keywords are sometimes silently accepted in paths | Example: ```rust type A = crate::r#break; // No error (?!) fn main() {} ``` Found by crater run (https://crater-reports.s3.amazonaws.com/beta-1.38-1/beta-2019-08-13/gh/xi-frontend.xi-term/log.txt) when visibility resolution switched to a different algorithm (early resolution), wh | labels: A-resolve, T-compiler, regression-from-stable-to-stable, C-bug


#[unwind(aborts)] does nothing on `extern "Rust" fn` | I would expect the following code to abort, and never print `Hello`: ```rust #![feature(unwind_attributes)] #[unwind(aborts)] fn foo() { // implicitly: extern "Rust" panic!("foooo"); } fn main() { if let Err(_) = std::panic::catch_unwind(|| foo()) {} println!("Hello"); } ``` But  | labels: T-compiler, C-bug, requires-nightly


[1.38] Regression: failed to resolve: could not find `rustc_serialize` in `{{root}}` | https://github.com/rust-lang/rust/issues/63628#issuecomment-524585041 Caused by https://github.com/rust-lang/rust/pull/63449. Tests in `rustc-serialize` and its fork `rustc-serialize2` are broken, no other crates are affected. (Can be fixed with `extern crate self as rustc_seriva | labels: T-compiler, regression-from-stable-to-beta


[1.38] Regression: lifetime name `'s` declared twice in the same scope | https://github.com/rust-lang/rust/issues/63628#issuecomment-524585351 >lifetime name `'s` declared twice in the same scope >lifetime name `'input` declared twice in the same scope ``` ./reg/cff/0.5.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared tw | labels: T-lang, T-compiler, regression-from-stable-to-beta


[1.38] Regression: attributes starting with `rustc` are reserved for use by the `rustc` compiler | https://github.com/rust-lang/rust/issues/63628#issuecomment-524586506 >attributes starting with `rustc` are reserved for use by the `rustc` compiler ``` ./reg/select-rustc/0.1.2/beta-2019-08-13.txt:[INFO] [stdout] error[E0658]: attributes starting with `rustc` are reserved for us | labels: T-compiler, regression-from-stable-to-beta


[1.38] Regression: cannot find macro `trace!` in this scope | https://github.com/rust-lang/rust/issues/63628#issuecomment-524587231 >cannot find macro `trace!` in this scope >cannot find macro `flatdata_intersperse!` in this scope ``` ./reg/eztrace/0.1.0/beta-2019-08-13.txt:[INFO] [stderr] error: cannot find macro `trace!` in this scope ./r | labels: P-high, T-compiler, regression-from-stable-to-beta


[1.38] Regression: expected open delimiter | https://github.com/rust-lang/rust/issues/63628#issuecomment-524587696 >expected open delimiter ``` ./reg/dtolnay/0.0.2/beta-2019-08-13.txt:[INFO] [stderr] error: expected open delimiter ``` Expected breakage of an unstable feature (`my_macro! name { ... }` no longer parses), caus | labels: T-compiler, regression-from-stable-to-beta


[1.38] Regression: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `is` | https://github.com/rust-lang/rust/issues/63628#issuecomment-524590824 >expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `is` ``` ./reg/google-games1/1.0.10+20190627/beta-2019-08-13.txt:[INFO] [stdout] error: expected one of `!`, `.`, `::`, `;`, `?`, `{`,  | labels: T-rustdoc, regression-from-stable-to-beta


[1.38] Regression: expected module, found unresolved item `crate::mod` | https://github.com/rust-lang/rust/issues/63628#issuecomment-524633353 >expected module, found unresolved item `crate::mod` ``` ./gh/xi-frontend/xi-term/beta-2019-08-13.txt:[INFO] [stderr] error[E0577]: expected module, found unresolved item `crate::mod` ``` This is the most hilar | labels: T-compiler, regression-from-stable-to-beta


[1.38] Regression: failed to resolve: use of undeclared type or module `SliceConcatExt` | https://github.com/rust-lang/rust/issues/63628#issuecomment-524634090 >failed to resolve: use of undeclared type or module `SliceConcatExt` ``` ./gh/echupriyanov/tls-ws/beta-2019-08-13.txt:[INFO] [stderr] error[E0433]: failed to resolve: use of undeclared type or module `SliceCon | labels: T-libs-api, regression-from-stable-to-beta


[1.38] Regression: cannot determine resolution for the derive macro `Debug` | https://github.com/rust-lang/rust/issues/63628#issuecomment-524636403 >cannot determine resolution for the derive macro `Debug` ``` ./reg/ruroonga_command/0.3.4/beta-2019-08-13.txt:[INFO] [stderr] error: cannot determine resolution for the derive macro `Debug` ``` Minimized: ```r | labels: T-lang, T-compiler, regression-from-stable-to-beta


[1.38] Regression: proc macro panicked | https://github.com/rust-lang/rust/issues/63628#issuecomment-524641105 >proc macro panicked ``` [INFO] [stderr] Compiling custom-slice-macros v0.1.1 (/opt/crater/workdir) [INFO] [stderr] error: proc macro panicked [INFO] [stderr] --> tests/derives.rs:48:13 [INFO] [stderr] | [INFO] | labels: T-compiler, regression-from-stable-to-beta


[1.38] Regression: custom attribute panicked | https://github.com/rust-lang/rust/issues/63628#issuecomment-524641889 >custom attribute panicked ``` [INFO] [stderr] Compiling display-as v0.4.6 (/opt/crater/workdir) [INFO] [stderr] error: custom attribute panicked [INFO] [stderr] --> tests/format_as.rs:104:5 [INFO] [stderr] | [ | labels: T-compiler, regression-from-stable-to-beta


[1.38] Regression: proc-macro derive panicked | https://github.com/rust-lang/rust/issues/63628#issuecomment-524643597 >proc-macro derive panicked ``` [INFO] [stderr] error: proc-macro derive panicked [INFO] [stderr] --> src/lib.rs:11:1 [INFO] [stderr] | [INFO] [stderr] 11 | / proc_macro_item_decl! { [INFO] [stderr] 12 | | ///  | labels: A-pretty, A-macros, T-compiler, regression-from-stable-to-beta


Rust Installer: OS Error 649: The create operation failed because the name contained at ... | I got the below information when installing the rustup-init.exe <pre> error: component download failed for rustc-x86_64-pc-windows-msvc info: caused by: could not rename downloaded file from 'C:\Users\Hadi\.rustup\downloads\923e829d67102e45fc16eeae727a4dad13f7abe6239b99fef0e4a233


ICE having include! in code from stdin when calling rustc | to reproduce the fault this can be used: `echo 'include!("auxiliary/empty.rs"); pub fn main(){}' | rustc - ` will result in this ICE: `thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', src/libsyntax/ext/source_util.rs:189:22 note: Run with RUST_BACKTR | labels: I-ICE, I-needs-decision, T-lang, C-bug, glacier


Collect occurrences of `{}` for mismatched braces diagnostic | Many editors _helpfully_ auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: ``` fn main() {} let _ = (); } ``` It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to ``` | labels: E-easy, C-enhancement, A-diagnostics, A-parser, T-compiler, A-suggestion-diagnostics


No documentation about f32_runtime without std | Hi, It seems like all the functions under `f32_runtime` don't work without std (https://doc.rust-lang.org/src/std/f32.rs.html#29-994) I tried looking for documentation about this and didn't find anything concrete, and since the `core` docs don't have documentation for the primiti | labels: C-enhancement, T-libs-api, A-docs, A-floating-point


Cannot convert this tail recursive function into an iterative one due to lifetime error | Rust version: 1.37.0 This problem has been previously discussed on [Stack Overflow](https://stackoverflow.com/q/57643908/722720) and [Rust Users Forum](https://users.rust-lang.org/t/how-do-you-remove-the-last-node-from-a-singly-linked-list/31805?u=efanzh). And I think it is somet | labels: C-enhancement, A-borrow-checker, NLL-polonius


linking with `cc` failed: exit code: 1 | error: linking with `cc` failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/opt/rust/target/debug/build/log-2c3a5c1cf08eb014/build_script_buil


1.38 beta fails to bootstrap itself | When using 1.38 beta to bootstrap itself, I get: ``` error: unnecessary `unsafe` block --> src/bootstrap/builder.rs:148:19 | 148 | name: unsafe { ::std::intrinsics::type_name::<S>() }, | ^^^^^^ unnecessary `unsafe` block | ``` | labels: T-bootstrap


rustc should error instead of panic when the generator trait is not found | This somehow doesn't occur when putting the `abc` function in a non `#![no_core]` crate, yet I can't find any difference between the `libcore` version of `FnOnce` and this one. ```rust #![feature(no_core, lang_items, unboxed_closures)] #![no_core] #[lang = "sized"] pub trait Size | labels: E-easy, I-ICE, T-compiler, E-help-wanted, C-bug, A-coroutines


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


Default sysconfdir | I'm not sure this is actually a bug but it seems like it could be. The default sysconfdir in config.toml is `/etc`; which means it bypasses the user-defined prefix, in turn resulting in the installation failing if not running as root (even when installing to a user folder or, as  | labels: C-enhancement, P-low, T-bootstrap


Const function sized arrays fail to evaluate `Sized` bound | Hello, I was trying to have generic arrays that occupy as much of a single cache line as possible, but get a compile error when trying to use `std::mem::size_of<T>()`, as the `T: Sized` constraint seems to be evaluated later than [T; N] seems to require the value. Is this behavio | labels: A-trait-system, T-compiler, C-bug, A-const-eval


Wasm code failing regression probably related to update to LLVM 9 trunk | # Summary: The following piece of code fail when compiled to wasm32-unknown-unknown since nightly-2019-07-18. This nightly introduces https://github.com/rust-lang/rust/pull/62592/files so probably related. # Regression test: ```rust pub fn get() -> u128 { let d = [0, 0, 32, 59, 1 | labels: A-LLVM, P-medium, T-compiler, regression-from-stable-to-beta, I-unsound, O-wasm


Migrate test suite to use run-pass stdout/stderr testing | Where possible, we should prefer to use the functionality added by https://github.com/rust-lang/rust/pull/63825 instead of `std::process` and the like. At least one such test is known, but it's possible more can be found. | labels: E-easy, C-cleanup, A-testsuite, E-mentor


Building a no_std cdylib results in "syntax error in VERSION script" | I'm trying to build a pure `no_std` `cdylib` with no external library dependencies. For an initial proof of concept, I tried to create such a library using the following code: ```Cargo.toml```: ```toml [package] name = "cdylib-no-std" version = "0.1.0" edition = "2018" [lib] crat | labels: A-linkage, T-compiler, C-bug


./x.py build --help gives misleading help | ``` $ ./x.py build --help [...] For a quick build of a usable compiler, you can pass: ./x.py build --stage 1 src/libtest ``` But in practice: ``` $ ./x.py build --stage 1 src/libtest Updating only changed submodules Submodules updated in 0.13 seconds Finished dev [unoptimized] ta | labels: E-easy, E-mentor, T-bootstrap, C-bug


ICE on borrow check `check_loans` on stable | I don't know how to minimize this... ``` $ RUST_BACKTRACE=1 cargo run Compiling baguetteland v0.1.0 (/nobackup/baguetteland) thread 'rustc' panicked at 'assertion failed: self.bccx.region_scope_tree.scopes_intersect(old_loan.kill_scope, new_loan.kill_scope)', src/librustc_borrowc | labels: I-ICE, A-borrow-checker, T-compiler, C-bug


Intra-rustdoc Links Do Not Work For Anything | ## Stats: toolchain version: stable-x86_64-unknown-linux-gnu (default) rustc version: rustc 1.37.0 (eae3437df 2019-08-13) cargo version: cargo 1.37.0 (9edd08916 2019-08-02) ## Steps to reproduce: 1. Run `cargo init example` 2. Edit `example/src/main.rs` 3. At the top, add `//! Ch


error: failed to run custom build command for `ring v0.14.6` | error: build failed [root@eulerOS:/opt/rust]# RUST_BACKTRACE=1 cargo build --target x86_64-unknown-linux-musl Compiling ring v0.14.6 Compiling num-traits v0.2.8 Compiling atty v0.2.13 Compiling rand v0.4.6 Compiling base64 v0.10.1 Compiling want v0.2.0 Compiling tokio-resource-po


Better error message for 'is private' | ``` mod foo { use bar::A; mod bar { pub struct A {} } } use foo::A; fn main() {} ``` Produces the error: ``` error[E0603]: struct `A` is private --> src/main.rs:9:10 | 9 | use foo::A; | ^ ``` [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gis | labels: C-enhancement, A-diagnostics, A-visibility, T-compiler, A-suggestion-diagnostics


Undefined Behavior in safe code that unwinds out of `extern "C"` function | **UPDATE**: this optimization is perfectly correct. It only breaks code that already has undefined behavior. This is however an issue since until #52652 is fixed we want to keep such code working. **ORIGINAL TITLE**: mis-compilation of noreturn extern "C" definitions that unwind  | labels: A-FFI, T-lang, I-unsound, C-bug


`Ref` methods unnecessary? | I'm a bit confused about the methods on `std::cell::Ref`. Are there any use cases for the `clone`, `map`, and `map_split` methods? I understand the value for `RefMut` (since there can only be one mutable borrow, you can change what it points to split one borrow into multiple refe


Excess semicolon lint produces wrong diagnostics with async main and derive macro | The new lint for excess semicolons (https://github.com/rust-lang/rust/pull/62984) has some weird behaviour when the lint is triggered inside an async function that is transformed using a procedural macro. Rustc version: 1.39.0-nightly (9b91b9c10 2019-08-26) Compiling this: ```rus | labels: A-lints, T-compiler, C-bug


rustc diverges on large dangling integer slice | I wanted to test our handling of slices that are "too big" (bigger than the largest possible allocation), so I wrote: ```rust use std::usize; #[repr(C)] #[derive(Copy, Clone)] struct SliceRepr { ptr: *const u8, len: usize, } union SliceTransmute { repr: SliceRepr, slice: &'static | labels: E-needs-test, A-const-eval


Add optional span to `require_lang_item` for diagnostics with more context | [`fn require_lang_item(LangItem)`](https://github.com/rust-lang/rust/blob/615c46086a994f088c9ed569fc36df229ae115b6/src/librustc/middle/lang_items.rs#L384-L388) should also take an optional `Span` to [avoid output without context](https://github.com/rust-lang/rust/pull/63917/files | labels: E-easy, C-enhancement, A-diagnostics, T-compiler, A-lang-item


Miscompilation with target-cpu=znver1 (AMD Ryzen 1000/2000 series) on Windows + LLVM 9. | On any recent MSVC nightly, compiling with `release` profile with `RUSTFLAGS = "-C target-cpu=native"` results in either `STATUS_ACCESS_VIOLATION` or `STATUS_HEAP_CORRUPTION` depending on the crate. Many crates work, but others don't. Among those that fail some use SIMD. `target- | labels: I-crash, A-LLVM, P-high, T-compiler, regression-from-stable-to-stable, C-bug


Hint on missing tuple parens in pattern | It'd be nice to smartly hint about missing tuple parentheses in patterns, especially in positions where parentheses nesting is required. Example of incorrect code: ```rust fn main() { match Some((1, 2)) { Some(x, y) => {} None => {} } } ``` The error: ```rust error[E0023]: this p | labels: C-enhancement, A-diagnostics, E-mentor, T-compiler, E-help-wanted, E-medium


Bootstrap fails to build in not completely clean environment | * `git checkout 53df91a9b24ad999e7ca896447af6f5f74fe43bc` (today's master) * `make prepare` ``` [...] Compiling bootstrap v0.0.0 (/home/jethro/projects/rust/src/bootstrap) Finished dev [unoptimized] target(s) in 7.16s ``` (success) * `git checkout 72bfc375356b56933955e07471f91ef9 | labels: T-bootstrap, C-bug


Call pinned method from Trait on generic parameter | I've found a problem regarding [Pin](https://doc.rust-lang.org/nightly/std/pin/struct.Pin.html) that I just can't solve and the current Nightly compiler gives a misleading suggestion. [This playground example serves well as a minimalist example](https://play.rust-lang.org/?versio | labels: A-diagnostics, T-compiler, C-bug, A-suggestion-diagnostics


redundant_semicolon and clippy::no_effect tripped without emitting line numbers | Using nightly-2019-08-26. In [this TiKV PR](https://github.com/tikv/tikv/pull/5261#issuecomment-525569617) we upgraded the compiler. Our tidb_query component tripped the redundant_semicolon lint (and seemingly in turn clippy::no_effect) but rustc/clippy did not tell us the line n | labels: A-lints, A-diagnostics, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


E0425 suggestion has `fn` keyword before `use ...;` | ```shell $ rustc --version rustc 1.39.0-nightly (4cf767307 2019-08-18) $ cargo --version cargo 1.38.0-nightly (e853aa976 2019-08-09) $ cat rust-toolchain nightly-2019-08-19 ``` ```rust #[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] pub struct FileId(pub usize | labels: A-diagnostics, T-compiler, C-bug, A-suggestion-diagnostics, D-invalid-suggestion


Confusing error message on private newtype field | ``` $ rustc --version rustc 1.37.0 (eae3437df 2019-08-13) ``` To reproduce: ``` [dependencies] actix-web = "1.0.5" ``` ``` use actix_web::web; fn main() { let a: web::Query<i32> = web::Query(4); } ``` `Query` is defined as: `pub struct Query<T>(T);` Yet, the error message: ``` er | labels: A-diagnostics, A-visibility, T-compiler, C-bug, A-suggestion-diagnostics


Incorrect error message when accessing private field of union | ```rust #[derive(Copy, Clone)] pub struct B; mod a { pub union U { pub a: i32, b: crate::B, } } fn new(a: i32) -> B { unsafe { a::U { a }.b } } ``` ([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d461d59d40a77187aa1f38e1861f0801)) Errors: `` | labels: E-easy, A-diagnostics, A-visibility, T-compiler, C-bug


Weird segfault when trying inline asm on macOS in Rust | Hello! I tried this piece of code: ```Rust #![feature(asm)] fn main() { unsafe { asm!(" xor rax, rax .process_loop: nop add rax, 1 cmp rax, 500 jne .process_loop ": : :"rax" :"intel") }; } ``` On windows it compiles and runs normally. On my macOS it compiles with no error or warn | labels: O-macos, A-inline-assembly, T-compiler, requires-nightly


Reducing the memory/bandwidth footprint of submodules with ./x.py? | I recently tried to compile rust by using the `./x.py` script. I noticed that the first thing that happens is a full clone of all the git submodules (see https://github.com/rust-lang/rust/blob/master/src/bootstrap/bootstrap.py#L679-L687). Cloning the whole history of all the subm | labels: C-enhancement, T-bootstrap


Self::fn_name returns non-static fn item | It's hard to describe, but this fails to compile [playground](https://play.rust-lang.org/?gist=b8ea20af2f92d025b0fa2176346a971e): ```rust trait Foo { fn bar() { Self::bar.type_id(); // Any::type_id, Any requires 'static } } ``` Error: ``` error[E0310]: the parameter type `Self` m | labels: A-lifetimes, A-trait-system, T-lang, T-compiler, C-bug


Unify errors for Unit pattern on Tuple and Struct variants | Code Example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=73d19f6e2a08205bb03e3741d6588de5)): ``` enum MyEnum { Tuple(i32), Struct { s: i32 }, } fn foo(en: MyEnum) { match en { MyEnum::Tuple => "", MyEnum::Struct => "", }; } ``` <img width | labels: E-easy, C-enhancement, A-diagnostics, P-low, T-compiler, A-suggestion-diagnostics


Lint against overlapping pattern ranges and pattern ranges with small holes caught by `_` | For both exclusive(nightly) and inclusive range patterns, we don't have any lint about overlapping ranges. We probably should complain about `100..=500` being partially covered already. This would minimize the likelihood of the following off-by-one error going unnoticed: ``` fn m | labels: C-enhancement, A-lints, A-diagnostics, T-lang, T-compiler


Suggest borrowing when doing `if let Some(_)` from non-Copy ADT | Just got this error: ``` error[E0382]: borrow of moved value: `x` --> src/librustc_mir/hair/pattern/_match.rs:1614:53 | 1611 | if let Some(range) = x { | ----- value moved here ... 1614 | debug!("intersection {:?}", x); | ^ value borrowed here after partial move | = note: move oc | labels: C-enhancement, A-diagnostics, T-compiler, A-suggestion-diagnostics, D-papercut, D-newcomer-roadblock


Misleading error messages about lifetimes and borrowing | The error message is misleading that it led me to another approach through which I can't fix my program. ```log error[E0597]: `line` does not live long enough --> src/main.rs:24:30 | 24 | let spt: Vec<&str> = line.split(char::is_whitespace).collect(); | ^^^^ borrowed value does n | labels: A-diagnostics, A-lifetimes


async-await: mutually recursive functions compile sometimes | In the following code: ```rust async fn rec_1() { rec_2().await; } async fn rec_2() { rec_1().await; } ``` This gives an error when it is a part of a `lib` crate. However, as a part of a `bin` crate, it compiles. Here's an [erroneously compiling playground link](https://play.rust | labels: A-async-await, AsyncAwait-Polish


Dependencies with build script fail on FreeBSD + 1.39 nightly | Tested on various crates like bindgen, backtrace, async-std, etc, that has one or more -sys dependencies that include a build.rs file. All such deps fail with errors like: ``` error: failed to run custom build command for `openssl-sys v0.9.49` Caused by: process didn't exit succe | labels: P-medium, regression-from-stable-to-nightly, T-compiler, O-freebsd, C-bug


Why can't update libc to 0.2.63 or 0.2.64? | I notice by default we are using libc 0.2.61. and we can update it to 0.2.62 if using "cargo update -p libc". But I see the latest libc version is 0.2.64. Is there any special reason that prevent us from using the version 0.2.63 or version 0.2.64? Thanks, Baoshan


Segfaults on FreeBSD in some cases since 1.37.0 | I have a crate that links to library in base for FreeBSD, up until 1.37 it was working fine. Since 1.37 and after it started segfaulting on certain calls. I can't reproduce it outside of FreeBSD, but here is is the "minimal" [example](https://github.com/Inner-Heaven/libnv-rs/blob


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


Tracking issue for making `Vec::new` a `const fn` | This tracks stabilization of the `const_vec_new` feature, introduced in https://github.com/rust-lang/rust/pull/50233, which allows calling `Vec::new` in a constant expression. | labels: A-collections, T-lang, T-libs-api, B-unstable, C-tracking-issue, A-const-eval


Matches on tuples of boxes present incorrect dereference help text | Consider the following broken code([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f9637cf1265ffb17eeac765c000ba345)): ```rust struct S(i32); fn main() { let x = Box::new(S(1)); let y = Box::new(S(2)); let f = match (x, y) { (S(a), S(b)) => (a | labels: A-diagnostics, T-compiler, C-bug, A-suggestion-diagnostics, D-invalid-suggestion


RangeBounds<T> impl for Range*<&T> is missing ?Sized | Much like the impl for `(Bounds<&T>, Bounds<&T>)`, `impl<T> RangeBounds<T> for RangeFrom<&T> {` could use a `T: ?Sized`. This would allow ```rust let map = BTreeMap::<String, i32>::new() map.range::<str, _>("a"..); ``` to compile the way it does when using Bound. (Unfortunately I | labels: E-mentor, T-libs-api, C-feature-request


Help with enum of Box through FFI | Hello everyone! I am having an issue understanding how to share an Enum, where some variants holds a Box, through FFI boundary. The Enum looks like this: ```Rust #[derive(Debug)] #[repr(C)] pub enum SchemeType { Ip, Bytes, Int, Bool, Array(Box<SchemeType>), Map(Box<SchemeType>),


C++ compiler cache causes compiler segfaults on ARM | Since the LLVM 9 update, rustc will segfault on ARM hosts with opt-level > 0 and codegen-units > 1. The possible cause is that GCC ARM C++ ABI is not very stable (sometimes you will see the "parameter passing of argument of type ... changed in GCC \<version\>" note) and sccache d


Incorrect unused warning when value is used for a comparison inside a function invocation | The following code generates an unused variable warning for x: ``` fn test(v: bool) { println!("value is {}", v); } fn main() { let mut x: Option<u32> = None; x = Some(5); test(x.unwrap() == 5); } ``` ``` --> test.rs:6:11 | 6 | let mut x: Option<u32> = None; | ^ | = note: `#[warn


Incorrect error reported for doc comment on if statement | Example code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3391ce9f657a47424a118ad9a6941a99)): ```rust fn main() { /// Accidental doc comment if true { } } ``` Error: <img width="532" alt="image" src="https://user-images.githubusercontent.c | labels: A-diagnostics, T-compiler, C-bug


Recursive fn with varying const generic parameter causes ICE. | ```rust #![feature(const_generics)] fn mk_array<T, const TO: usize>() -> [T; TO] { panic!(); } fn uperms<const DICE_NUM: usize>() -> Vec<[u8; DICE_NUM]> { if DICE_NUM <= 1 { return vec![mk_array::<u8, {DICE_NUM}>()]; } else { let pperms = uperms::<{ DICE_NUM - 1 }>(); panic!(); }


debuginfo/boxed-struct test fails with LLDB 8 | On a fresh clone (b3146549ab) of the `rust` repro, using LLVM/clang/lldb 8.0.0, the `debuginfo/boxed-struct` test fails due to #47938. As noted in my [comment there](https://github.com/rust-lang/rust/issues/47938#issuecomment-526878164), the cause is the local variable `unique` s


vec![] creates broken vector of tuples with nulls in memory if a lot of elements passed. | **Description:** for example I can create vector with over 50K elements, using vec![/* elements */]; When I iterate values in vector I can meet that my tuple value is null (0), and next values will be null too. I tried same with array, &[(i64, i64, i64)].to_vec(), but it's workin | labels: T-compiler, C-bug


`-(-0.0)` raises const_err "attempt to negate with overflow" | ```rust fn main() { let _ = -(-0.0); } ``` ``` error: this expression will panic at runtime --> test.rs:2:13 | 2 | let _ = -(-0.0); | ^^^^^^^ attempt to negate with overflow | = note: `#[deny(const_err)]` on by default error: aborting due to previous error ``` <details><summary>M | labels: E-easy, A-lints, E-mentor, T-compiler, C-bug, A-const-eval


Automatic dark theme still doesn't work | Follow-up to #61079, #61236, #63830, and #63847. Same symptoms as #63830. Additionally, I'm seeing styles from both light.css and dark.css active, and the ones in light.css are taking precedence over the ones in dark.css even though the system is in dark mode. Tested on <https://


`unused_parens` false-positive on mutable binding inside &-pattern | ```rust for &(mut _x) in &[1, 2, 3] { // _x: mutable binding to a copied element } ``` `unused_parens` suggests removing parens, but doing so will turn the pattern into a `&mut` pattern. ``` warning: unnecessary parentheses around pattern --> test.rs:2:10 | 2 | for &(mut _x) in &


Diagnostics for an immutable reference to an iterator | This problem comes up in generic contexts, but the simplest code to reproduce is: ```rust let iter = &[1,2,3].iter(); for i in iter { } ``` Results in: > error[E0277]: `&std::slice::Iter<'_, {integer}>` is not an iterator > ```text > | for i in iter { > | ^^^^ `&std::slice::Iter< | labels: C-enhancement, A-diagnostics, T-compiler, A-iterators, A-suggestion-diagnostics, D-newcomer-roadblock


Tracking issue for cstring_from_vec_of_nonzerou8 | Tracking issue for `impl From<Vec<NonZeroU8>> for CString`. Code added in #64069


Confusing documentation on mem::transmute | [Documentation on mem::transmute](https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives) presents the following piece of code: ```rust let store = [0, 1, 2, 3]; let mut v_orig = store.iter().collect::<Vec<&i32>>(); // Using transmute: this is Undefined Behavior, and a  | labels: A-docs


debuginfo/issue22656 test assertion fails with LLDB 8 | ## Problem The test `debuginfo/issue-22656` has the following failing assertion: ``` // lldbg-check:[...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct, y: 123, z: ZeroSizedStruct, w: 456 } ``` Note the `g`, so this is for an LLDB that is _not_ rust-enabled. Here's what I see | labels: A-testsuite, A-debuginfo, C-bug


Types cannot refer to persistent data from generic elements | This is a pseudo-code of a part of my library, it has not been compiled, because types, for some reason not clear to me, cannot refer to persistent data from generalized elements. ``` rustc 1.39.0-nightly (4295eea90 2019-08-30) ``` ```rust trait CheckErr { const U: usize = 0; typ


Paths involving 'super' don't work from within a function | The following code compiles correctly: ```rust struct Foo; mod inner { use super::Foo; } ``` However, when wrapped in a function: ```rust fn outer() { struct Foo; mod inner { use super::Foo; } } ``` it gives the following error: ``` error[E0432]: unresolved import `super::Foo` -- | labels: A-resolve, T-lang, C-feature-request


[rustdoc] Convert double-hyphen to dash in docs | It would be nice to get rustdoc to convert double-hyphen (`--`) (probably just when surrounded by spaces?) to a dash character (`–`) in doc-comments. People tend to use double-hyphen in code instead of the actual actual character, since it's easier to type on most keyboards. I re | labels: T-rustdoc, C-feature-request, A-markdown-parsing


cargo test gives up compiling after one error | I'm making a big refactor. When attempting to clean up my tests, `cargo test` appears to go file by file, alphabetically when compiling the tests. As soon as one `#[test]` has a compile error, the build is aborted. - `#[test]`s following the failure do not get compiled. - Subsequ | labels: C-enhancement, A-diagnostics, A-trait-system, T-compiler


UnwindSafe and RefUnwindSafe should be in libcore | I *think* that would be useful to allow pure no_std libraries to implement those traits without needing the `std` cargo feature. cc @gnzlbg, you've asked about this #40628. | labels: T-libs-api, C-feature-request


ICE when `into_iter()` is called on a const generic array of type T where size is unkown. | ~~Might be similar to #60744, idk.~~ This causes an ICE: ```rust #![feature(const_generics)] fn combinator<T, const S: usize>() -> [T; S] {} fn main() { combinator().into_iter(); } ``` Backtrace: https://gist.github.com/ZeGentzy/d8a1eaa26fe3551e0c5590885265884a So does this: ```r | labels: I-ICE, A-incr-comp, A-const-generics, requires-nightly, F-const_generics


Spurious `unsized` error on resolution error | the `bar` function does not exist, so its return type is implicitly inferred to be whatever type is consumed further down. If the inferred type is unsized, we may get additional errors though. I think we should find a way to silence that additional error. ```rust fn foo() { let x | labels: A-diagnostics, T-compiler


Add warnig for assignment to temporary | For simple useless code: ``` fn main() { const N: (usize, usize) = (10, 20); N.0 = 0; println!("{:?}", N); } ``` rust compiller no any warnings/errors. But clippy have an one display item: ``` warning: assignment to temporary --> src/main.rs:3:5 | 3 | N.0 = 0; | ^^^^^^^ | ``` I t


Missed-optimization: extern "C" fn type calls are not nounwind | See https://rust.godbolt.org/z/9UvEyu ```rust #![feature(unwind_attributes)] extern "C" { #[unwind(allow)] fn foo(); // fn bar(); static bar: extern "C" fn(); static mut BAR: i32; } struct Foo; impl Drop for Foo { fn drop(&mut self) { unsafe { BAR = 42; } } } pub unsafe fn unwind | labels: A-LLVM, I-slow, A-FFI, T-lang, T-compiler, C-optimization


trait impl specialization does not support types out of constraints | As this [example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e06032f3d222d3a15d84521356955782) ```rust #![feature(specialization)] trait A { fn a(); } default impl <T: ToString> A for T { fn a() {} } impl A for i32 { fn a() {} } impl A for () { fn a(


Inconsistent analysis results for unsafe blocks and operators | related: https://github.com/rust-lang/rustfmt/issues/3770 rust playground link: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ef4769175cb5b4febb445b05c1e27b82 The second !unsafe block return &&bool. I think the second block should return bool. ```rust f


Improve `rustc::hir::PatKind::Wild` | The [`slice_patterns` feature](https://doc.rust-lang.org/nightly/unstable-book/language-features/slice-patterns.html) introduces the `..` wildcard. It seems classified as `rustc::hir::PatKind::Wild` along with `_`. However, `Wild` currently has no information to distinguish betwe | labels: C-enhancement, T-compiler, A-HIR


Tracking issue for `std::hint::black_box` | This is a tracking issue for the RFC `std::hint:_black_box`. Original RFC: [RFC 2360](https://rust-lang.github.io/rfcs/2360-bench-black-box.html) **Public API:** ```rust // std::hint pub fn black_box<T>(dummy: T) -> T; ``` **Steps:** - [x] Implementation - [x] FCP - [ ] Stabiliza | labels: B-RFC-approved, T-libs-api, T-compiler, C-tracking-issue, disposition-merge, finished-final-comment-period


false positive "unreachable expression" | ````rust pub fn main() { std::process::Command::new("test").output().unwrap_or(panic!("oh no")); } ```` rustc warns that the entire line is an unreachable expression ```` warning: unreachable expression --> src/main.rs:3:6 | 3 | std::process::Command::new("test").output().unwrap_ | labels: A-lints, T-compiler, C-bug


or_patterns: `unused_parens` lints erroneously on `_a @ (0 | 1)` | ```rust #![feature(or_patterns)] #![allow(incomplete_features)] fn foo() { match 0 { _a @ (0 | 1) => {} _ => {} } let () = 0; // Prevent the ICE in MIR. } ``` results in: ```rust warning: unnecessary parentheses around pattern --> src/lib.rs:6:14 | 6 | _a @ (0 | 1) => {} | ^^^^^^ | labels: A-lints, T-compiler, C-bug, requires-nightly, F-or_patterns


Append implementation of Vec doesn't look safe | Randomly looking at the code of `append()`, https://github.com/rust-lang/rust/blob/master/src/liballoc/vec.rs#L1157, doesn't look safe: ```rust self.append_elements(other.as_slice() as _); other.set_len(0); ``` As, we already copy and set the new `len` before reset other vector `


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


Weird behavior with type errors in macros | Unfortunately I don't have a reproducer but this is what I think I know: - I had some nested macros that took types as arguments and implemented traits. - Somewhere in the chain I was using a `HashMap`. - `HashMap` was not imported in the scope where the macro was invoked (same s | labels: A-diagnostics, A-macros, T-compiler, E-needs-mcve


Adding method to `consume` an iterator efficiently | Currently, mapping methods for iterator, e.g. `map` and `filter` are implemented in a lazy manner. Which means they would not be calculated until further `consumption`. However, sometimes it can be the case that given an `Iterator` (whatever it actually is) . we just wanted its s | labels: T-libs-api, C-feature-request


faults and weird behavior on armv5te | I'm trying to use rust binaries on an armv5te gateway using yocto(thud, meta-atmel). Depending on the configuration(rust-version, target-flags, lto, optimization) I have anything from a (luckily) working binary over wrong logic-level behavior to segmentation faults. During runtim | labels: O-Arm


non-send futures error at point of use, but could cite point of definition in some cases | Consider this example ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=5f67107e3c9fb3e10aafd83295b3fbf4)): ```rust #![feature(async_await)] use std::sync::Mutex; fn is_send<T: Send>(t: T) { } async fn foo() { bar(&Mutex::new(22)).await; } asy | labels: C-enhancement, A-diagnostics, T-compiler, A-async-await, AsyncAwait-Polish, AsyncAwait-Triaged


rustc: Migrate `__register_diagnostic` and friends to stable proc macros | A few macros used internally in `rustc` for working with error codes still use legacy proc macros (aka syntactic plugins) making `rustc` one of the last (*the* last?) noticeable users of the feature in the ecosystem. They need to be moved to `librustc_macros` and re-implemented u | labels: C-cleanup, A-diagnostics, A-macros, T-compiler


overflow evaluating the requirement `[closure@main.rs:41:17: 41:38]: std::ops::Fn<(&i32,)> | Hi Rust team I am pretty new to Rust, but believe I might have found a bug in the rustc compiler that causes the trait checker to loop. Here's the program I am trying to compile: ```rust struct BinTree<V> { left: Option<Box<BinTree<V>>>, right: Option<Box<BinTree<V>>>, value: V }


E0507 E0009 should be mutually exclusive | E0507 E0009 should be mutually exclusive ### E0009 cannot bind by-move and by-ref in the same pattern ### E0507 cannot move out of borrowed content # Example [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9f2f8562e3e24ff49c943fd86cc0ea5d) ``` | labels: A-diagnostics, T-compiler


Drop glue is always inlined into caller crate | I was investigating the compile time of a crate recently and came across a surprising aspect of the compiler. It looks like the drop glue, or rather the code necessary to drop a type, is inlined unconditionally into the caller crate, even if there are no generics in play. This pr | labels: A-codegen, I-compiletime, T-compiler


ICE in import resolution with renamed crate import | I tried renaming a crate import and a bunch of dependent uses of the crate, and ended up seeing a unexpected panic in the compiler. Log is here: https://gitlab.parity.io/parity/substrate/-/jobs/223357 ``` Compiling srml-support v2.0.0 (/builds/parity/substrate/srml/support) threa | labels: A-resolve, I-ICE, P-medium, T-compiler


rustdoc generates illegal
 in  for struct-like enums | See also #7529, #60403 and #60865 When using a struct-like enum, rustdoc generates the following code for the enums fields: (hand formatted) ```html
Fields of ParseU64Error

 <span id="varia | labels: T-rustdoc, C-bug


./x.py clippy is broken | commit 5f42f3e108db9390038a93fc95d9376aa871ae34 Running `./x.py clippy` results in the following message: ``` $ ./x.py clippy Updating only changed submodules Submodules updated in 0.05 seconds Finished dev [unoptimized] target(s) in 0.11s Checking rustdoc artifacts (x86_64-apple | labels: T-compiler, T-bootstrap, C-bug


ThinLTO and `-o`  compiler option can lead to duplicate object file inclusion in staticlib | I've verified this on macOS 10.14/Xcode 10.3 as well as Ubuntu 14.04/GCC 4.8 rustc -V: rustc 1.36.0-nightly (50a0defd5 2019-05-21) (although the code i mention is the same in master) tl;dr object files (`.o`) prefixes are inferred from `-o`, but lto object file exclusion uses cra | labels: A-linkage, O-linux, O-macos, P-high, T-compiler


cdylib for the target `wasm32-wasi` | <!-- Thanks for filing a 🐛 bug report 😄! --> **Problem** cannot produce cdylib for the target `wasm32-wasi` **Steps** <!-- The steps to reproduce the bug. --> 1. Add "cdylib" to the Cargo.toml, e.g. ``` cargo new check-wasi && cd check-wasi echo "[lib]" >> Cargo.toml echo "crate- | labels: T-compiler, O-wasm, C-feature-accepted


`clippy-driver` no longer builds after rust-lang/rust#64160 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64160, 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


E0631 has duplicated diagnostics | https://github.com/rust-lang/rust/blob/master/src/test/ui/anonymous-higher-ranked-lifetime.stderr has duplicated redundant diagnostics. We should come up with a deduplicating strategy to avoid them. | labels: E-easy, C-enhancement, A-diagnostics, P-low, T-compiler


No unnecessary parentheses warning in types | Types can be parenthesized, which is useful for e.g. `dyn (Foo + 'static)` or similar, but often these parentheses are unnecessary. Whenever a trivial type is parenthesized the compiler should suggest to remove the parentheses ```rust pub fn foo() -> (i32) { 42 } ``` ([Playground | labels: E-easy, C-enhancement, A-lints, E-mentor, T-compiler, E-help-wanted


File and Metadata should document reasons to prefer *not* to use `is_file()` | As per https://github.com/rust-lang/rust-clippy/issues/4503, there's a bit of a trap you can fall into if you use `is_file()` as a predictor for "can I probably open and read bytes from this thing". You *generally* don't want to assert `is_file()` for user specified paths, **espe | labels: C-enhancement, T-libs-api, A-docs


Unused lifetime cause ICE | The following code ICE's on stable, beta and nightly: ```Rust use core::mem::size_of; struct Bug<'s> { array: [(); size_of::<&Self>()], } ``` <details> <summary>Backtrace:</summary> ``` Compiling playground v0.0.1 (/playground) error: internal compiler error: src/librustc_mir/bor | labels: E-hard, I-ICE, E-needs-test, P-medium, T-compiler, A-NLL


Lifetime error when Send is enforced on async function return type | Just like a lot of lifetime issues, I'm not actually sure whether this is a bug in the compiler or a bug in my code. The following code: ```rust use std::pin::Pin; use std::future::Future; trait FooRef<'a> { type Elem; fn next_elem(self) -> Pin<Box<dyn Future<Output = Self::Elem> | labels: T-lang, T-compiler, A-async-await, AsyncAwait-Triaged


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


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


Make x86_64-linux-kernel target be tier-2 | This would mean compiling libcore in CI, and publishing those artifacts. This would add a lot of value to the efforts to get Rust support into the mainline kernel, since it will mean all the building can be done with just cargo, no 3rd party tools. I'm happy to do whatever work i


Extend `span_label` to include fallback operation | There are occassions where `DiagnosticBuilder::span_label` can be called with a `DUMMY _SP`. The current behavior is we don't show those labels at all in the output. In some cases that is the correct behavior. In others, we proactively look for `DUMMY_SP`s and emit a `note` inste | labels: C-cleanup, A-diagnostics, T-compiler, D-diagnostic-infra


Cross-compilation of rust 1.37.0 fails with multiple crate matches | Having dealt with issue #63828, another one crops up which is more directly related to rust. While building, I hit several instances of this particular error message: ``` Compiling rustc-ap-arena v491.0.0 Compiling rustc-ap-syntax_pos v491.0.0 Compiling rustc-ap-rustc_errors v491 | labels: A-cross, O-netbsd


1946-intra-rustdoc-links issue | <!-- Thanks for filing a 🐛 bug report 😄! --> **Problem** <!-- A clear and concise description of what the bug is. --> <!-- including what currently happens and what you expected to happen. --> Links created according to [1946-intra-rustdoc-links](https://rust-lang.github.io/rfcs/ | labels: T-rustdoc, C-bug, A-intra-doc-links


Maximum number of backtrace frames is not configurable | The standard library currently has a [hard-coded limit of 100 frames](https://github.com/rust-lang/rust/blob/618768492f0c731fcb770dc2d178abe840846419/src/libstd/sys_common/backtrace.rs#L18) when printing a backtrace. However, some applications may have larger call stacks - withou | labels: T-libs-api


Add Fuchsia to actually_monotonic | std's internal [actually_monotonic](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/time.rs#L311-L315) function is used to determine which platforms' clocks are truly monotonic. Those that aren't (that have been observed to sometimes go backwards in practice) re


Consider moving out-of-line module loading from parser to expansion | Due to module loading parser has to do some not very appropriate for a parser things like - expanding `cfg`s on modules (duplicated with expansion) - keeping the current filesystem position (duplicated with expansion) We also don't really need to load those files until we need to | labels: A-frontend, A-parser, A-macros, T-compiler


Poor error message when using `self: Box<Self>` | The following code produces a very confusing error message. ```rust struct Foo; impl Foo { fn consume(self: Box<Self>) {} } fn bar() { let x = Foo; x.consume(); } ``` ``` error[E0599]: no method named `consume` found for type `Foo` in the current scope --> src/lib.rs:9:7 | 1 | st | labels: A-diagnostics, T-compiler


Cannot declare const in function scope that depends on generic impl const | The compiler misreports the following as error 401, saying you can't use generic parameters from an outer function. ```rust trait X { const Y: i32; } trait Z { fn a() -> i32; } struct B<T> { t: std::marker::PhantomData<T> } impl<T: X> Z for B<T> { fn a() -> i32 { const C: i32 = T


annotate-snippet emitter: Add UI test where `annotated_files` count is > 1 | Part of #59346 It would be nice to have a UI test for the annotate-snippet emitter, that includes annotations that span multiple files. The goal of this issue is to find and add such a test. ## Instructions A simple way to look for this, would be to add this code: ```rust if anno | labels: C-enhancement, A-diagnostics, E-mentor, T-compiler, E-help-wanted


Curious errors with misused qualified method call syntax | The qualified method call syntax (`<Type as Trait>::method()`) accepts both tyṕes and modules as the trait. This leads to some interesting errors. ``` fn main() { <f32 as f32>::ceil(1.0); <f32 as String>::ceil(1.0); <f32 as std>::ceil(1.0); } ``` Results in ``` error[E0576]: cann | labels: A-diagnostics, T-compiler, C-bug, D-papercut


[Feature Request] compile time arguments | Currently the closest thing to C's preprocessor conditional compilations we have is the cfg and the features. But there's one missing piece, and that's and that's values in those variables. Currently the design idea of features is to be incremental which doesn't make sense with h


HashMap slow compared to hashbrown implementation | Since Rust 1.36 the HashMap implementation in the standard library should be ported from [hashbrown](https://github.com/rust-lang/hashbrown) (see #56241)). But when benchmarking both, hashbrown is a lot faster (3x) on inserts than the HashMap in the standard library: ```bash $ ca


`clippy-driver` no longer builds after rust-lang/rust#64209 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64209, 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


Tracking issue: slice_internals? | I was looking at the unstable [`core::slice::memchr`](https://doc.rust-lang.org/core/slice/memchr/fn.memchr.html) API, and couldn't figure out the corresponding tracking issue (it's still set to `#0`). Is there meant to be one? How can I read up on its stabilization status? Thank


LLVM doesn't build  on the first try when cross compilling to windows-gnu host | Running `./x.py build --host x86_64-pc-windows-gnu --target x86_64-pc-windows-gnu` from Linux will fail on building LLVM for Windows (so it's 2nd LLVM build) because somehow LLVM_ON_UNIX is defined: ``` /home/mateusz/Projects/rust/rust/src/llvm-project/llvm/include/llvm/Support/F | labels: A-LLVM, O-windows-gnu, T-bootstrap, C-bug


Missed optimization: fn type calls returning never are not noreturn | We currently do not annotate calls to function types returning Never as `noreturn`, but we probably should. This is similar to #64090 . | labels: I-slow, C-enhancement, A-codegen, E-needs-test, T-compiler, C-optimization


Missed optimization: catch_unwind not removed when closure never unwinds | Consider this C++ code (https://gcc.godbolt.org/z/iaSj6g) ```c++ extern "C" void foo() noexcept; int bar() { try { foo(); return 42; } catch(...) { return 13; } } ``` which gets optimized to: ```asm bar(): # @bar() push rax call foo mov eax, 42 pop rcx ret ``` Now consider the se | labels: I-slow, T-compiler, C-bug


Migrate to LLVM{Get,Set}ValueName2 | We currently use the C APIs `LLVM{Get,Set}ValueName` which return/take a 0-terminated `char *`, but those APIs have been deprecated a while ago in favor of `LLVM{Get,Set}ValueName2` which return/take pairs of `char *` + length (the C-friendly lowering of `llvm::StringRef`) which  | labels: C-cleanup, A-LLVM, T-compiler


Why is the code size of catch_unwind so large ? | While filling #64222 I noticed that we generate more code than C++ for `catch_unwind`. That did not feel right, since C++'s `catch` can do much more than Rust's catch unwind, e.g., filtering different types of exceptions, etc. MWE: C++ (https://gcc.godbolt.org/z/z_dgPg): ```c++ e | labels: C-enhancement, T-libs-api, T-compiler, I-heavy


fmt::Debug for right-to-left strings | When formatting strings using fmt::Debug, the normal right-to-left characters are printed as is. This will mangle the entire display line in a rather unpredicable way. [Playground demo](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=03b109a38ef2ecdd7b318f | labels: T-libs-api, C-bug


Unnecessary mov instruction | For the following code ```rust extern "C" { fn moo(a: i64); } pub unsafe fn baa(a: i64) { if a != 0 { moo(a); } moo(a); } ``` I get the following assembly ```asm example::baa: push rbx mov rbx, rdi test rdi, rdi je .LBB0_2 mov rdi, rbx ;unnecessary call qword ptr [rip + moo@GOTPC


Factor out pluralisation checks in diagnostics | The following pattern is common in diagnostic messages in rustc: ```rust format!("found {} thing{}", x, if x != 1 { "s" } else { "" }) ``` It would be good to extract all of these pluralisation checks into a function or macro: ```rust format!("found {} thing{}", x, pluralise(x))  | labels: E-easy, C-cleanup, E-mentor, T-compiler, E-help-wanted


compiler-rt missing from rustc-1.37.0-src.tar.gz | In #60981 we switched to detecting compiler-rt's presence in `src/llvm-project/compiler-rt` and enabling the `c` feature for `compiler-builtins` if present, falling back to rust-only otherwise. In the git checkout, this works fine, however the `compiler-rt` directory is missing f


`miri` no longer builds after rust-lang/rust#64230 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#64230, 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: T-compiler


Tracking Issue for Cross Compiling Doctests | This is an issue to track the functionality added by [PR#60387](https://github.com/rust-lang/rust/pull/60387), and also by extension [this PR](https://github.com/rust-lang/cargo/pull/6892) in cargo. PR#60387 adds three options to rustdoc: + `--enable-per-target-ignores` which add | labels: T-rustdoc, A-cross, B-unstable, C-tracking-issue, A-doctests, requires-nightly


Self::EnumVariant not considered const fn | When using `Self` to create an enum variant in Rust 1.37+, we get an error: ``` const VAL: Self = Self::X(42); ``` results in: ``` error: `Foo::X` is not yet stable as a const fn ``` but if the enum is constructed explicitly, the compilation succeeds: ``` const VAL: Self = Foo::X | labels: A-diagnostics, T-lang, T-compiler, C-feature-request, A-const-eval


Builder got stuck on "Updating crates.io index" | In https://github.com/rust-lang/rust/pull/64246#issuecomment-529094551, the test-various builder got stuck (https://dev.azure.com/rust-lang/rust/_build/results?buildId=7573): ``` 2019-09-07T06:17:08.8395892Z extracting /checkout/obj/build/cache/2019-08-13/cargo-beta-x86_64-unknow | labels: A-spurious, T-infra, C-bug


`cargo new` generate symbolic link of unknown purpose | Every time I create a new Rust project in a folder that is not the part of Git repository, cargo creates an extra file, which seems to be some kind of symbolic link, with the name of the following format: `_git2_a#####` where the `#` is a (random?) single digit. Example: ```conso


Incorrect mixing of reexport and definition documentation of proc macros | The PR #62855 improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using `rustc 1.39.0-nightly (6e19f3f38 2019-09-06)`. **`Cargo.toml`** ```toml [package] name = "doc-bug" version = "0.1.0" authors = ["me"] edition = "2018"  | labels: T-rustdoc, A-macros, C-bug


Diagnostics: help text for missing left-hand side in arbitrary self type | Forgetting to include the left-hand side of an arbitrary self type can give some confusing errors. This was reported by someone trying to implement a future manually, and the diagnostics threw them off. I realize diagnostics for arbitrary self types are an open issue, but figured | labels: C-enhancement, A-diagnostics, T-compiler, A-suggestion-diagnostics


Tracking issue for `bool::then_some` | Tracking issue for the `bool::then_some` method, which abstract the following pattern: ```rust if some_condition { Some(t) } else { None } ``` `bool:then` has previously been stabilised as part of this feature gate: https://github.com/rust-lang/rust/pull/79299 RFC: https://github | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, requires-nightly


E0514 compiling hello world on nightly-armv7-unknown-linux-gnueabihf | # Steps to reproduce ```sh cargo new --bin compile-fail cd compile-fail rustup override set nightly cargo check --verbose ``` Output: ``` Created binary (application) `compile-fail` package info: using existing install for 'nightly-armv7-unknown-linux-gnueabihf' info: override to


Regression of #63210 param attributes not showing in proc-macro TokenStream | It seems https://github.com/rust-lang/rust/issues/63210 isn't actually fixed. Run `cargo test -- --nocapture` and you'll see the `TokenStream` does not contain any attributes on a parameter: https://github.com/bbqsrc/params-attribute-example | labels: A-pretty, A-attributes, P-high, requires-nightly, F-param_attrs


Enforce `min_const_fn` by default in `staged_api` with opt-out | We want to switch to a scheme where everything inside the standard library requires `min_const_fn` by default. If an additional `#[rustc_not_min_const_fn]` is present, then the function will be uncallable from any `min_const_fn`. It's also important to note that a function `#[rus | labels: C-enhancement, A-attributes, P-medium, A-stability, T-compiler, A-const-eval


Error: Can't find crate for core | Hi folks! I am testing few things for a rust based operating system. I run make and I get error[E0463]: can't find create for `core` note: the `x-y-unknown-none` target may not be installed When I do `rustc --explain E0463`, I get: ``` A plugin/crate was declared but cannot be fo


Support running with new pass manager | Rustc currently still uses the legacy LLVM pass manager. There's been some discussion about enabling NewPM by default for Clang 10, so we might want to start migrating in that direction as well. To start with, we'd probably want a debug option `-Z llvm-pass-manager=new` that is n | labels: A-LLVM, T-compiler


Suggest introduction of new type argument | When writing `impl Trait<T> for X {}` We correctly complain about `T` not being in scope. We should also suggest introducing a new type argument in the correct place. | labels: C-enhancement, A-diagnostics, P-low, T-compiler, A-suggestion-diagnostics, D-papercut


RustC Panic | ``` thread 'rustc' panicked at 'assertion failed: bpos.to_u32() >= mbc.pos.to_u32() + mbc.bytes as u32', src/libsyntax/source_map.rs:842:17 stack backtrace: thread 'rustc' panicked at 'assertion failed: bpos.to_u32() >= mbc.pos.to_u32() + mbc.bytes as u32', src/libsyntax/source_m | labels: I-ICE, A-parser, A-Unicode, A-cross, T-compiler


Too many `memcpy`s | Cachegrind profiles indicate that the Rust compiler often spends 3-6% of its executed instructions within `memcpy` (specifically `__memcpy_avx_unaligned_erms` on my Linux box), which is pretty incredible. I have modified DHAT to track `memcpy`/`memmove` calls and have discovered  | labels: I-compiletime, T-compiler


SGX's std::env::args function is not thread-safe | The `args` method is defined as follows. ```rust pub fn args() -> Args { let args = unsafe { (ARGS.load(Ordering::Relaxed) as *const ArgsStore).as_ref() }; if let Some(args) = args { Args(args.iter()) } else { Args([].iter()) } } ``` Clean-up function is defined as follows; ```ru | labels: T-libs-api, I-unsound, C-bug


Instead of hiding rustdoc search bar by default, disable it | It'd have the advantage of not having the not so pretty effect we have currently when the search bar "appears". | labels: T-rustdoc, C-enhancement


Doc tests use RUST_LOG variable | ### To reproduce 1. `cargo new --lib doctest_spam` 2. `cd doctest_spam` 3. `RUST_LOG=info cargo test --doc` ### Expected results ``` Finished dev [unoptimized + debuginfo] target(s) in 0.01s Doc-tests doctest_spam running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0  | labels: T-rustdoc


Cannot opt out of LLVM MergeFunctions pass on stable | LLVM's MergeFunctions introduces aliases which can trigger a bug in macOS's `ld64` linker when compiling with ThinLTO: https://github.com/froydnj/ld64-aliases-bug For this reason Firefox has to be built with a patched version of `ld64` when compiling with xLTO. Since the bug in q | labels: A-linkage, A-LLVM, O-macos, A-codegen, T-compiler, I-unsound


Add other variants to std::io::ErrorKind enum | I was trying to rewrite Python code in Rust and I need to match against what could be `NotADirectory` (`ENOTDIR`) and saw that `ErrorKind`'s variants do not include many `errno`s present in `libc` - to speak only of the Unix platform - including the one I need. Is there a reason  | labels: T-libs-api, C-feature-request