ICE while switching a type definition between enum and trait | I have observed an ICE when I run `cargo check`. At that time I was switching a type definition between `enum` and `trait` on my own type. At first I was using a trait: ```rust trait Block { // ... } ``` on implementing it further I realized that I needed to use GAT, so I switche | labels: I-ICE, T-compiler, A-incr-comp, C-bug, E-needs-mcve


LinuxTools builder: sccache isn't used | The compiler time of [LinuxTool builds](https://dev.azure.com/rust-lang/rust/_build/results?buildId=3593&view=logs) are nearly 4 hours, which is due to the lack of sccache not being used. I believe that PRs don't have access to the same environment variable group as the auto buil | labels: T-infra


LinuxTools builder: TOOLSTATE_REPO is undefined | This may or may not have the same fix as https://github.com/rust-lang/rust/issues/62753, but the LinuxTools PR builder doesn't have access to the same variables as the auto builders, which means the docker image fails at the very end (https://dev.azure.com/rust-lang/rust/_build/r | labels: T-infra


STATUS_ACCESS_VIOLATION on 'index out of bounds' Windows 7 with lto and avx | With avx and lto enabled, index out of bounds causes a STATUS_ACCESS_VIOLATION instead of a panic. Initially encountered this problem in a program using rand::thread_rng() but narrowed down to a simpler test case found in issue #51794. I tried this code: ``` fn main() { let x = [ | labels: O-windows, P-high, T-compiler, I-unsound


hashbrown's trait implementations appear in std docs | Perhaps this is a known issue, but I've noticed that since `hashbrown` was integrated into the standard library, impls from that crate now [show up under the 'Implementations on Foreign Types' section of the trait docs](https://doc.rust-lang.org/std/iter/trait.IntoIterator.html#f | labels: T-rustdoc, A-collections, T-libs-api, A-docs, C-bug


ICE when use-ing enum variant after glob-importing same-named enum | [playpen](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=17237a55fd54a2981a6113425362cfce) Reproduction code: ```rust mod foo { pub enum Foo { Foo(i32), } } use foo::*; use Foo::Foo; ``` ``` thread 'rustc' panicked at 'assertion failed: directive.imported | labels: A-resolve, I-ICE, P-medium, T-compiler, C-bug, glacier


"Foo is ambiguous" even though it's not | [playpen](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=75fda319e5fcd1be7259ee46c608a710) Given the following code: ```rust mod foo { pub enum Foo { Foo(i32), } } use foo::*; use Foo::*; ``` The compiler claims, that the `Foo` in `use Foo::*` could eithe | labels: A-resolve, T-compiler, C-bug


Minor 1.36 rustdoc regression:  \] after a link is not treated as an escape | A minor change in behavior between 1.35.0 and 1.36.0. Repro example here: ``` /// \[This escapes both brackets\] /// \[[This escapes only the left bracket as of 1.36.0](https://www.google.com/)\] pub fn example() { } ``` Run a standard `cargo doc`. In 1.36.0, the link will displa | labels: T-rustdoc, regression-from-stable-to-stable, C-bug


str::trim_start_matches and similar should not trust Searcher to return valid indices | For example, https://github.com/rust-lang/rust/blob/bc2e84ca0939b73fcf1768209044432f6a15c2e5/src/libcore/str/mod.rs#L3748, and the equivalent in trim_end_matches. The functions on Searcher that return these are not unsafe, and *someday* could be implemented outside the stdlib. Al


test cases under run-pass directory are not running | With the change in function should_run_successfully() of commit 54337fab39f4c610bd5e5c51cea6a965e7bd7cdb: - RunPass => true, - Ui => self.props.pass_mode == Some(PassMode::Run), + RunPass | Ui => self.effective_pass_mode() == Some(PassMode::Run), The test cases under run-pass dir | labels: A-testsuite, C-bug


Building core on thumbv6-none-eabi fails with "LLVM ERROR: invalid symbol redefinition" | In my project I'm using xargo to build libcore. Perhaps appropriately, the compiler warns it may crash and then promptly crashes: ``` warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> /home/gui/.rustup/toolchains/nightly-x86_64-unknown-li | labels: A-LLVM, A-codegen, T-compiler, C-bug, A-const-generics


Cross-crate re-export produces invalid rustdoc for impl Trait | In a cross-crate reexport of an `impl Trait`-accepting function, rustdoc formats it in a wrong way which is not even valid Rust. Let `crate1` be: ```rust pub trait MyTrait {} pub fn accepts_impl(_t: impl MyTrait) {} ``` Let `crate2` be: ```rust pub use crate1::{MyTrait, accepts_i | labels: T-rustdoc, A-impl-trait, C-bug


Tests related to debuginfo-both failing on sparc64 | During the past releases, a lot of bugs in the sparc64 backend have been fixed so that we're down to 59 failing tests now. One of the tests that have been failing for a long time now (don't know whether they ever passed) are ```debuginfo-both```: ``` test [debuginfo-both] debugin | labels: A-testsuite, A-debuginfo, O-SPARC, C-bug


Recent nightly versions break thumb* targets | Hey all, I've noticed in nightly-2019-07-18, rustc has begun producing symbols in the `.ARM.exidx` region, which it did not previously do. As our standard linker script does not have a linker rule for this region, building fails with with the following error: ``` = note: rust-lld | labels: A-LLVM, O-Arm, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


Undefined symbol _fltused when compiling to x86_64-unknown-uefi | Recent nightlies give the following linker error when trying to compile with the `x86_64-unknown-uefi` target: ``` error: linking with `rust-lld` failed: exit code: 1 | = note: "rust-lld" "-flavor" "link" "/NOLOGO" "/NXCOMPAT" "/nodefaultlib" "/entry:efi_main" "/subsystem:efi_app | labels: A-linkage, O-x86_64, P-high, T-compiler, regression-from-stable-to-beta, C-bug


Miri/CTFE fails when const generic is used as value | Miri/CTFE fails to execute code where a const generic parameter is used as a value, such as what `try_from` for arrays does these days: ```rust #![feature(const_generics)] fn len<'a, T, const N: usize>(_array: &'a [T; N]) -> usize { N } fn main() { const N: usize = 16; type Array | labels: C-bug, A-const-eval, A-miri, A-const-generics, requires-nightly, F-const_generics


Document that `Debug` output of structures is unstable | Pretty printed structures for `cfg!(windows)` have trailing commas, which is inconsistent with the debug output format documentation and output on non-windows platforms. ```rust use std::fmt; struct Foo { bar: u32, baz: Option<u32> } impl fmt::Debug for Foo { fn fmt(&self, fmt: & | labels: E-easy, C-enhancement, T-libs-api, A-docs


compile cdylib is ok,but staticlib can't link to __cxxframehandler3 | env : windows10 compile with cdylib is ok,just copy dll to windows path but with staticlib , can build success , but can't link to __cxxframehandler3 panic="abort" didn't useful nm xxx.lib U __CxxFrameHandler3 U __CxxFrameHandler3 U __CxxFrameHandler3 | labels: A-linkage, O-windows, T-compiler


Disable llvm orcjit | labels: A-LLVM, C-enhancement, T-compiler


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


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


Test `run-pass/generator/size-moved-locals.rs` fails on WASM | Due to a regression in `compiletest` some `run-pass` tests weren't run properly for some time and this is one of the regressions that slipped through during that time. https://github.com/rust-lang/rust/pull/62797#issuecomment-513279794 ``` 2019-07-19T15:47:51.8482480Z ---- [run-p | labels: T-compiler, O-wasm, C-bug, A-coroutines


LinuxTools builders fails to (mabye?) push at the end of PR builds | Discovered through https://github.com/rust-lang/rust/pull/62766 the end of a build failed with: ``` 2019-07-18T17:43:29.7626178Z Verifying status of book... 2019-07-18T17:43:29.7645772Z Verifying status of nomicon... 2019-07-18T17:43:29.7656763Z Verifying status of reference... 2 | labels: T-infra


Conflicting trait impls are allowed when not actually used | The following code [(playground)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=717aed92e64fd7e046d8167654b12b73): ```rust trait MyOtherTrait {} trait MyTrait {} struct MyStruct<T> { field: T } impl<T> MyTrait for MyStruct<T> where MyStruct<T>: MyOtherT | labels: A-trait-system, T-lang, C-bug


Test `run-pass/command-uid-gid.rs` fails on emscripten | Due to a regression in `compiletest` some `run-pass` tests weren't run properly for some time and this is one of the regressions that slipped through during that time. https://github.com/rust-lang/rust/pull/62797#issuecomment-513428569 ``` 2019-07-20T02:37:15.4921233Z ---- [run-p | labels: A-testsuite, C-bug


re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) | #62150 got reverted to give users some time to migrate; we should re-land it. **Original issue:** https://github.com/rust-lang/rust/pull/62150 has changed the behavior of `mem::uninitialized()` (and `zeroed()`), causing a few popular crates to be killed by `SIGILL`. A writeup can | labels: T-lang


Rustdoc link with module@ does not link to the module | Starting with an ambiguous lib.rs: ```rust pub mod x {} pub fn x() {} /// [x] pub struct S; ``` rustdoc correctly reports the ambiguity and suggests the possible resolutions: ```console warning: `x` is both a module and a function --> src/lib.rs:4:6 | 4 | /// [x] | ^ ambiguous li | labels: T-rustdoc, C-bug, A-intra-doc-links


assume all sequences have (unique) spans for now | Steps to reproduce: - Extract the archive [delegate_impl.tar[1].gz](https://github.com/rust-lang/rust/files/3413804/delegate_impl.tar.1.gz) - Run `cargo build` - Run `cargo test` The following generated macro is a likely source of error: ```rust pub trait Foo { fn len(&self) -> u | labels: I-ICE, A-macros, T-compiler, C-bug


Anchors in intra doc link | lib.rs: ```rust /// A! /// /// # Errors /// /// None? pub struct A; /// [x][A], [y][A#errors], [z] /// /// [z]: A#errors pub struct B; ``` The documentation of B is rendered by rustdoc as \` <a href="#">x</a>, \[y\]\[A#errors\], <a href="#">z</a> \`, in which the x link correctly | labels: T-rustdoc, C-bug, A-intra-doc-links


Allow generic parameters in intra doc link | ```rust pub struct Collection<T> { __: T } /// [`Collection`], [`Collection<T>`] pub struct S; ``` Currently this renders as \` <a href="#">Collection</a>, \[`Collection<T>`\] \`, where the first link is ok but the second link is not rendered. I think these should both point to s | labels: T-rustdoc, C-enhancement, E-mentor, E-medium, A-intra-doc-links


Add a way to get the number of bits in a representation | A few `core` APIs return values related to a number of bits. For example, the various [`leading_zeros` methods](https://doc.rust-lang.org/std/primitive.usize.html#method.leading_zeros), [`trailing_zeros` methods](https://doc.rust-lang.org/std/primitive.usize.html#method.trailing_ | labels: T-libs-api, C-feature-request


ICE on recursive struct | repro code: https://gist.github.com/sgrif/959bb5f820a0c9a616f569ea2195ff7c `Expression` on line 68 should be `Box<Expression>`, introducing the indirection fixes the ICE. I haven't attempted to reduce beyond this example. `rustc 1.36.0 (a53f9df32 2019-07-03)` | labels: I-ICE, P-medium, T-compiler, C-bug, E-needs-mcve


DWARF variant metadata for compressed enums with niche is ambiguous | After the change of DWARF metadata generation for enums (https://github.com/rust-lang/rust/pull/54004), compressed enums with niches are not distinguishable from tagged or empty enums in GDB pretty printing (not in the actual Rust pretty printers, as they do not support the new f | labels: A-debuginfo, T-compiler, C-bug, A-layout


ARMv6 architecture support broken in nightly-2019-07-18 | The support for ARMv6 architecture was broken somewhere between 07e0c3651...bc2e84ca0: `nightly-2019-07-16` compiles file while `nightly-2019-07-17` produces binary that crashes with `Illegal instruction`. More specifically, this is a binary cross-compiled from `x86_64-unknown-li | labels: I-crash, A-LLVM, O-Arm, regression-from-stable-to-nightly, P-high, T-compiler


Confusing error message when trying to use String as a Pattern | Consider this code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=1a04d9b9f18985990294c60baf35155e)): ```rust fn main() { let line = String::from("abc"); let pattern = String::from("bc"); println!("{:?}", line.find(pattern)); } ``` On both  | labels: A-diagnostics, T-compiler, C-bug


Test `run-pass\backtrace-debuginfo.rs` fails on i686-pc-windows-msvc | Due to a regression in `compiletest` some `run-pass` tests weren't run properly for some time and this is one of the regressions that slipped through during that time. https://github.com/rust-lang/rust/pull/62797#issuecomment-513516054 ``` ---- [run-pass] run-pass\backtrace-debug | labels: A-testsuite, A-debuginfo, T-compiler, O-windows-msvc, C-bug


tidy complains about valid stability attribute | With the following stability attribute ```rust #[unstable( feature = "internal_uninit_const", issue = "0", reason = "hack to work around promotability", )] ``` tidy complained ``` tidy error: /checkout/src/libcore/mem/maybe_uninit.rs:256: malformed stability attribute: missing `f | labels: A-testsuite, A-stability, C-bug


test attribute doesn't check if another test attribute is specified | Currently if you slap `#[test]` two times you're going to get double tests in `cargo test` output. I suspect it doesn't really care about presence of other attributes. And I only noticed it because `tokio::test` attribute that wraps async functions for tests also appends own `#[t | labels: A-libtest, C-bug, T-libs


Update Condvar docs to use match ergonomics | In `std::sync::Condvar`'s [docs](https://doc.rust-lang.org/std/sync/struct.Condvar.html), it looks like [line 39](https://github.com/rust-lang/rust/blob/0c7cf8c633b388d0d8cc4991d41a281d6ddd47bd/src/libstd/sync/condvar.rs#L39): ```rust let &(ref lock, ref cvar) = &*pair2; ``` and  | labels: E-easy, C-enhancement, T-libs-api, A-docs


compiler nontermination after "error: bare CR not allowed in doc-comment" | ``` $ rustc -vV rustc 1.38.0-nightly (273f42b59 2019-07-21) binary: rustc commit-hash: 273f42b5964c29dda2c5a349dd4655529767b07f commit-date: 2019-07-21 host: x86_64-unknown-linux-gnu release: 1.38.0-nightly LLVM version: 9.0 $ echo cyAgaS8vL2cNLyBydW4tcA0vLyBhIHNi | base64 --deco | labels: A-attributes, T-compiler, C-bug


Translate `\r\n` -> `\n` when reading files | Currently, we handle `\r\n` explicitly in the lexer. We should do this at the file read time instead. Motivation: 1. Line endings should not affect semantics of the language. For example, git on windows by default checkouts with `\r\n` line endings, and it would be bad if compili | labels: A-frontend, C-cleanup, T-compiler


Remove padding when code spans/code link spans are adjacent | I used ```markdown [`Stream`](futures::stream::Stream)`<Item = `[`io::Result`](std::io::Result)`<`[`Bytes`](bytes::Bytes)`>>` ``` in [some crates documentation](https://docs.rs/async-compression/0.1.0-alpha.1/async_compression/) which renders as ![concated-code](https://user-imag | labels: T-rustdoc, C-feature-request, A-rustdoc-ui


Alternatives to rustc_plugin::registry for (Servo’s) custom lints? | Continuing from https://github.com/rust-lang/rust/pull/62727#issuecomment-513508389: > > Servo’s memory safety unfortunately still depends on a custom lint that checks that GC pointers on the stack are properly rooted: https://github.com/servo/servo/tree/cef98d2e5179/components/s | labels: A-lints, A-plugins, T-lang, T-compiler, C-feature-request


Unexpected type for async closure? | ``` alexgaynor@penguin /t/x> rustc --version rustc 1.38.0-nightly (273f42b59 2019-07-21) ``` ```rust #![feature(async_await, async_closure)] use futures::stream::StreamExt; pub async fn f<Fut: std::future::Future<Output = ()> + std::marker::Unpin>(data: &mut [Fut]) { data.iter_mu


Const generics and transmute: cannot transmute between types of different sizes | The following code should compile, but it doesn't: ``` #![feature(const_generics)] use std::{ mem::{self, MaybeUninit}, ptr, }; fn main() { } pub struct Foo<const SIZE: usize> { messages: [Option<String>; SIZE], } impl<const SIZE: usize> Default for Foo<{SIZE}> { fn default() ->  | labels: T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


Missing x86/x86_64 intrinsic: `_mm_loadu_si32` | [intel guide](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=SSE2&text=_mm_loadu_si32) [rust docs show it as not there](https://doc.rust-lang.org/std/index.html?search=_mm_loadu_si32) | labels: O-x86_64, A-SIMD, O-x86_32


Const generics: Wrong number of const arguments | The following should type check but does not: ```rust #![feature(const_generics)] fn foo<const N: usize, const A: [u8; N]>() {} fn bar() { foo::<_, {[1]}>(); } ``` Errors with: ``` error[E0107]: wrong number of const arguments: expected 2, found 1 --> src/lib.rs:6:5 | 6 | foo::<_ | labels: T-compiler, C-bug, A-const-generics, A-lazy-normalization, requires-nightly, F-const_generics


ICE with const generics with dependent const parameters | ```rust #![feature(const_generics)] fn foo<const N: usize, const A: [u8; N]>() {} fn bar() { foo::<1, {[1]}>(); } ``` results in an ICE: ``` error: internal compiler error: src/librustc/ty/subst.rs:597: const parameter `N/#0` (Const { ty: usize, val: Param(N/#0) }/0) out of range | labels: I-ICE, T-compiler, C-bug, A-const-generics, A-lazy-normalization, requires-nightly


ICE on "index out of bounds: the len is 0 but the index is 1" | When I try to run `rustc` on this program (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)) ```rust fn f() -> isize { fn f() -> isize {} pub f< ``` it crashes with this error: ``` error: this file contains an un-closed delimiter --> main.rs:1:45 | 1 | fn f() -> isiz | labels: I-ICE, A-parser, T-compiler, regression-from-stable-to-stable, C-bug


Slow recompilation of rustc with incremental compilation | I'm probably doing something wrong. The docs say that with incremental compilation you should be able to recompile rustc in about 30 seconds. For me it takes around 10 minutes. I've done the following ([as described in the docs](https://rust-lang.github.io/rustc-guide/how-to-buil | labels: C-enhancement, I-compiletime, T-compiler, A-incr-comp


Link error if panic_handler is marked #[inline] | Test case: ```rust #![feature(core_intrinsics)] #![no_std] #![no_main] #[panic_handler] #[inline(always)] pub fn panic_imp(_: &core::panic::PanicInfo) -> ! { unsafe { core::intrinsics::abort(); } } #[no_mangle] pub extern fn main() -> i32 { panic!() } ``` Compiling with: ``` rust | labels: A-linkage, T-compiler, C-bug


"Aborted (core dumped)" with asm! after "error: expected expression, found `<eof>`" | rustc crashes ungracefully when given the following input (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)): ```rust asm!(f(assert_eq!(f/ ``` ``` $ rustc -vV rustc 1.38.0-nightly (273f42b59 2019-07-21) binary: rustc commit-hash: 273f42b5964c29dda2c5a349dd4655529767b | labels: E-easy, A-parser, E-needs-test, A-macros, T-compiler


ICE on "index out of bounds: the len is 3 but the index is 4" | I'm getting an internal compiler error on the following program (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)): ```rust // run-pass fn v() -> isize { mod _{ pub fn g() -> isizee { mod _{ pub g() -> is (), w20); } (), w20); } ``` ``` $ RUST_BACKTRACE=1 rustc main. | labels: I-ICE, P-high, T-compiler, regression-from-stable-to-stable, C-bug


Segfault compiling libc on armv7-unknown-linux-gnueabihf | Originally reported as rust-lang/libc#1441 but I was asked to report this here. # Steps to reproduce ```sh cargo new --bin compile-fail cd compile-fail rustup override set nightly echo 'libc = "=0.2.60"' >> Cargo.toml cargo check --release ``` Output: ``` Created binary (applicat | labels: I-crash, A-LLVM, O-Arm, P-high, T-compiler, regression-from-stable-to-stable


Explicit `Self: Sized` bounds missing from generated documentation. | Nearly every method of `Iterator` has an explicit `Self: Sized` bound. These bounds are **present in libcore**'s documentation (e.g., [`Iterator::count`](https://doc.rust-lang.org/1.36.0/core/iter/trait.Iterator.html#method.count)), but are **missing in libstd**'s documentation ( | labels: T-rustdoc, C-bug


ICE on "lexer accepted unterminated literal with trailing slash" | I'm getting an internal compiler on the following input (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)): ```rust "\u\\" ``` ``` error: incorrect unicode escape sequence --> main.rs:1:2 | 1 | "\u\\" | ^^^ incorrect unicode escape sequence | = help: format of unicod | labels: I-ICE, A-parser, T-compiler, C-bug


arbitrary_enum_discriminant: needs raw ptr -> usize cast + "a raw memory access tried to access part of a pointer value as raw bytes" | With: ```rust #![feature(arbitrary_enum_discriminant)] #[repr(u8)] enum Beta { V1 = 41, V2() = Self::V2 as u8 + 1, } ``` something seemingly strange is going on: ``` error[E0658]: casting pointers to integers in constants is unstable --> src/lib.rs:6:12 | 6 | V2() = Self::V2 as u | labels: T-compiler, A-const-eval


Remove TLS dependency from async/await | Futures currently have a dependency on TLS for storing a pointer to` Context<'_>`. https://github.com/rust-lang/rust/blob/master/src/libstd/future.rs#L116 This makes usage in `no_std` environments quite difficult. | labels: C-enhancement, T-libs-api, A-async-await, AsyncAwait-Triaged


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


Rework method disambiguation error to use structured suggestions | _Taken from https://github.com/rust-lang/rust/pull/62921#discussion_r306584349_ #62921 will extend the amount of times we display the disambiguated syntax in cases where multiple traits with the method being called is displayed in the following way: ``` error[E0034]: multiple app | labels: C-enhancement, A-diagnostics, T-compiler, A-suggestion-diagnostics, D-papercut


Tracking issue for map_first_last: first/last methods on BTreeSet and BTreeMap | <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, y | labels: I-slow, A-collections, T-libs-api, C-tracking-issue, disposition-merge, finished-final-comment-period


integer method `wrapping_abs` should be made const | The current `wrapping_abs` definition is ```rust pub fn wrapping_abs(self) -> Self { if self.is_negative() { self.wrapping_neg() } else { self } } ``` But for any integer type you can perform a branchless/const wrapping absolute with ```rust macro_rules! branchless_abs { ($x:expr | labels: C-enhancement, T-libs-api, A-const-eval


Documentation: remember the selected crate in search | Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc @GuillaumeGomez | labels: T-rustdoc, C-enhancement


Allocation::bytes should be private | The `bytes` field of an [`Allocation`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Allocation.html) is a very subtle one -- the values in there often do not mean what one might intuitively think. First of all the doc comment should probably be impro | labels: T-compiler


libcore fails to compile for thumbv6m-none-eabi | The libc crate cron job has started failing to build on master for the target `thumbv6m-none-eabi`. To reproduce: ``` cargo install xargo rustup target add thumbv6m-none-eabi git clone git@github.com:rust-lang/libc.git cd libc xargo +nightly build -vv --no-default-features --targ | labels: A-LLVM, O-Arm, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


changes to master should be gated on tier-1 compilers building libcore correctly for the targets they support | #62932 #62896 are regressions on tier-1 rustc `nightly-x86_64-unknown-linux-gnu` builds failing to build libcore for some of the targets that they are supposed to support cross-compiling to. Changes to master should be gated on not introducing regressions here. Testing this is ea | labels: A-testsuite, C-enhancement, T-infra


`mismatched types` error in Listing 2-4  of the book | #### Env: rustc 1.36.0 (a53f9df32 2019-07-03) Windows 10 64 bits #### Problem: In the Listing 2-4 of https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html#comparing-the-guess-to-the-secret-number . It seems the guess is a `String` and secret_number is a `i32`, the co


Documentation: Add a link to the keywords list | As per [this request](https://github.com/rust-lang/rust/issues/34601#issuecomment-514586053): Add the following link (`/std/index.html#keywords`) next to the existing ones: **See all std's items** Re-exports Primitive Types Modules Macros [Keywords](https://doc.rust-lang.org/nigh | labels: E-easy, C-enhancement, A-docs


cargo doc --all does not document proc macro crates if target is explicitly specified | If a target is explicitly specified on the command line, even if it is the same target as the host, then proc macro crates will not be documented by `cargo doc --all`. When a cargo configuration file is used to set a default target for cross-compliation, this can prevent document | labels: T-rustdoc, A-macros, A-cross, C-bug


rust-gdb doesn't set up path substitutions? | I'm trying to use `rust-gdb` on project generated by `cargo new` and looks like the `rust-src` source code path is not configured: ``` Reading symbols from target/debug/hello... (gdb) show directories Source directories searched: ~/.rustup/toolchains/nightly-x86_64-unknown-linux- | labels: A-debuginfo, P-low, E-mentor, T-compiler, E-medium


Confusing Debug of chars | Currently, the Debug of `Chars` prints the underlying bytes, rather than the chars: [Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7b09ceeb511d2859dbf492b5f4c046f4) ```rust #![allow(unused)] fn main() { let s = String::from(" é 😀 "); let | labels: C-enhancement, T-libs-api, A-iterators


Ungreat diagnostic error borrowed data escapes outside of function | On an change I was implementing in the compiler I got the following error ... ``` error[E0521]: borrowed data escapes outside of function --> src/librustc_codegen_ssa/mir/analyze.rs:228:9 | 218 | fn visit_place(&mut self, | --------- `self` is declared here, outside of the functi | labels: C-enhancement, A-diagnostics, A-borrow-checker, T-compiler


Initializing struct fields with `MaybeUninit` | The `MaybeUninit` docs have one weird, concerning section: > [There is currently no supported way to create a raw pointer or reference to a field of a struct inside `MaybeUninit<Struct>`. That means it is not possible to create a struct by calling `MaybeUninit::uninit::<Struct>() | labels: T-lang, C-feature-request, F-raw_ref_op


Spurious failures when downloading awscli from PyPI | We recently started seeing multiple network failures while downloading awscli from PyPI: * https://github.com/rust-lang/rust/pull/62960: [log 1](https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_apis/build/builds/4208/logs/707), [log 2](https://dev.azure.com/r | labels: A-spurious, T-infra, C-bug


Rustdoc doesn't explain (or can't) linking to slice methods | Rustdoc documentation tells you link to an item with `[text](rust::path::to::item)`. You can even use paths appropriate to the current context to name an item, and so because `i32` and other primitives are always in scope you can point a link at `i32::abs` or whatever. However, y | labels: T-rustdoc, C-bug, A-intra-doc-links


No way to extract flags arguments from unix::OpenOptionsExt | At the moment, if I want to write an interface that uses `OpenOptions`, but doesn't use the `OpenOptions::open` interface it's simply not possible to implement. The short reason why this is needed is because I am [writing a library](https://github.com/openSUSE/libpathrs) that use | labels: T-libs-api, C-feature-request


ICE on "byte index 1 is out of bounds of ``" | I'm seeing an internal compiler error on the following input (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)): ```rust fn p() { match s { v, E { [) {) } ``` (EDIT: the trailing newlines are important) ``` error: this file contains an un-closed delimiter --> main.rs | labels: I-ICE, A-parser


Make references to GitHub issues in diagnostics consistent | Some diagnostics include a link to GitHub issues. From the ui testsuite, I found at least these two patterns: ``` = note: for more information, see https://github.com/rust-lang/rust/issues/51999 ``` ``` = note: for more information, see issue #36887 <https://github.com/rust-lang/ | labels: E-easy, C-enhancement, A-diagnostics, T-compiler


Existential types have issues with lifetimes | ```rust #![feature(existential_type)] trait MyTrait { type AssocType: Send; fn ret(&self) -> Self::AssocType; } impl MyTrait for () { existential type AssocType: Send; fn ret(&self) -> Self::AssocType { () } } impl<'a> MyTrait for &'a () { existential type AssocType: Send; fn ret | labels: T-compiler, A-impl-trait, C-bug, F-type_alias_impl_trait, requires-nightly


Boolean optimization no longer works | I'm unsure if this is a bug or not. The following code used to perform just as well as if there were no `let` statements. However, sometime since last year, that has changed. ```rust pub fn is_leap_year1(year: i32) -> bool { let div_4 = year % 4 == 0; let div_100 = year % 100 ==  | labels: A-LLVM, I-slow, T-compiler, regression-from-stable-to-stable, C-bug


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


rustc should "ellipsis" very long lines when printing warnings | STR on macOS: - Clone https://github.com/RustAudio/coreaudio-sys - Checkout commit 13a32d718647b9e5be1defdef8197958cfda31fa - Edit Cargo.toml to update the bindgen dependency from 0.42 to 0.49. - `cargo build` - Admire the 200MB of warnings scrolling in your terminal for ~800 act | labels: A-diagnostics, T-compiler


Lifetime elision rules in `self` types | This issue tracking lifetime elision rules in `self` types. Here are test cases of elision rules introduced in #61207: https://github.com/rust-lang/rust/blob/d79d13f9e6ca05f2002446addfbd68e63e419cc1/src/test/ui/self/elision/README.md This rule has already been applied in Rust 1.3 | labels: A-lifetimes, I-needs-decision, T-lang, A-inference, C-tracking-issue


rustdoc: Searching for path (including a `::`) does not work | Say I want to find the docs for `Vec::new`, so I search for that. What I get is [this](https://doc.rust-lang.org/nightly/std/?search=Vec%3A%3Anew): almost all of these results are entirely irrelevant. rustdoc search should understand enough about Rust syntax to handle `::` approp | labels: T-rustdoc, C-bug


rustdoc silently fails parsing some doctests when using a playground URL | For example running `rustdoc --markdown-playground-url=https://play.rust-lang.org/ foo.md` on: ``````markdown # test ``` # #![feature(async_await)] use std::future::Future; use std::pin::Pin; fn foo_recursive(n: usize) -> Pin<Box<dyn Future<Output = ()>>> { Box::pin(async move {  | labels: T-rustdoc, I-ICE, C-bug


Missing documentation folder in armv7-unknown-linux-gnueabihf installer (both standalone and using rustup) | Tried in Linux raspberrypi 4.4.9-v7 Friday, May 6 2016, armv7l GNU/Linux. All the steps described below were executed in 23th or July, 2019. While following the installation guide (ref001, at the bottom of this report), and once Rust is sucessfully installed in the system (stable | labels: O-Arm, A-docs, T-infra


rustc_args_required_const on parameter not treated as constant in argument | This implementation of wasm32's v8x16.shuffle intrinsic does not build (add to stdarch/crates/core_arch/src/wasm32/simd128.rs): ``` #[inline] #[cfg(not(only_node_compatible_functions))] #[cfg_attr(test, assert_instr("v8x16.shuffle"))] #[rustc_args_required_const(2)] pub fn v8x16_ | labels: T-compiler, A-SIMD, C-bug, A-const-eval


Strange Arc::ptr_eq behaviour (duplicate vtables?) | Hello. This issue is simmilar to https://github.com/rust-lang/rust/issues/48795 and https://github.com/rust-lang/rust/issues/46139 but have more strange behaviour and suggestion. The problem is located when we clone `Arc` to `Arc<Trait>` in one function, return `Arc` and then clo | labels: C-enhancement, T-lang


On i686 release builds, Valgrind reports depending on uninitialized values | For the following *main.rs* ```rust fn main() { let x = &[0i32]; let _ = (x.iter().map(|_| 1i32)) .chain(x.iter().map(|_| 1i32)) .chain(x.iter().map(|_| 1i32)) .chain(x.iter().map(|_| 1i32)) .chain(x.iter().map(|_| 1i32)) .collect::<Vec<i32>>(); } ``` On i686 GNU/Linux, for a rel | labels: O-x86_32


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


ICE: local variable without a name | The following code causes an internal compiler error on 1.37.0-beta.6 and 1.38.0-nightly. On stable it's a simple error, though the message could be improved (#63027). ```rust use std::collections::HashMap; use std::hash::Hash; fn group_by<I, F, T>(xs: &mut I, f: F) -> HashMap<T, | labels: I-ICE, T-compiler, regression-from-stable-to-beta, A-NLL, C-bug


Error message referring to non-existent variable: "cannot return value referencing local variable `__next`" | Compiling the following code on stable result in an error message which is referring to a non-existent variable `__next` ```rust use std::collections::HashMap; use std::hash::Hash; fn group_by<I, F, T>(xs: &mut I, f: F) -> HashMap<T, Vec<&I::Item>> where I: Iterator, F: Fn(&I::It | labels: A-diagnostics, T-compiler, C-bug


ICE typechecking closure object with bound lifetime | I don't think this was previously submitted as an issue, though it was mentioned on the [Rust Internals forum](https://users.rust-lang.org/t/generic-closure-arguments-and-hrtbs/13185/5). ```rust trait Lf<'a> { type Type; } struct F32; impl<'a> Lf<'a> for F32 { type Type = f32; }  | labels: A-codegen, I-ICE, P-medium, A-closures, T-compiler, C-bug


Lifetime is unnecessarily captured in nested functions returning impl trait via async | When trying to create some futures that do a bit of work up-front to avoid borrowing some inputs, I ran into this strange issue where it seems like an input lifetime is being unnecessarily captured by the returned impl trait even though the value isn't: ```rust #![feature(async_a | labels: T-compiler, A-impl-trait, A-async-await, AsyncAwait-Triaged


Async fn does not compile if lifetime does not appear in bounds (sometimes) | ```rust #![feature(async_await)] use std::marker::PhantomData; trait Trait {} async fn f<'a>(reference: &(), marker: PhantomData<dyn Trait>) {} ``` This fails with: ```console error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds --> src/main | labels: A-lifetimes, T-compiler, C-bug, A-async-await, AsyncAwait-Triaged


rustdoc shows anonymous elided lifetimes in async fn signature | When run on an `async fn` with elided lifetimes, `rustdoc` generates documentation containing the anonymous elided lifetimes in the function's signature. Running `rustdoc` on the blocking variant of the same function produces a correct signature. You can reproduce this issue by g | labels: T-rustdoc, A-lifetimes, C-bug


Builtin macro pattern separator | Since #62243 builtin macros use `,` as a separator between different patterns. Although, all other macros use `;` instead. Is it intended change? This change breaks parser in IntelliJ Rust plugin. Should we adjust our parser or it should be fixed from stdlib side?


Invalid suggestion when returning struct with lifetime param missing | ```rust struct Context<'a> { a: &'a (), } fn context() -> Context { loop {} } ``` ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8e98596fa4a1d144fa7c8061697cbcb1)) Errors: ``` Compiling playground v0.0.1 (/playground) error[E0106]: missing l | labels: A-diagnostics, T-compiler, C-bug, A-suggestion-diagnostics, D-invalid-suggestion


[docs] auto impl trait should be sorted | That'd make tests more accurate. | labels: T-rustdoc, C-enhancement


"Variable is assigned to, but never used" with += operator | Tested on both rust 1.36 and 1.38 (nightly): $ rustc -V rustc 1.36.0 (a53f9df32 2019-07-03) $ rustc +nightly -V rustc 1.38.0-nightly (c43753f91 2019-07-26) The following code: ``` $ cat src/main.rs fn main() { let mut error = 0; for i in 0..3 { error += i; } } ``` Produces the fo


-Zprofile and -Clink-dead-code enabled leads to the linking error on macOS | I'm integrating [grcov](https://github.com/mozilla/grcov) and have macOS build failures with a linkage error while both `-Zprofile` and `-Clink-dead-code` flags enabled. Consider a cargo project with the following manifest: ```toml [package] name = "foo" version = "0.1.0" authors | labels: A-linkage, O-macos, C-bug, A-code-coverage


Simple software design pattern not possible | ``` struct Item { name: String } struct Human { items: Vec<Item>, name: String } impl Human { fn rename(&self, i: &mut Item) { i.name = self.name.clone(); } fn work(&mut self) { for i in &mut self.items { self.rename(i); } } } fn main() { let mut human = Human{items: Vec::new(),


ANSI mode text breakage on Windows PowerShell | 1.) In the "Type here to search" box search "Registry Editor" and open the Registry Editor app (If it asks if you want to allow the app to make changes to your device choose "Yes"). 2.) Click the drop down arrow for "HKEY_CURRENT_USER" and select the folder named "Console". 3.) I


dead_code lint highlights too much on functions with multi-line signatures | With the following example code: ```rust fn unused() { println!("blah"); } fn unused2(var: i32) { println!("foo {}", var); } fn unused3( var: i32, ) { println!("bar {}", var); } fn main() { println!("Hello world!"); } ``` ([Playground](https://play.rust-lang.org/?version=nightly& | labels: A-lints, A-diagnostics, T-compiler, C-bug


E0277 should put emphasis on containing function's return type | I got the following error today: ``` error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `std::ops::Try`) --> src/main.rs:29:20 | 29 | let mut resp = reqwest::get("...")?; | ^^^^^^^^^^^^^^^^^^^^ cannot u | labels: E-easy, C-enhancement, A-diagnostics, T-compiler, F-on_unimplemented


Confusing error message when matching on an unnecessarily-unwrapped value | Consider this code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c083e7005433f0e7b29d10d8f2fe4725)): ```rust pub fn test(input: &str) -> Result<serde_json::Value, String> { match serde_json::from_str(input).unwrap() { Ok(v) => Ok(v), Err(w | labels: C-enhancement, A-diagnostics, T-compiler


Reevaluate Miri engine alignment checks | Two PRs will likely land soon that change the way the Miri engine does alignment checks: https://github.com/rust-lang/rust/pull/63079 and https://github.com/rust-lang/rust/pull/63075. The former entirely disables alignment checks for CTFE (when the Miri engine is used as part of  | labels: T-compiler, A-const-eval, A-miri


Invalid span when emitting a diagnostic note on the top-level module | While I was investigating a fix for #63064, I noticed one problematic error case, where, as it turns out, the compiler emits a broken span. ```rust fn main() {} trait Foo<X = Box<dyn Foo>> {} ``` This is the error I'm getting with the nightly: ``` error[E0391]: cycle detected whe | labels: A-diagnostics, T-compiler, C-bug


`type S = Option<Box<S>>;` should compile | It seems a compiler bug to me. I tried this code: ```rust type S = Option<Box<S>>; ``` I expected it could compile, but instead: ```bash lihz:linkedlist lihzhang$ cargo build Compiling linkedlist v0.1.0 (/Users/lihzhang/Documents/com.github/linkedlist) error[E0391]: cycle detecte | labels: C-enhancement, A-diagnostics, T-compiler, A-suggestion-diagnostics


`f64::round` produces Illegal Instruction on `arm-unknown-linux-gnueabihf` | I am cross-compiling for a Raspberry Pi Zero W (`arm-unknown-linux-gnueabihf`), and I am experiencing a strange issue when using `f64::round`, which leads to an “Illegal Instruction”. Here are some minimal examples: 1. Illegal Instruction at line 4 ```rust fn main() { let v: f64


"Try invoking the function" hint | Hi, Let's consider following code: ```rust fn foo() -> usize { 0 } fn bar(i: usize) { } fn main() { bar(foo); } ``` Right now it fails with the `expected usize, found fn item` message - I think it would be helpful if compiler bragged about missing parentheses when function's retu | labels: A-diagnostics, T-compiler, A-async-await, A-suggestion-diagnostics, AsyncAwait-Triaged


Support armv7-unknown-linux-gnueabi and armv7-unknown-linux-musleabi (soft-float variants) | Currently for armv7 only the hardfloat variants (`armv7-unknown-linux-gnueabihf` and `armv7-unknown-linux-musleabihf`) are supported. I'll try to open a pull request as this seems to be a small change. | labels: O-linux, O-Arm, T-compiler, C-feature-request


decl macro 2.0 doesn't allow trailing comma | ```rust macro abc { () => {}, ``` ([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6986bf981691d75da249f136a16e2e07)) Errors: ``` Compiling playground v0.0.1 (/playground) error: unexpected end of macro invocation --> src/lib.rs:2:14 | 2 | () | labels: A-parser, T-compiler, A-decl-macros-2-0, C-bug


Should PartialOrd provide impl for Ord to avoid boilerplate? | Currently `std` gives the following example in "[How can I implement `Ord`?](https://doc.rust-lang.org/std/cmp/trait.Ord.html#how-can-i-implement-ord)": ```rust use std::cmp::Ordering; #[derive(Eq)] struct Person { id: u32, name: String, height: u32, } impl Ord for Person { fn cm | labels: T-libs-api, C-feature-request


Redundant E0106 missing lifetime error and rust_2018_idioms missing lifetime lint | While hacking in the compiler I got the following error: ``` error: hidden lifetime parameters in types are deprecated --> src/libsyntax_ext/format.rs:113:43 | 113 | arg_with_formatting_spans: Vec<(Span, parse::FormatSpec)>, | ^^^^^^^^^^^^^^^^^- help: indicate the anonymous lifet | labels: C-enhancement, A-lints, A-diagnostics, T-compiler, A-suggestion-diagnostics, L-elided_lifetimes_in_paths


Improve recovery diagnostic for `for ( $pat in $expr ) $block` | Roughly according to https://github.com/rust-lang/rust/pull/62928#discussion_r308365465. cc @estebank | labels: C-enhancement, A-diagnostics, T-compiler, A-suggestion-diagnostics, D-papercut


"`X...` range patterns are not supported" occurring in today's nightly | The CI for `libssh2-sys` started to fail today with this error: ``` error: `X...` range patterns are not supported --> C:\Users\wez\.cargo\registry\src\github.com-1ecc6299db9ec823\extprim-1.7.0\src\traits.rs:94:21 | 94 | 1 ... $e => u128::new(mantissa) << exp, | ^^^^^ help: try u | labels: A-parser, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


ICE on "internal error: entered unreachable code" | I'm seeing an internal compiler error on the following input (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)): ```rust impl W <s(f;Y(;] ``` ``` error: this file contains an un-closed delimiter --> main.rs:1:18 | 1 | impl W <s(f;Y(;] | - ^ | | | un-closed delimiter  | labels: I-ICE, A-parser, E-needs-test, T-compiler, C-bug, glacier


Re-exporting `extern "C"` and `#[no_mangle] symbols in cdylib doesn’t work with gcc on Linux | Building a `cdylib` crate that has a dependency on a crate with `extern "C"` and `#[no_mangle]` symbols fails to export the symbols on Linux, even when the symbols are re-exported as public. Symbols are correctly exported on Mac and Windows. The problem was somewhat discussed on  | labels: A-linkage, A-FFI, T-compiler, C-bug


Add the markdown preview for the output of `rustc --explain E...` | Currently it outputs the raw markdown, but it makes sense to provide an embedded preview. Luckily, there is an amazing Rust library for that - [termimad](https://github.com/Canop/termimad). And it is scrollable out of the box. ![image](https://user-images.githubusercontent.com/20 | labels: T-compiler, C-feature-request


Compute all argument-less const fns via `eval_const` to cache their evaluation | cc https://github.com/rust-lang/rust/pull/61626#issuecomment-514719862 We are already doing that for nullary intrinsics (#61626), it seems like we could get some perf gains from this, even cross crate. | labels: C-enhancement, I-compiletime, T-compiler, A-const-eval


Improve UX with std::thread::Builder::name() by accepting Into<String> | We could improve the [`std::thread::Builder::name()`](https://doc.rust-lang.org/std/thread/struct.Builder.html#method.name) method by accepting not only a `<String>`, but anything that could be converted to a string: ```rust pub fn name<S: Into<String>>(self, name: S) -> Builder; | labels: T-libs-api, C-feature-request


RGB_GAMA | #C0C0C0_ C+M+Y author_email="ritiekmalhotra123@gmail.com


ICE on "Error constructed but not emitted" | I'm seeing an internal compiler error on the following input (found by [fuzz-rustc](https://github.com/dwrensha/fuzz-rustc)): ```rust fn i(n{...,f # ``` ``` error: this file contains an un-closed delimiter --> main.rs:2:2 | 1 | fn i(n{...,f # | - - un-closed delimiter | | | un-cl | labels: I-ICE, A-parser, T-compiler, C-bug


"match arms have incompatible types" hint incorrect | > this and all prior arms are found to be of type `!` Only some of the prior arms are of type `!`, the rest is of type `FloatCC`. ``` error[E0308]: match arms have incompatible types --> src/llvm_intrinsics.rs:77:33 | 60 | / match scalar.assert_bits(Size::from_bytes(1)) { 61 | |  | labels: A-diagnostics, T-compiler, C-bug


Rustdoc search results truncated | https://docs.rs/cranelift-codegen/0.37.0/cranelift_codegen/ir/trait.InstBuilder.html?search=I32X ![image](https://user-images.githubusercontent.com/17426603/62130746-f768d200-b2d9-11e9-89d9-b9201ff5dda2.png) Reason: `max-height: calc(100vh - 32px);` on parent `<div class="rustdoc | labels: T-rustdoc, C-bug


Tracking issue for div_duration | Rust PR: #62756 This feature adds the following methods to `Duration`: - `div_duration_f64(self, rhs: Duration) -> f64` - `div_duration_f32(self, rhs: Duration) -> f32` | labels: T-libs-api, B-unstable, C-tracking-issue, requires-nightly, Libs-Tracked, Libs-Small


Generic type parameters used in expression? | Is there a way to use a generic type parameter in an expression? For example: ~~~rust fn SomeGenericFunc<T>() { if T : Display { // Here we know T implements Display println!("{}", T); } else if T : Debug { // Here we know T implements Debug println!("{:?}", T); } else { println!


Using proc macros through a re-exported crate raises rustc_private unstability error | When a library A depends on a library B, which re-exports a library C that (re-?)exports procedural macros, using them in A through the re-export in B may result in an E0658 error. I tried this code: ```rust // src/lib.rs use inner::serde::Deserialize; #[derive(Deserialize)] pub  | labels: C-enhancement, A-diagnostics, A-resolve, A-macros, T-compiler


Box "doesn't have a size known at compile-time" wrong diagnostic | If I do ... ```rust fn main() { let x = "hello"; let y = Box::new(*x); } ``` I get the following error ... ``` --> src/main.rs:3:13 | 3 | let y = Box::new(*x); | ^^^^^^^^ doesn't have a size known at compile-time | = help: the trait `std::marker::Sized` is not implemented for `st | labels: A-diagnostics, T-compiler, C-bug


Fix to #62194 broke the coherence tests and made error messages more mysterious | PR #62696 had *removed* the notes from the tests for the upstream/downstream printing logic, so now that logic is not tested: https://github.com/rust-lang/rust/commit/2ced474e808d59e4b3bf2c6874e40446a4598f51 Plus, the new error messages are worse: an upstream impl can indeed be a | labels: A-diagnostics, A-trait-system, T-compiler, C-bug


incremental compilation DepNode Bug running cargo check | # cargo check panic # code that produced the panic ```rust type Data = Vec<u8>; #[derive(Debug)] enum EventImpl{ NoteOn(u8), NoteOff(u8) } #[derive(Debug)] struct Event{ data:Data, i:EventImpl } impl Event{ fn new(data:Data)->Self{ Event{ i: match data[0]{ 0 => EventImpl::NoteOn( | labels: I-ICE, P-high, T-compiler, A-incr-comp, C-bug, E-needs-mcve


Spurious unused field warning when matching variants under a `Self` scope | This code should compile without warnings: ```rust enum Enum { Variant { field: usize } } impl Enum { fn read_field(self) -> usize { match self { // Enum::Variant { field } => field Self::Variant { field } => field } } } fn main() { let e = Enum::Variant { field: 42 }; println!(" | labels: A-lints, T-compiler, C-bug


Associated types, impl traits ~and closures~; oh my, an ICE. | While experimenting with some code I hit this ICE. Interestingly, when running `cargo test` a second time, it magically works - skipping the error. Also, `cargo miri test` works fine too. I'm on a slightly older nightly because some rustup components are missing on the latest. ht | labels: I-ICE, A-closures, A-associated-items, P-high, T-compiler, A-MIR


lint of unnecessary parentheses around `if` condition may case error | when unnecessary parentheses is removed, may lack a whitespace between `if` and `expr`. example `if(is_prime) {println!("hello")};` while be replaced to `ifis_prime {println!("hello")};` Maybe we should replare `(expr)` with a pair of whitespace around `expr`, instead of just `ex | labels: E-easy, A-lints, T-compiler, C-bug


Drop ordering breaks macro hygiene | Macro hygiene implies any objects created in the macro should be dropped before any code run after it executes. This does not happen in latest stable or nightly. I tried this code: ```rust use std::io::Write; macro_rules! out { ($content:expr $(, $vars:expr)*) => { let stdout = s | labels: A-destructors, A-macros, T-lang


Do copy[_nonoverlapping]/swap[_nonoverlapping] do typed copies? | The following example ([godbolt](https://rust.godbolt.org/z/SDb-pj)): ```rust #[repr(align(128))] #[derive(Copy, Clone)] pub struct A(u8); pub unsafe fn foo(x: &A) -> A { *x } pub unsafe fn bar(x: &A) -> A { let mut y: A = std::mem::uninitialized(); std::ptr::copy_nonoverlapping( | labels: A-LLVM, I-slow, C-enhancement, T-compiler


Redox builder is temporarily disabled | #61393 temporarily disables the redox builder, this issue tracks re-enabling it. cc @jackpot51 | labels: T-infra, O-redox


ICE: index out of bounds: the len is 7 but the index is 7 | I encountered an ICE today. Below you find the backtrace of running `cargo test`. I ran `cargo clean` afterwards and the ICE vanished, so it seams to be connected to incremental compilation. ``` thread 'rustc' panicked at 'index out of bounds: the len is 7 but the index is 7', /r | labels: I-ICE, T-compiler, A-incr-comp, C-bug, E-needs-mcve


internal error: entered unreachable code | Seems to be something to do with Rocket. Having a `get` on the internal function is causing the compiler to blow up. ```rust fn moo() { #[get("/moo")] fn get() -> String { "moo".to_string() } } ``` Version: ``` rustc 1.38.0-nightly (dddb7fca0 2019-07-30) binary: rustc commit-hash | labels: I-ICE, A-visibility, A-macros, P-high, T-compiler, A-decl-macros-2-0


Confusing error message with type unification of impl Traits | It took a colleague explaining to me that the return type of a function returning an impl Trait is unique across function definitions for me to understand the following error: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4ceda076c82b01ea279e8864518ab5d9 | labels: C-enhancement, A-diagnostics, T-compiler, A-impl-trait, A-async-await, AsyncAwait-Triaged


Tracking issue for Result::cloned, Result::cloned_err, Result::copied, Result::copied_err | [PR](https://github.com/rust-lang/rust/pull/63166) | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, requires-nightly


impl trait in type aliases does not trigger "private type in public interface" errors | The current implementation of `existential_type` does not trigger any "private type in public interface" errors, for the following code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f8b7bf41e44a8f7ec207f35eaf879f16)): ```rust #![feature(ex | labels: A-resolve, A-visibility, I-needs-decision, T-lang, T-compiler, A-impl-trait


TcpListener does not listen any requests | I wrote this code for build a simple TCP server: ```rust use std::io::prelude::*; use std::net::{TcpListener, TcpStream}; fn main() { let server = TcpListener::bind("127.0.0.1:5600").unwrap(); println!("Server is working."); for stream in server.incoming() { let stream = stream.u


fs::read_dir() and ReadDir need clear warnings about not relying on iteration order | The docs for `fs::read_dir()` and `fs::ReadDir` need to clearly state that iteration order is implementation defined and may vary not just between OS's but between identical versions of a directory on different filesystems. Currently the warning on `fs::read_dir()` is uselessly v | labels: E-easy, C-enhancement, E-mentor, A-docs


Toolstate for Linux not correctly published | The toolstate for Linux at https://rust-lang-nursery.github.io/rust-toolstate/ claims that tools are still failing. E.g., https://github.com/rust-lang/rust/pull/63141 landed, but only the Windows toolstate was considered fixed after that. Looks like something is breaking publishi | labels: T-infra, C-bug


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


Investigate whether `Ty` and `OpaqueTy` can be merged | A similar sentiment is probably valid in other contexts, but the original motivation for this is https://github.com/rust-lang/rust/pull/63180#discussion_r309927011. | labels: C-cleanup, T-compiler, A-impl-trait, F-type_alias_impl_trait, requires-nightly


document some diagnostics for min TAIT in stabilization report | This issue was repurposed. It now refers to documenting the diagnostics for various errors and other cases in the [`min_type_alias_impl_trait` stabilization report](https://hackmd.io/o9KO-D8aSb6bJgQ1froVTA). -- @nikomatsakis ~~After https://github.com/rust-lang/rust/issues/63063  | labels: C-enhancement, A-diagnostics, T-compiler, A-impl-trait, F-type_alias_impl_trait, requires-nightly


Formal parameter attributes won't be passed into proc-macro | As this [example repo](https://github.com/Hexilee/params-attribute-example/blob/master/proc-macro-tests/rename_params.rs) This is the example proc-macro: ```rust extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn rename_params(_args: TokenStream, | labels: A-attributes, A-macros, T-compiler, C-bug, requires-nightly, F-param_attrs


Associated types cause "expected" and "found" to be reversed in error messages | TL;DR: `Iterator<Item=...>` type mismatches are described wrong. In some cases -- I've reproduced consistently with associated types, but haven't explored further -- type mismatches are reported incorrectly, with the expected type being reported as "found" and the actual type bei | labels: A-type-system, A-diagnostics, T-compiler


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


Move closure copies :Copy variables silently | ## The Good Given the following code: ```rust fn main() { let mut x = 0; dbg!(x); } ``` https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=19261742184207a4075885cae58680e1 I got a reasonable warning: ``` warning: variable does not need to be mutable --> src/m | labels: C-enhancement, A-lints, A-closures, T-lang


[rustdoc] stabilize #[doc(alias = ...)] | cc @rust-lang/rustdoc | labels: T-rustdoc, A-doc-alias


Compiler panic on a macro invocation combined with invalid pub declaration | The compiler panics when compiling the following code. I had been expecting to see syntax errors instead. Deleting either line causes the compiler not to panic and give expected error messages. ```rust const FOO: &str = b!("foo"); pub struct Bar { pub(in ::a) x: u64 } ``` ([Playg | labels: A-resolve, I-ICE, A-macros, T-compiler, C-bug


How to parse rmeta file | Hello, I'm currently working on the compiler process of rust and I want to know some details about the metadata included in the rlib file. I have extracted the rmeta file from the rlib file, however, I found out it is also a binary file. I wonder if there are any approaches or to | labels: A-metadata, T-compiler, E-help-wanted


Error with nested async fn and anonymous lifetimes | The following breaks on nightly (see [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a1aabca3f0059c24f101e3a149632fbd)) ```rust #![feature(async_await)] struct Foo<'a>(&'a ()); impl Foo<'_> { fn test() { async fn test() {} } } ``` With: ``` e | labels: T-compiler, C-bug, A-async-await, AsyncAwait-Polish


ICE when constructing monomorphic vtable in a static in dependent crate. | This is ICE happens when I call `ROnce::new` from the abi_stable crate in const contexts in dependent crates/doctests, but not when using the `ROnce::NEW` associated constant. # Reproducing It can be reproduced using a doctest in the playground: https://play.rust-lang.org/?versio | labels: E-easy, A-codegen, I-ICE, E-mentor, P-high, T-compiler


Adding stuff to a particular existing crate? | Well simply put - monkey patching code. Oh boy, I can feel the raised eyebrows already. I am working on an embedded project. Worked on Cortex-M3 until now (thumbv7v-m), and recently switched to Cortex-M (thumbv6-m), and all hell broke lose. The main issue is that the instruction


Fix test style in unused parentheses lint test | Update test file to use `#![deny(unused_parens)]` + `//~ ERROR` annotations instead of `pretty-json` (see https://rust-lang.github.io/rustc-guide/tests/adding.html) The files need to update are: - `test/lint/unused_parens_json_suggestions.rs` - `test/lint/used_parens_remove_json_ | labels: E-easy, C-cleanup, A-testsuite, A-lints, E-mentor, T-compiler


deps.rs EXCEPTIONS needs to be re-triaged | The [EXCEPTIONS](https://github.com/rust-lang/rust/blob/d7270712cb446aad0817040bbca73a8d024f67b0/src/tools/tidy/src/deps.rs#L27) list lists license exceptions. After reviewing a few of them, they seem to be out of date, and some that were copyleft are now permissive, and some hav | labels: T-core


Nested tuple leads to worse code | For ```rust pub struct Moo((u128, ())); pub fn moo(a: Moo, b: Moo) -> Moo { Moo(((a.0).0 + (b.0).0, ())) } pub struct Baa(u128, ()); pub fn baa(a: Baa, b: Baa) -> Baa { Baa(a.0 + b.0, ()) } ``` `cargo asm` gives ```asm try::moo: mov rcx, qword, ptr, [rdx] add rcx, qword, ptr, [rs | labels: I-slow, A-codegen, T-compiler


rustc claims that "array lengths can't depend on generic parameters" for exactly one type of expression, while various other far more complex expressions involving const generics work perfectly | Quite simply: The fact that [this playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c567834235a3f1354b9a96fdbedfad35) gives an error (which is literally the only syntactic way I'm aware of to get that error), while on the other hand I was a | labels: T-compiler, A-const-generics, A-lazy-normalization


"can't qualify macro invocation with `pub`" error can fire without any macro invocations | With #63180 in effect, code using `existential type` produces confusing error: ``` error: can't qualify macro invocation with `pub` --> src/mixer.rs:6:1 | 6 | pub existential type T: MotorCtrl; | ^^^ | = help: try adjusting the macro to put `pub` inside the invocation ``` The act | labels: A-diagnostics, A-parser, T-compiler, C-bug, D-incorrect


Segmentation fault when using spmc:::channel | After a few days studying Rust I have come to a road block with segmentation faults and other errors when running a simple program using an mpsc channel. use std::thread; use std::fs::File; use std::io::{BufReader,BufRead}; pub fn main() { let (tx, rx) = spmc::channel(); let mut  | labels: I-crash, T-libs-api, I-unsound, C-bug


Opt-level profile override causes function miscompile to ud2 on MacOS | Opt-level profile override causes function miscompile to ud2 on MacOS. I wasn't able to reproduce this bug on Windows 10. **rustc version:** 1.38.0-nightly (6e0d27d93 2019-08-03) The most minimal example I could come up with: https://github.com/mvlabat/ud2 **src/main.rs:** https: | labels: O-macos


ICE with closure return type as impl trait type alias defining use | In an attempt to make the compiler recognize my defining use of an impl trait type alias without making a separate wrapper function, I ran this code, but it resulted in an ICE: ```rust #![feature(type_alias_impl_trait)] pub type Closure = impl FnOnce(); fn main() { || -> Closure  | labels: I-ICE, A-closures, T-compiler, A-impl-trait, C-bug, F-type_alias_impl_trait


The standard library should have a basic future runtime | While libraries like Tokio and runtime exist, there's a real discovery problem for new users. And importing a large library like those can increase compile time a bunch and whatnot. For ease of use, I'm proposing that the standard library contains a simple future runtime. It does


rustdoc: Built-in macros are not documented in all the necessary locations | NOTE: Some cases below assume https://github.com/rust-lang/rust/pull/63056 has landed. - :negative_squared_cross_mark: https://doc.rust-lang.org/nightly/core/default/index.html doesn't contain the derive macro `Default`. :heavy_check_mark: Compare with the https://doc.rust-lang.o | labels: T-rustdoc, A-macros, C-bug


f32/64::asinh() should return -0.0 for -0.0 | Currently, both of the following return false: ```rust (-0.0 as f64).asinh().is_sign_negative() (-0.0 as f32).asinh().is_sign_negative() ``` However, in other languages like [C](https://en.cppreference.com/w/c/numeric/math/asinh), `asinh(-0.0)` would always return `-0.0`. We migh | labels: T-libs-api, C-bug


Should the Future trait be in the prelude? | I'm curious what opinions people have about this. | labels: T-lang, C-feature-request


rustdoc: `DerefMut` methods are missing from sidebar | Take a look at https://doc.rust-lang.org/std/vec/struct.Vec.html. The sidebar has `Deref<Target=[T]>`, but not `DerefMut`, so methods like `sort` are missing. | labels: T-rustdoc, C-bug


Different error messages between async and regular functions | Hi, Let's consider following code: ```rust fn foo() -> Result<bool, ()> { unimplemented!() } fn bar() -> Result<(), ()> { foo()?; () } ``` There's an error in the penultimate line - it should say `Ok(())` and Rust correctly helps to spot the mistake: ``` | 7 | fn bar() -> Result< | labels: A-diagnostics, T-compiler, A-async-await


How to do Zero-fill right shift in rust? | ```rust fn main(){ let i:i32 = -9; println!("{}", i >>> 3) } ```


ICE: instantiated twice | While minimizing https://github.com/rust-lang/rust/issues/63263 I stumbled upon another ICE ```rust #![feature(type_alias_impl_trait)] type Closure = impl FnOnce(); fn c() -> Closure { || -> Closure { || () } } fn main() {} ``` ([Playground](https://play.rust-lang.org/?version=ni | labels: I-ICE, E-needs-test, A-closures, T-compiler, A-impl-trait, C-bug


ICE - 'cannot access a scoped thread local variable without calling `set` first' | Hello, After updating nightly version to `2019-07-31` (also fails on `2019-08-04`), previously working code no longer compiles. I can confirm that it compiles successfully on `nightly-2019-07-30`. EDIT: Happens on `debug` aswell, also doesn't happen on macOS, but I'm not sure whe | labels: I-ICE, T-compiler, A-thread-locals, C-bug, E-needs-mcve


update rustdoc's syntax checker to work with error-recovering lexer | Rustdoc processes code inside of `` ``` `` blocks in two ways: * _First_, the code is [checked](https://github.com/rust-lang/rust/blob/4be067558962c004b638e4c6f162d50f7c0c98b6/src/librustdoc/passes/check_code_block_syntax.rs#L28-L99) for lexer errors * _Second_, lexer-based synta | labels: C-cleanup, T-rustdoc


Parser silent exit on invalid input | I'm using rustc's parser ([`parse_crate_mod`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html#method.parse_crate_mod) more specifically) as part of a program I'm writing and for some inputs, the parser terminates my program. Using the curren | labels: A-parser


const generics and lifetimes ICE | The following ICE's on _stable_, beta and nightly, even though `const_generics` is nightly only: ```Rust #![feature(const_generics)] use core::marker::PhantomData; struct Bug<'a, const S: &'a str>(PhantomData<&'a ()>); impl Bug<'_, {""}> {} ``` <details> <summary>Backtrace:</summ | labels: I-ICE, T-compiler, C-bug, A-const-generics


Tracking issue for uninitialized constructors for Box, Rc, Arc | Assigning `MaybeUninit::<Foo>::uninit()` to a local variable is usually free, even when `size_of::<Foo>()` is large. However, passing it for example to `Arc::new` [causes at least one copy](https://youtu.be/F1AquroPfcI?t=4116) (from the stack to the newly allocated heap memory) e | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, requires-nightly


ICE on generic associated type with a bound referencing the quantified type | I was reading https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in-rust.html and decided to try some of the code samples, but the compiler panicked! ```rust trait Functor<A> { type HigherSelf<T>: Functor<T>; } ``` Crashes with `error: internal compiler error: src/librustc | labels: I-ICE, A-associated-items, T-compiler, C-bug, F-generic_associated_types, glacier


std::iter::Rev breaks order or operation with std::iter::Map | Hello, I've just found out that when you use `it.rev().map(...).rev()`, the two `.rev()` seem to cancel each other. While in most cases, this isn't much of an issue, it does cause problems with stuff such as this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018 | labels: T-libs-api, C-bug, A-iterators


running "./x.py test" after "./x.py build" build fails | Here is the relevant part... ``` ... Testing rustc_macros stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) [0/45477] Finished release [optimized] target(s) in 0.10s Running build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/rustc_macros-9c38a09c1d63337a running | labels: T-bootstrap, C-bug


Warn on using intra-doc links on stable | It would be a significant effort to implement feature-gates in Rustdoc just for intra-doc links so I understand why that hasn't been done. However, because there is no warning I've been unintentionally creating docs with broken links on stable for a while now. I haven't observed  | labels: T-rustdoc, C-enhancement, A-stability, A-intra-doc-links


librustc/infer/lexical_region_resolve readme points to unreachable url | It's the first link here https://github.com/rust-lang/rust/blob/a6294b762859b3bb86b2a94c6857ae39beea9aeb/src/librustc/infer/lexical_region_resolve/README.md | labels: T-compiler, A-docs, A-NLL, C-bug


Closures in const generics cause ICE | Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. ``` #![feature(const_generics)] fn test<const F: &'static dyn Fn(u32) -> u32>(i: u32) -> u32 { F(i) } const F: &'static dyn Fn(u32) -> u32 = &|x| x*x; fn main () { | labels: I-ICE, A-closures, T-compiler, C-bug, A-const-generics, requires-nightly


Incorrect `unreachable_code` lint for loops in `try_blocks` | ```rust #![feature(try_blocks)] pub fn foo() { let _: Result<(), ()> = try { loop { // anything here } }; } ``` Here, the entire `loop` expression is reported unreachable, despite not being so. This is similar to https://github.com/rust-lang/rust/issues/54165, and probably has th | labels: A-lints, T-compiler, C-bug, requires-nightly, F-try_blocks


File::set_len uses an unsafe cast on Unix | Precisely, `size as off64_t`. The conversion occurs [here](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/fs.rs#L558) On my system `off64_t` is `i64`. This means that the number will overflow if larger than `i64::max_value()` and become negative. In such case,  | labels: T-libs-api, C-bug


remap-path-prefix affects dep-info | The `--remap-path-prefix` flag affects paths in dep-info files. This causes some problems witth Cargo. Cargo uses these paths to detect if any source file has been modified. Since the common use case for `--remap-path-prefix` is to rewrite to some artificial path (like `/rustc/$H | labels: A-driver, T-compiler, C-bug


Warn about path change for `#[doc(include)]` | Recently (https://github.com/rust-lang/rust/pull/60938) the path root for `#[doc(include)]` files was changed. This change makes a lot of sense, and it's not difficult to update, but there is now a situation where code using the old path roots won't compile on new nightlies and v | labels: T-rustdoc, C-enhancement, A-diagnostics, F-external_doc


Is the order of procedural macro attribute execution guaranteed per item? | Hiya, is there an intentional guarantee that procedural macro attributes are executed outward-in per item? To illustrate ([repo](https://github.com/azriel91/proc_macro_attribute_order)): ```rust // attr_* appends a new field to the struct #[attr_0(u8)] #[attr_1(u16)] #[attr_2(u32 | labels: A-attributes, A-macros, T-lang


remap-debuginfo causes some rustc tests to fail | Setting `remap-debuginfo` to `true` in `config.toml` will cause a few tests to fail. They are: - `ui/impl-trait/impl-generic-mismatch.rs` - `ui/consts/const-size_of-cycle.rs` - `ui/type_length_limit.rs` The issue is that these tests use `$SRC_DIR` in their `.stderr` output, but w | labels: A-testsuite, A-debuginfo, T-compiler, C-bug


Rust execute the SHELL command 'git --no-pager log --author=authorname' cannot get output


Recompiling causes panic | Making changes to code in modules that compile to WASM and running `cargo build --release` results in a panic. This is the project: https://github.com/paritytech/substrate Immediately running `cargo clean && cargo build --release` will allow successful compilation. Also upgrading | labels: I-ICE, P-high, T-compiler, A-incr-comp, C-bug, E-needs-mcve


Intra-rustdoc links do not work for all primitives | Coming from the tracking issue #43466. I'm trying to link to [`slice::rotate_left`](https://doc.rust-lang.org/std/primitive.slice.html#method.rotate_left) and it doesn't seem to be supported I tested [`pointer::is_null`](https://doc.rust-lang.org/stable/std/primitive.pointer.html | labels: T-rustdoc, E-hard, E-mentor, C-bug, A-intra-doc-links


ICE with type_alias_impl_trait: errors selecting obligation during MIR typeck | ```rust #![feature(type_alias_impl_trait)] pub trait Foo {} pub trait Bar { type Foo: Foo; fn foo() -> Self::Foo; } pub trait Baz { type Foo: Foo; type Bar: Bar<Foo = Self::Foo>; fn foo() -> Self::Foo; fn bar() -> Self::Bar; } impl Foo for () {} impl Bar for () { type Foo = FooIm | labels: E-needs-test, T-compiler, A-impl-trait, C-bug, F-type_alias_impl_trait, requires-nightly


`std::iter::count` and `std::iter::count_with` functions | It would be great to have these functions, which would behave similarly to the `once` / `once_with` and `repeat` / `repeat_with` functions, except they would iterate a fixed number of times (given by a `usize`) instead of just once/infinitely. | labels: T-libs-api, C-feature-request, A-iterators


A way to force the compiler to accept falsely named "Undefined behavior" | I'm trying to execute some data in Rust, however I'm getting this error: ``` error[E0080]: it is undefined behavior to use this value --> src/main.rs:9:1 | 9 | / const executable_data: extern "C" fn() = unsafe { 10 | | std::mem::transmute(address) 11 | | }; | |__^ type validation | labels: T-lang, C-feature-request, A-const-eval


Link errors on MSVC Nightly since around 2019-07-13 | Any crate that uses `std::sync::Arc` fails to compile with a link error saying `unresolved external symbol __atomic_fetch_sub_8` Test case on `rustc 1.38.0-nightly (6a91782b7 2019-08-06)` ```rust fn main() { let test = std::sync::Arc::new(32); } ``` outputs: ``` link_error-44aa39 | labels: A-linkage, A-LLVM, O-windows, O-linux, regression-from-stable-to-nightly, T-compiler


Inconsistent behavior between check and build when handling duplicate #[no_mangle] static values | <!-- Thanks for filing a 🐛 bug report 😄! --> (if this issue is better suited to rust-lang/rust, please let me know and I'll post it there) **Problem** `cargo check` and `cargo build` behave differently when handling two identically-named `#[no_mangle]` static values defined in di | labels: A-metadata, T-compiler, T-cargo


ICE when iterating over a `u16` range whose bounds exceed 64k | An ICE is observable with this code: ``` fn part(_: u16) -> u32 { 1 } fn main() { for n in 100_000.. { let _ = part(n); } } ``` ``` thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1', src/librustc_lint/types.rs:79:12 note: Run with `RUST_BACKTRACE=1 | labels: E-easy, A-lints, I-ICE, T-compiler, regression-from-stable-to-stable, C-bug


Confusing error message with FnMut | https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=12bbb938650f4835979fafc55ce9c5ea ```rust fn main() { fn do_twice<F>(mut func: F) where F: FnMut() { func(); func(); } let mut x: usize = 1; { // let add_two_to_x = || x += 2; // compliled let add_two_to_x =  | labels: C-enhancement, A-diagnostics, T-compiler


'cargo check' and 'cargo build' do not behave in the same way? | ## Problem This code, why 'cargo check' can pass, but 'cargo build' can't： ```rust fn main() { let a = [1, 2, 3, 4, 5]; const INDEX: usize = 10; let element = a[INDEX]; println!("element is: {:?}", element); } ``` cargo check: ``` $ cargo check Checking test v0.1.0 (/home/rust/te | labels: T-compiler


"conflicting implementations of trait" error missing helpful note on private traits | If I write this simple, but incorrect program, rust gives me a useful output message: ```rust pub trait MyTrait {} impl<T: Copy> MyTrait for T {} impl MyTrait for String {} ``` The output here is: ``` Compiling conflicttest v0.1.0 (/home/daboross/conflicttest) error[E0119]: confl | labels: C-enhancement, A-diagnostics, A-trait-system, T-compiler


Confusing documentation for compile_error!() | Referring to https://github.com/rust-lang/rust/blob/db7c773a6be2f050d1d1504763819ea3916f5428/src/libcore/macros.rs#L681-L683 > It's the compiler-level form of panic!, which emits an error at runtime, rather than during compilation. It is unclear whether the "which" refers to "pan | labels: C-enhancement, A-docs


Unnecessary mul when multiplying u128 by small number | For this function ```rust pub fn mul_u128_10(a: u128) -> (u8, u128) { let (a_hi, a_lo) = (a >> 64, a & !(!0 << 64)); let (ten_a_hi, ten_a_lo) = (a_hi * 10, a_lo * 10); let (wrapped, overflow) = (ten_a_hi << 64).overflowing_add(ten_a_lo); ((ten_a_hi >> 64) as u8 + u8::from(overflo | labels: A-LLVM, I-slow, T-compiler


Unhelpful error message with async usage of Iterator | I'm not sure, if the behaviour itself is a bug or not, but the error message is surely not helpful. Code: ```rust #![feature(async_await)] use futures::future::FutureExt; use futures::future::TryFutureExt; use futures::stream::StreamExt; fn main() { tokio::run(function().unit_err | labels: A-diagnostics, T-compiler, A-async-await, AsyncAwait-Triaged, requires-nightly


`&self` lifetime elision with two parameters does not work with `async fn` | Originally reported in https://github.com/rust-lang/rust/pull/63383#discussion_r312128268. ```rust #![feature(async_await)] #![feature(nll)] // Without it you also get //~^ ERROR cannot infer an appropriate lifetime struct A; impl A { async fn foo(&self, f: &u32) -> &A { self } } | labels: A-type-system, A-lifetimes, T-compiler, A-inference, C-bug, A-async-await


Decide whether to suggest anything when encountering `break` and expecting `!` | https://github.com/rust-lang/rust/pull/63337#discussion_r312153076 introduces suggestions when encountering `break` without a value in a context that expects a value other than `()`. In the case that the expected value is `!` we don't suggest anything. Once `!` is stabilized, we  | labels: A-diagnostics, P-low, T-compiler, A-suggestion-diagnostics, F-never_type


Improve diagnostic for `break` in `async { ... }` block | With: ```rust #![feature(async_await)] fn foo() { async { break; }; } ``` you get: ```rust error[E0267]: `break` inside of a closure --> src/lib.rs:5:9 | 5 | break; | ^^^^^ cannot break inside of a closure ``` Note how it references "a closure" which seems confusing for a user wh | labels: C-enhancement, A-diagnostics, T-compiler, A-async-await, AsyncAwait-Triaged, requires-nightly


rustdoc ICE "tried to get index of builtin macros crate" | ``` Documenting fuchsia_vfs_pseudo_fs v0.1.0 (/b/s/w/ir/k/out/default/gen/garnet/public/rust/fuchsia-vfs/pseudo-fs/pseudo-fs) error: internal compiler error: src/librustc/hir/def_id.rs:51: Tried to get crate index of builtin macros crate thread 'rustc' panicked at 'Box<Any>', src | labels: T-rustdoc, I-ICE


Fix ambiguity issue with associated_type_bounds | Follow up of #61738. These two particular cases could not be refactored due to an ambiguity issue: --- https://github.com/rust-lang/rust/blob/2d1a551e144335e0d60a637d12f410cf65849876/src/libcore/iter/adapters/flatten.rs#L70-L76 With `#![feature(associated_type_bounds)]` ```rust i | labels: A-associated-items, T-compiler, C-bug, E-needs-mcve, requires-nightly, F-associated_type_bounds


Clean up `parse_bottom_expr` to use list parsing utility | _From https://github.com/rust-lang/rust/pull/63337#discussion_r312221122_ The following code should be using the common list parsing utilities: https://github.com/rust-lang/rust/blob/2d1a551e144335e0d60a637d12f410cf65849876/src/libsyntax/parse/parser.rs#L2052-L2070 CC @Centril | labels: A-frontend, C-cleanup, A-parser, T-compiler


Wrong block referenced when emitting E0728 | The following code ([Playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=3e36922f1d43ba54d23783769a15e381)) ```rust #![feature(async_await)] async fn do_the_thing() -> u8 { 8 } fn main() { let x = move || {}; let y = do_the_thing().await; } ` | labels: A-diagnostics, T-compiler, C-bug, A-async-await, AsyncAwait-Triaged


Wrong error message with closures when variable moved | https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c4b92f189e40cc2a6e8a6d13a24e4ee8 ```rust struct T(u32); fn by_value(_: T) {} fn by_ref(_: &T) {} fn main() { let z = T(123); let closure = || { by_ref(&z); by_value(z); }; closure(); by_value(z); } ``` Outpu | labels: A-diagnostics, A-closures, T-compiler, C-bug


cleanup: remove needless reference to Instance | At least one case of this is in src/librustc_mir/interpret/snapshot.rs on line 305, but grepping is also advisable. _Originally posted by @eddyb in https://github.com/rust-lang/rust/pull/63287_ | labels: C-cleanup, T-compiler, A-const-eval


E0529 should suggest turning the matched `Vec` into a slice | ``` error[E0529]: expected an array or slice, found `std::vec::Vec<{integer}>` --> src/test/ui/suggestions/vec-macro-in-pattern.fixed:4:14 | LL | Some([x]) => () | ^^^ pattern cannot match with input type `std::vec::Vec<{integer}>` error: aborting due to previous error ``` CC #63 | labels: C-enhancement, A-diagnostics, T-compiler, A-suggestion-diagnostics, D-newcomer-roadblock


Building LLVM with Clang fails | In `config.toml`, under `[target.x86_64-unknown-linux-gnu]`, one can set `cc` and `cxx` to configure the C/C++ compiler used for building LLVM. When using clang/clang++, regardless of whether `use-libcxx` is set under `[llvm]`, the `LLVM_LIBSTDCXX_MIN` compile test fails due to a | labels: A-LLVM, T-compiler, T-bootstrap, C-bug


Unexpected error in for loop: use of possibly uninitialized | The following code: ``` fn main() { let foo = 10; let result; for _i in 1..=1 { if foo == 10 { result = true; break; } match foo { 7 => { result = true; } _ => { result = false; break; } } break; } println!("{}", result) } ``` yields the following error: ``` Compiling playground


[ICE] C-variadic functions are only valid with one or more fixed arguments | This ICEs (see title) because of the call: ```rust extern { fn foo(...); } fn main() { unsafe { foo(1, 2, 3); } } ``` That's because the definition of `foo` errored in 1.34, but doesn't since 1.35: ```rust extern { fn foo(...); } ``` cc @dlrobertson (found while working on https: | labels: A-type-system, I-ICE, T-compiler, regression-from-stable-to-stable


Compilation panicked | Compilation exited abnormally when compiling [this code](https://github.com/gcao/gene.rs/blob/f861fba0d25f6a6de2f01a680bd39eebcf40b7e2/src/compiler.rs#L162) I know my code has a lot of issues but the compiler should either pass or fail instead of panicking Steps to reproduce git  | labels: I-ICE, A-borrow-checker, T-compiler, C-bug, fixed-by-NLL


Rustdoc search result links to 404 | On the following page: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/?search=niche_start clicking on any of the two search results yields a 404 error. | labels: T-rustdoc, C-bug


debuginfo/empty-string.rs test failed on Linux | When I run `x.py test` on Linux, `debuginfo/empty-string.rs` test failed with the following error: ```rust Check compiletest suite=debuginfo mode=debuginfo-gdb+lldb (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) running 122 tests .iiiii..ii.....i..i...i..i.iFi..i.ii..iii. | labels: A-testsuite, O-linux, A-debuginfo, T-compiler, C-bug


"Structural match" annotations should be moved from struct/enum items to impl items | "Structural match" property of a type means that the constants of this type can be used in patterns (https://github.com/rust-lang/rust/issues/31434) or in const generics in the future. Right now this property can be given to a type in two ways: - `#[structural_match]` attribute,  | labels: A-type-system, A-resolve, A-trait-system, A-macros, T-lang, T-compiler


const_prop makes RUST_CTFE_BACKTRACE unusable | The idea behind `RUST_CTFE_BACKTRACE=1` was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in const_prop, and now I get thousands of | labels: T-compiler, C-bug, A-const-eval, A-miri


[rustdoc] on search results, when pressing ESC, either remove text in URL or don't remove text in search bar | I think the best be the second: not removing text from search bar. | labels: T-rustdoc


Rustc panics with comments with non-ascii characters after an error | Running this on playground: ```rust struct A {} fn main() { let a = A; // é } ``` Panics rustc: ``` Compiling playground v0.0.1 (/playground) thread 'rustc' panicked at 'byte index 44 is not a char boundary; it is inside 'é' (bytes 43..45) of `struct A {} fn main() { let a = A; / | labels: A-diagnostics, I-ICE, A-parser, T-compiler, C-bug


rustc hangs on this particular invalid `if let` syntax | The following code causes rustc to hang, consuming 100% CPU on one core, and unbounded memory until it is killed by the OOM killer: fn main() { let condition = Some(true); (if let Some(x) = condition) && x { println!("condition is present and true"); } } This is the output from ` | labels: A-parser, T-compiler, C-bug, I-hang


Incorrect Code Generation | https://godbolt.org/z/Q0WgsL ```rust use std::os::raw::c_char; use std::ffi::c_void; const RTLD_NEXT: *mut c_void = -1i64 as *mut c_void; extern "C" { fn dlsym(handle: *mut c_void, symbol: *const c_char) -> *mut c_void; } #[allow(non_camel_case_types)] type pid_t = i32; #[inline(


Some(..).is_some() is false for redox_syscall datastructure | When using the redox_syscall crate, the compiler fail at an `assert!(Some(..).is_some())`. This bug however is only present with the crate: locally defining the same datastructure runs perfectly. Equality still works, though, as the fields can be compared. ## Minimum reproducible


std::env::var and std::env::var_os do not document panic on key containing null byte | `env::remove_var` and `env::set_var` document that they panic when the key contains a null byte, but `env::var` and `env::var_os` do not document this behavior. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e43934f459b10424f374f20db846f092 | labels: A-docs


Consider move libarena and libgraphviz out of tree | These code doesn't get touched a lot. So maybe it makes sense to move them out instead of generating auto publish packages every day. | labels: C-enhancement, T-compiler


incompatible types even if and else uses the same code... | ```rust error[E0308]: if and else have incompatible types --> src/main.rs:98:17 | 87 | / if query["size"] != json!(-1) { 88 | | Client::new() | _|_________________- 89 | | | .post(&url) 90 | | | .json(&query) 91 | | | .send() ... | | 95 | | | }) 96 | | | .map_err(error::ErrorInte


Recursive macro call inside concat macro fails to find macros referred to by $crate | ```rust #[macro_export] macro_rules! separator { () => { "/" }; } #[macro_export] macro_rules! concat_separator { ( $e:literal, $($other:literal),+ ) => { concat!($e, $crate::separator!(), $crate::concat_separator!($($other),+)) }; ( $e:literal ) => { $e } } fn main() { println!( | labels: A-resolve, A-macros, T-compiler, C-bug


segfault with target-feature=+soft-float | The following program currently segfaults on x86_64-unknown-linux-gnu when compiling with stable rust 1.36.0 with soft-float, and running with TARGET unset. ```rust use std::env; fn main(){ let target = env::var("TARGET").unwrap(); println!("{}", target); } ``` Here's the output: | labels: O-linux, P-high, T-compiler, I-unsound


nightly version fails: invalid version 3 on git_proxy_options; class=Invalid (3) | On FreeBSD 12 amd64 rust-nightly-1.38.0.20190811_1 fails: ``` $ cargo build Updating crates.io index error: failed to load source for a dependency on `image` Caused by: Unable to update registry `https://github.com/rust-lang/crates.io-index` Caused by: failed to fetch `https://gi | labels: O-freebsd, C-bug


Typo in `println` docs. | There is an unclosed parenthesis in the [docs](https://doc.rust-lang.org/std/macro.print.html) for [`println!`](https://github.com/rust-lang/rust/blob/master/src/libstd/macros.rs#L122). The line in question is [line 122](https://github.com/rust-lang/rust/blob/master/src/libstd/ma


Lots of "cannot find in scope" errors can make name resolution extraordinarily slow | I missed a `use` and found a `check` that takes _over 4 minutes_ to fail. Repro: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=aaac7e403ced051c0e4165df25a455a5 time-passes blames this on "name resolution" | labels: A-diagnostics, A-resolve, I-compiletime, T-compiler


Regression: Matching on function pointers fails when one of the formal params implements custom PartialEq | A contrived [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=401774c0d5d389dc0d621608553f7e99) example: ```rust #[derive(Eq)] struct A { a: i64 } impl PartialEq for A { #[inline] fn eq(&self, other: &Self) -> bool { self.a.eq(&other.a) } } typ | labels: P-high, T-compiler, regression-from-stable-to-beta, C-bug


Compiler is awkwardly happy with fns without Box | Hi, I'm writing a functional programming library in Rust, and I found some weird behaviour with typing. In the below code to emulate `Apply` ``` use crate::functor::Functor; use crate::hkt::{HKT, HKT3}; pub trait Apply<A, F, B>: Functor<A, B> + HKT3<A, F, B> where F: FnOnce(A) ->


Using profile-overrides results in both optimized and unoptimized versions of the same crate in linked executable | I'm trying to use the "profile-overrides" feature in cargo. The tracking issue for this feature is here: https://github.com/rust-lang/rust/issues/48683 The documentation for this is here: https://doc.rust-lang.org/cargo/reference/unstable.html#profile-overrides I'm trying to buil | labels: T-cargo, C-bug


ICE when trying to reference an associated trait constant | ``` trait ToBytes { const SIZE: usize; fn a(self) -> [u8; ToBytes::SIZE]; // error happens because a previous type error happened I think fn b(self) -> [u8; ToBytes::SIZE]; } ``` ## Error message `error: internal compiler error: src/librustc/traits/codegen/mod.rs:51: Encountered  | labels: A-codegen, I-ICE, E-needs-test, P-medium, A-associated-items, T-compiler


async fn methods and impl `'_` elision do not interact correctly | As [reported by @cramertj](https://github.com/rust-lang/rust/issues/63225#issuecomment-519163528), this example: ```rust #![feature(async_await)] struct Foo<'a>(&'a u8); impl Foo<'_> { async fn bar() {} } ``` currently produces this error: ``` error[E0261]: use of undeclared life | labels: A-lifetimes, T-compiler, A-inference, A-async-await, AsyncAwait-Polish


When needing type annotation do not suggest using `impl Trait` or closure | _Subset of https://github.com/rust-lang/rust/issues/63502_ When encountering ``` #![feature(async_await)] use std::io::Error; fn make_unit() -> Result<(), Error> { Ok(()) } fn main() { let fut = async { make_unit()?; Ok(()) }; } ``` Do not suggest "consider giving `fut` the expli | labels: E-easy, A-diagnostics, P-medium, T-compiler, A-inference, C-bug


Suggest `Box::new` on E0308 when appropriate | When encountering a boxed value as expected and a stack allocated value that could be boxed to fulfill the expectation, like in the following snippet, suggest `Box::new` wrapping: ``` fn main() { let x: Box<Fn() -> _> = || { Err(())?; Ok(()) }; } ``` ``` error[E0308]: mismatched  | labels: C-enhancement, A-diagnostics, P-low, A-closures, T-compiler, A-suggestion-diagnostics


Spurious expired crates.io certificate on CI | We encountered multiple spurious failures while trying to download crates from crates.io, related to an expired certificate. This is probably something happening on the CI VMs, as the crates.io certificate is expiring in a few months (maybe the clock goes back to the epoch for wh | labels: A-spurious, T-infra, C-bug


Azure Pipelines sometimes doesn't report back its status to GitHub | It happened a few times that Azure Pipelines doesn't report back the build status to GitHub, causing the commits to be in a permament "in progress" state. For example, a few times it happened yesterday: * https://github.com/rust-lang/rust/runs/191033192 * https://github.com/rust- | labels: A-spurious, T-infra, C-bug


Tracking issue for map_ok and map_err method for Poll<Option<Result<T, E>>> | Currently map_ok and map_err methods are given for Poll<Result<T, E>>. We should provide similar methods for Poll<Option<Result<T, E>>> as they are helpful in stream building code. --- ### Steps - [x] Implementation: https://github.com/rust-lang/rust/pull/63512 - [x] Stabilizatio | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, A-async-await


Weird compiler behavior with in-lining of a function -> constant value arbitrary changed | Hey there, I guess I found a weird bug in the compiler in the following scenario: I do have a function with the following signature and the first part of the contents given like this: ``` pub(crate) fn send_message<T: MailboxMessage>(channel: MailboxChannel, message: &T) -> Mailb | labels: A-LLVM, A-codegen, P-high, T-compiler, I-unsound, C-bug


Dependencies "can't find crate `core`" on nightly for thumbv7em-none-eabi | The following steps will work and compile on stable, but not on nightly. # Steps to reproduce ``` rustup target add thumbv7em-none-eabi cargo new --lib compile-fail && cd compile-fail echo 'libc="=0.2.61"' >> Cargo.toml # or cargo add libc@0.2.61 echo '#![no_std]' > src/lib.rs ca | labels: T-compiler, C-bug


run-make-fulldeps/linker-output-non-utf8 failure | when running `x.py test` locally I get errors in the test `run-make-fulldeps/linker-output-non-utf8`: ``` ---- [run-make] run-make-fulldeps/linker-output-non-utf8 stdout ---- error: make failed status: exit code: 2 command: "make" stdout: ----------------------------------------- | labels: A-linkage, A-testsuite, P-medium, T-compiler, T-bootstrap


Any rust-related command opens non-unicode file called "cargo" or "rustup" | When using any of the rust related commands, it opens a file that has 3 identifiable characters at the top and a mixed amount of bullcrap in the rest. "ELF" is at the top. Please take a look for yourself cause It's causing me tons of problems. [rustup.txt](https://github.com/rust


Include type bindings on string representation of `impl Trait` | _Follow up to https://github.com/rust-lang/rust/pull/63507#discussion_r313287274_ Include type arguments for traits when displaying `impl Trait`. For example, the following: ``` error[E0282]: type annotations needed for `impl std::future::Future` --> $DIR/cannot-infer-async-enabl | labels: C-enhancement, A-diagnostics, T-compiler, A-async-await, AsyncAwait-Triaged


Date time chronology calendar JSR-310 capabilities within rust | I understand JSR-310 was mentioned earlier. I understand others have mentioned this as issue on github, but why has the issue been closed when I haven't seen the capabilities as being implemented yet? If they have been implemented, please indicate where they are. Thank you https:


Improve error message for `.await` in 2015 edition | Trivial example: ```rust fn f(x: std::pin::Pin<&mut dyn std::future::Future<Output=()>>) { x.await; } ``` Output on current nightly: ``` error[E0609]: no field `await` on type `std::pin::Pin<&mut dyn std::future::Future<Output = ()>>` --> src/lib.rs:2:7 | 2 | x.await; | ^^^^^ unk | labels: A-type-system, C-enhancement, A-diagnostics, T-compiler, A-async-await


ICE on roman numeral macro example | ## Description of Problem I'm trying to run the roman numeral compiler plugin code in the documentation ([here](https://doc.rust-lang.org/nightly/unstable-book/language-features/plugin.html)). The compiler panics with this error: ``` thread 'rustc' panicked at 'cannot access a sc


CI is shown stuck on github | The CI seems to be stuck on Github and jobs are shown running for more than a day but it has actually completed in Azure. ![Capture](https://user-images.githubusercontent.com/22871609/62998376-f2368600-be88-11e9-9216-d2617dc8b754.PNG) ![Capture](https://user-images.githubusercont


thread 'main' has overflowed its stack | There're something wrong with my code , but I don't know why ? Please help me , thx very much! ``` use std::collections::HashMap; enum SyntaxKind { Unknown, } impl std::fmt::Display for SyntaxKind { fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result { write!(f, "{}",


Codegen backend handles compare binops for the unit type | https://github.com/rust-lang/rust/blob/c43d03a19f326f4a323569328cc501e86eb6d22e/src/librustc_codegen_ssa/mir/rvalue.rs#L586-L592 libcore however doesn't use those for the implementations for `PartialEq` and `PartialOrd` for the unit type. https://github.com/rust-lang/rust/blob/c4 | labels: E-easy, C-cleanup, A-codegen, E-mentor, T-compiler, E-help-wanted


Codegen forgets array size when used with iterators | Consider these three functions: ``` pub fn in_range1(x: [usize; 3], m: usize) -> bool { (x[0] < m) && (x[1] < m) && (x[2] < m) } pub fn in_range2(x: [usize; 3], m: usize) -> bool { for k in &x { if *k >= m { return false; } } true } pub fn in_range3(x: [usize; 3], m: usize) -> bo | labels: A-LLVM, I-slow, P-medium, T-compiler, regression-from-stable-to-stable, C-bug


Sporadic linker failure | I compiled a rather large project and got the error below: ``` error: linking with `cc` failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/alice/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" | labels: A-linkage, T-compiler, C-bug


Linking with extern function in Wasm | I am trying to use functions from an external module and importing them like that: ```rust #[link(wasm_import_module = "sqlite")] extern "C" { #[link_name="allocate"] pub fn allocate_external(size: usize) -> i32; #[link_name="deallocate"] pub fn deallocate_external(ptr: i32, size | labels: A-linkage, T-compiler, O-wasm


Meta tracking issue for RFC 1892, "Deprecate uninitialized in favor of a new MaybeUninit type" | This issue tracks the progress of `MaybeUninit<T>` in general. The type was introduced in https://github.com/rust-lang/rfcs/pull/1892. The old tracking issue is https://github.com/rust-lang/rust/issues/53491. This issue is not for discussion about specific extensions to `MaybeUni | labels: metabug, T-lang, T-libs-api, C-tracking-issue, Libs-Tracked, A-raw-pointers