[bug] When I Use tauri-plugin-http and reqwest either, I got a panic | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, P-medium, T-compiler, regression-from-stable-to-stable, C-bug, A-coercions


ICE Unsize coercion, but `Box<{async block@file.rs}>` isn't coercible to `Box<dyn Send>` | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, E-mentor, T-compiler, E-medium, C-bug, S-has-mcve


[ICE]: !tcx.next_trait_solver_globally() | <!-- ICE: Rustc ./2969A4590773DF5416935FBB7FE10D4070C5F412CB47CD0E21F34E735F4A479B.rs '--edition=2024 -Znext-solver=globally -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' ($TID) panicked at compiler/rustc_hir_analysis/src/collect/type_of/opaque.rs: | labels: I-ICE, T-compiler, C-bug, WG-trait-system-refactor


normalize_lexically should mention other functions that do basic normalization | ### Location https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.normalize_lexically ### Summary both the PartialEq impl for Path and Path::components will normalize away non-leading `.` and duplicate/trailing slashes. This is "good enough" for  | labels: A-docs, T-libs


[ICE]: !self.tcx.next_trait_solver_globally() | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, T-compiler, C-bug, F-type_alias_impl_trait, WG-trait-system-refactor


std::pointer::Nonnull should guarantee ABI compatibility for non-null pointer values | Can we rely on `NonNull<T>` having the same representation as `*mut T` for all non-null values of that type? In particular, can we rely on e.g. `NonNull<std::ffi::c_void>` being ABI compatible with C `void*` for non-null pointers? It seems pretty likely that t | labels: T-libs-api, A-raw-pointers, C-discussion, T-opsem


Lint regression: `dead_code` ignores `#[allow(dead_code)]` on traits | ### Code ```rust #[allow(dead_code)] trait Foo { const FOO: u32; } impl Foo for u32 { const FOO: u32 = roundtrip(0); } const fn roundtrip(x: u32) -> u32 { x } ``` https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1991c4121122ea00f92d7386 | labels: A-diagnostics, P-low, T-compiler, regression-from-stable-to-stable, L-false-positive, I-lang-radar


stable compiler should provide better advice for `Step` trait failures | ### Code ```Rust fn custom_range() { struct Foo(u32); let x = Foo(0); let y = Foo(10); for value in x..y {} } ``` ### Current output ```Shell error[E0277]: the trait bound `Foo: Step` is not satisfied --> src/lib.rs:7:18 | 7 | for value in x..y {} | ^^^^ unsat | labels: A-diagnostics, T-compiler


Unclear compiler error when `impl Trait` return value captures non-'static argument | (cc @estebank) I tried this code (the explicit `'static` lifetime is unnecessary but emphasizes the implicit `'static` requirement of `impl Trait`): ```rust fn foo<T>(a: T) -> impl Iterator<Item = String> + 'static where T: std::fmt::Display { std::iter::once( | labels: A-diagnostics, A-lifetimes, T-compiler, A-impl-trait, C-bug, D-papercut


`-Clinker-plugin-lto` is required for inlining stdlib with LTO | ## Experiment setup Considering the following code: ```rust #![no_main] extern "C" { fn ftn() -> u32; } #[unsafe(export_name = "_start")] fn _start() -> f64 { let f77 = unsafe { ftn() } as f64; f64::cbrt(f77) } ``` The code is incorrect but quite good for demo | labels: A-linkage, T-compiler, C-bug, A-LTO


Issue | <!-- 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 proc


Missed optimization: introducing a temporary ownership move of `Vec` changes optimized code generation in `main`. | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code: https://godbolt.org/z/Ts7ss7zj4 ```rust #[no_mangle] fn grow(v: &mut Vec<isize>) {  | labels: C-optimization


Tracking Issue for reflection | This is a tracking issue for an un-RFC-ed language feature experiment The feature gate for the issue is `#![feature(reflection)]`. ### About tracking issues Tracking issues are used to record the overall progress of implementation. They are also used as hubs c | labels: T-lang, T-compiler, C-tracking-issue, S-tracking-unimplemented, B-experimental


ICE: `None.unwrap()` in `tokenstream.rs` during `resolver_for_lowering_raw` | This bug was found with a fuzzer ([tree-splicer](https://github.com/langston-barrett/tree-splicer)). Reduced with [treereduce](https://github.com/langston-barrett/treereduce), then hand-reduced. [playground](https://play.rust-lang.org/?version=nightly&mode=deb | labels: I-ICE, A-parser, A-macros, T-compiler, C-bug


False postive: warning of unnecessary `unsafe` block | ### Code I tried this code: ```rust fn main() { let a = unsafe { core::arch::x86_64::__cpuid_count(0, 0) }; dbg!(a); } ``` I expected to see this happen: it compiles without warnings. Instead, this happened: it compiles with a warning of unnecessary `unsafe` b | labels: T-lang, T-libs-api, C-discussion, S-has-bisection


Array Repeat operator should not use a loop for small sizes | This likely caused poor assembly for `Simd::splat` in some circumstances: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/Very.20bad.20.60u16x8.3A.3Asplat.60.20codegen.20on.20x86_64 I opened a PR for a workaround: https://gith | labels: A-LLVM, I-slow, A-codegen, E-needs-test, T-compiler, A-SIMD


multiline cfg_attr in a doctest outputs a corrupted snippet | With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping `main` method doesn't take into account the dangling `stdsimd))]` line that closes the attribute. ```rust /// ```rust /// # #![cfg_attr(not(dox), f | labels: T-rustdoc, A-doctests


ICE: Failed to extract DefId: opt_local_def_id_to_hir_id | ### Code Can be reproduced by first building (in debug mode) `crates/yaboc-hir` of https://github.com/8051enthusiast/yabo at commit `442536c09df2fe898bfeda81a2788bf9dce9dc19` after a `cargo clean` and then building at commit `5d5d795041d55d3bcbe21c5052807711dd | labels: I-ICE, T-compiler, A-incr-comp, C-bug, S-has-mcve


[ICE]: `arg len already exists` | <!-- ICE: Rustc ./a.rs '' 'thread 'rustc' ($TID) panicked at compiler/rustc_errors/src/diagnostic.rs:359:9: 'arg len already exists'', 'thread 'rustc' ($TID) panicked at compiler/rustc_errors/src/diagnostic.rs:359:9: 'arg len already exists'' File: /t | labels: I-ICE, T-compiler, C-bug, requires-debug-assertions


Method `SourceFile::normalized_byte_pos` is broken | I have been looking through the source of `rustc_span` and stumbled upon an inconsistent usage of byte positions. The problematic code is from [SourceFile::normalized_byte_pos](https://github.com/rust-lang/rust/blob/646a3f8c15baefb98dc6e0c1c1ba3356db702d2a/com | labels: T-compiler, C-bug


ICE due to RBV not handling RTN where trait is behind trait alias | Context: It's HIR ty lowering's job to resolve+lower RTN. However, it needs the lifetime resolutions from RBV which runs before HIR ty lowering and which (unfortunately) sort of duplicates some of HIR ty lowering code to resolve RTN itself. Now, while HIR ty l | labels: A-lifetimes, I-ICE, T-compiler, C-bug, F-trait_alias, S-has-mcve


ICEs (in debug mode) due to RBV not expanding trait aliases when collecting bound vars from supertrait bounds | 1st reproducer: ```rs #![feature(trait_alias)] trait A<'a> { type X; } trait B: for<'a> A<'a> {} trait C = B; fn f<T>() where T: C<X: Copy> {} ``` Compiler panic message w/o backtrace: ``` thread 'rustc' (47550) panicked at compiler/rustc_type_ir/src/binder.rs | labels: I-ICE, T-compiler, C-bug, F-trait_alias, S-has-mcve, T-types


Add mention that `ilog2` and `checked_ilog2` can be used to get the number of bits in an integer | ### Location - [`{integer}::ilog2`](https://doc.rust-lang.org/nightly/core/primitive.i32.html#method.ilog2) - [`{integer}::checked_ilog2`](https://doc.rust-lang.org/nightly/core/primitive.i32.html#method.checked_ilog2) - [`NonZero::ilog2`](https://doc.rust-lan | labels: A-docs, T-libs


regression: parameter may not live long enough | ``` [INFO] [stdout] error[E0310]: the parameter type `T` may not live long enough [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/cogo-0.1.2/src/yield_now.rs:35:13 [INFO] [stdout] | [INFO] [stdout] 35 | let r = resour | labels: regression-from-stable-to-beta, I-prioritize


Sub-optimal codegen: Unnecessarily dumping AVX registers to stack | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code ([example 1](https://rust.godbolt.org/z/86FfSi)), in which we have a public function | labels: I-slow, C-enhancement, A-codegen, T-compiler, A-SIMD, C-optimization


`unused_mut` false positive due to borrow-checking error | ### Code ```Rust struct Thing; impl Drop for Thing { fn drop(&mut self) {} } fn main() { let mut t; let mut b = None; loop { t = Thing; b.insert(&t); } } ``` ### Current output ```Shell warning: variable does not need to be mutable --> src/main.rs:7:9 | 7 | le | labels: A-lints, A-diagnostics, A-destructors, A-borrow-checker, T-compiler, L-unused_mut


Conflict markers with nonstandard lengths are not recognized as such | ### Code ```Rust <<<<<<<< ======== >>>>>>>> fn main() {} ``` ### Current output ```Shell error: expected identifier, found `<<` --> test.rs:1:1 | 1 | <<<<<<<< | ^^ expected identifier error: aborting due to 1 previous error ``` ### Desired output ```Shell erro | labels: A-diagnostics, T-compiler


GVN misunderstands aliasing, can create overlapping assignments (again) | This looks very similar to https://github.com/rust-lang/rust/issues/141038, but the compiler that found this has the patch that was linked to that issue. Reduced example from rustlantis, which is accepted by Miri without optimizations enabled: ```rust #![featu | labels: P-high, T-compiler, I-unsound, C-bug, A-mir-opt, I-miscompile


`*x == *y` for trait objects produce move error, so it is not equivalent to `PartialEq::eq(&*x, &*y)` even though the reference says it is | [The following code produces a move error](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=45b377544d27adffcaa1f0b38cbe22e0): ```rust trait Animal { fn noise(&self) -> String; } impl PartialEq for dyn Animal { fn eq(&self, other: &Self | labels: A-diagnostics, A-borrow-checker, T-compiler, A-docs, C-bug, A-dyn-trait


`#[expect(redundant_lifetimes)]` doesn't work when `#[derive(Debug)]` is present | Consider the following code: ```rust #![deny(redundant_lifetimes)] use std::fmt::Debug; #[derive(Debug)] pub struct RefWrapper<'a, T> where 'a: 'static, T: Debug, { pub t_ref: &'a T } ``` As expected, the compiler throws an error because the `'a` lifetime is r | labels: T-lang, C-bug, I-lang-radar


Tracking Issue for `atomic_try_update` | Feature gate: `#![feature(atomic_try_update)]` This is a tracking issue for an infallible version of `AtomicT::fetch_update` as well as a new name for the existing fallible version. When and if this gets stabilized, the existing `fetch_update` should be marked | labels: T-libs-api, C-tracking-issue, disposition-merge, finished-final-comment-period


Linker-plugin-based LTO with -flto in clang not working | The original issue title was "Implement cross-language ThinLTO," #49879 but when it was stabilized, the PR title became "Stabilize linker-plugin based LTO (aka cross-language LTO)," #58057 which seems to imply that fullLTO is available. The Rustc book states,  | labels: A-LLVM, T-compiler, C-bug


LLDB testing should be disabled | Per @khyperia in https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/debuginfo.20tests.20broken.20locally/with/571307617 these tests don't run in CI. On a contributor's machine they can easily fail to pass, for reasons I am not going | labels: A-testsuite, A-debuginfo, T-compiler, C-bug


Tracking Issue for `cold_path` | Feature gate: `#![feature(cold_path)]` This is a tracking issue for `core::hint::{cold_path}`. Please also see the meta discussion at https://github.com/rust-lang/rust/issues/26179. `#![feature(likely_unlikely)]` was split to a new tracking issue: https://gith | labels: T-lang, T-libs-api, C-tracking-issue


Meta tracking issue for branch hints (RFC 1131) | Tracking and meta discussion for branch and path hinting, including: - `likely`/`unlikely` as accepted in rust-lang/rfcs#1131 (much has changed since this RFC) - `core::hint::{likely, unlikely}` https://github.com/rust-lang/rust/issues/151619 - `core::hint::co | labels: metabug, B-RFC-approved, T-lang, B-unstable, E-help-wanted, C-tracking-issue


`hir::Body`'s documentation incorrectly suggests it doesn't contain parmaeter info for closures | ### Location https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.Body.html ### Summary Noticed this in rust-lang/rust-clippy#12981. The documentation says "a function" which I assume was meant to imply both a function/method call and closure w | labels: T-compiler, A-docs


Local `rustc-docs` could make use of local pages for `std` types | Posting this for @blyxyas and big thanks for having spotted this issue real quick :) ### Location (URL) The same problem persists in many different pages, just to pick an example on my machine: `$RUSTUP_HOME/toolchains/nightly-aarch64-apple-darwin/share/doc/ru | labels: T-rustdoc, A-docs


Inconsistent borrow-checking and temporary lifetime behavior with async closures | I've discovered some rather strange behavior involving borrow-checking and/or temporary lifetimes of async closures. Why does it behave this way? In the snippets below, `black_box` calls are done to be really clear that const promotion isn't occurring. The fol | labels: A-borrow-checker, C-bug, A-async-closures


mGCA: Support directly represented negated literals | Follow up of #150618 and #150699. We currently support directly represented literals as a `hir::ConstArgKind::Literal` but we don't support negated literals as such a representation: ```rust #![feature(adt_const_params, min_generic_const_args)] use std::marker | labels: E-easy, E-mentor, T-compiler, A-const-generics, F-adt_const_params, T-types


ICE：expected const for `N/#0` (N/#0/0) but found Type(A<N/#0>) when instantiating args=[A<N/#0>] | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, T-compiler, C-bug, F-inherent_associated_types, S-bug-has-test, requires-debug-assertions


ICE: index out of bounds: the len is 0 but the index is 0 | Here is the example code that I found: ```rust #![allow(incomplete_features)] #![feature(min_generic_const_args)] pub struct A; impl A { #[type_const] const LEN: usize = 4; #[allow(unused_braces)] fn arr() -> [u8; const { Self::LEN }] { return [0u8; const { Se | labels: I-ICE, T-compiler, C-bug, S-bug-has-test, F-associated_const_equality, F-min_generic_const_args


ICE: expected region but found Type | <!-- ICE: Rustc ./a.rs '-Zcrate-attr=feature(generic_const_exprs) -Zcrate-attr=feature(min_generic_const_args) -Zcrate-attr=feature(inherent_associated_types) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at /rustc/30f168ef811aec63124eac67 | labels: I-ICE, T-compiler, C-bug, F-generic_const_exprs, F-inherent_associated_types, S-bug-has-test


ICE: `expected type for param #0 in [N/#0]` | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, T-compiler, C-bug, F-min_generic_const_args


1.94 beta regression: "malformed `doc` attribute input" | The following errors are all the errors found in the 1.94 beta crater run that are related to the `doc` attribute. ## Error 1 ``` [INFO] [stdout] error[E0538]: malformed `doc` attribute input [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/index.crat | labels: A-attributes, P-high, T-lang, T-compiler, regression-from-stable-to-beta, C-bug


mGCA: consolidate type const checks on `tcx.is_type_const` | Under `feature(min_generic_const_args)` const items have been split into two, "const items" and "type const items". Type const items are written with the `#[type_const]` attribute applied to the syntax of a normal const item. In some places in the compiler we  | labels: E-easy, C-cleanup, E-mentor, T-compiler, A-const-generics, T-types


Unexpected result from recursive macro rule | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code: ```rust macro_rules! text_token { ("{%", $($token: literal,)*) => { println!("Found | labels: A-macros, C-bug, C-discussion, T-rust-analyzer


unmangled symbols are not escaped in naked/global assembly | I tried this code: ```rust unsafe extern "C" { #[link_name = "memset]; mov eax, 1; #"] unsafe fn inject(); } #[unsafe(export_name = "memset]; mov eax, 1; #")] extern "C" fn inject_() {} #[unsafe(naked)] extern "C" fn print_0() -> usize { core::arch::naked_asm! | labels: A-codegen, C-bug


#[derive(Clone, Copy)] doesn't work | I tried this code: ```rust use std::marker::PhantomData; #[derive(Clone, Copy)] pub struct TypedAddress<T>{ inner: u64, phantom: PhantomData<T>, } pub trait Memory { fn write_value<T>(&self, offset: TypedAddress<T>, value: &T); fn return_value<T>(&self, offset | labels: A-diagnostics, A-macros, T-compiler, A-suggestion-diagnostics, D-newcomer-roadblock


Performance regression with auto-vectorization from 1.87 onwards | ### Code I tried this code: ```rust pub fn unfilter_4(previous: &[u8], current: &mut [u8]) { let mut a_bpp = [0; 4]; let mut c_bpp = [0; 4]; for (chunk, b_bpp) in current.chunks_exact_mut(4).zip(previous.chunks_exact(4)) { let new_chunk = [ chunk[0].wrapping_a | labels: A-LLVM, T-compiler, regression-from-stable-to-stable, C-bug


[ICE]: Compiler panic while compiling ppc64le rust code in linux tree | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, T-compiler, O-PowerPC, C-bug


Tracking Issue for the Soundness Criterion | This is a tracking issue for the pre-RFC [Rust Safety Standard](https://internals.rust-lang.org/t/pre-rfc-rust-safety-standard/23963). Since there is a lack of actionable guidelines for unsafe usage, we are currently working on that. We have proposed several v | labels: C-discussion


Non-deterministic rmeta metadata ordering in rustc, continued, with fixes | This is a continuation of #151868 , which was locked for no good reason, and comments actually *removed*, again, for dubious reasons. Repro. script attached. [repro.sh](https://github.com/user-attachments/files/25086025/repro.sh) The prototype fix is broken in


Tracking Issue for `peekable_next_if_map` | Feature gate: `#![feature(peekable_next_if_map)]` This is a tracking issue for the `std::iter::Peekable::next_if_map{_mut}` functions, as a combination of `next_if()` and transformation in a single step (ACP: rust-lang/libs-team#613). ### Public API ```rust im | labels: T-libs-api, C-tracking-issue, disposition-merge, finished-final-comment-period, S-tracking-impl-incomplete


regression: "the parameter type `T` may not live long enough" in `offset_of!` | ``` [INFO] [stdout] error[E0310]: the parameter type `T` may not live long enough [INFO] [stdout] --> src/report/data.rs:310:24 [INFO] [stdout] | [INFO] [stdout] 310 | assert_eq!(offset_of!(ReportData<T>, vtable), 0); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^ | labels: P-medium, A-borrow-checker, regression-from-stable-to-beta, C-bug, finished-final-comment-period, disposition-close


Tracking Issue for AArch64 FEAT_JSCVT | The feature gate for the issue is `#![feature("stdarch_aarch64_jscvt")]`. # Public API This feature covers the intrinsic from the AArch64 `"jsconv"` target feature > Floating-point JavaScript convert to signed fixed-point, rounding toward zero ```rust #[target | labels: T-lang, T-libs-api, C-tracking-issue, disposition-merge, finished-final-comment-period, A-intrinsics


Tracking Issue for raw-pointer-to-reference conversion methods | <!-- 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 proc | labels: T-libs-api, C-tracking-issue, disposition-merge, finished-final-comment-period


Tracking issue for const `Pin` methods | Constify methods of `core::pin::Pin` under the feature `const_pin`. Implementation: #76655 Methods in `const_pin` (stable since 1.84.0 - https://github.com/rust-lang/rust/pull/130136): - `new` - `new_unchecked` - `get_ref` - `into_ref` - `get_mut` - `get_unche | labels: T-libs-api, A-const-eval, disposition-merge, finished-final-comment-period


ICE on nightly building futures-util | I encountered an internal compiler error when building `future-utils` on rust nightly (01/11). ### Reproduction ``` rustup toolchain install nightly git clone https://github.com/rust-lang/futures-rs.git cd futures-rs cargo +nightly doc ``` ### Meta Rust versio | labels: T-rustdoc, I-ICE, C-bug, A-intra-doc-links, regression-untriaged


ICE: pattern: `attempt to add with overflow` | <!-- ICE: Rustc ./A5635DBE231F0C3535BE7A41BE7846C6C6D75F86CAE0C9F78F9847A246403528.rs '' 'thread 'rustc' panicked at compiler/rustc_mir_build/src/thir/pattern/mod.rs:237:34: 'attempt to add with overflow'', 'thread 'rustc' panicked at compiler/rustc_mir_build/ | labels: A-diagnostics, I-ICE, E-needs-test, T-compiler, C-bug, S-has-mcve


Cannot build cdylib for wasm32-unknown-emscripten | Create an empty file `test.rs` and run ``` rustc -C link-args='-s SIDE_MODULE' --target wasm32-unknown-emscripten --crate-type cdylib test.rs ``` It gives the error ``` error: linking with `emcc` failed: exit code: 1 | = note: "emcc" "-s" "DISABLE_EXCEPTION_CA | labels: O-wasm, C-bug


Avoid monomorphizing intrinsic fallback bodies that the backend does not need | Currently, when an intrinsic with a fallback body gets used, we always monomorphize and codegen that body: mono item collection does not know whether the backend will invoke the fallback body or supply its own implementation. This has led to perf regressions i | labels: I-compiletime, T-compiler


De-stabilize target spec JSON | In a recent [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Stability.20guarantees.20of.20custom.20target.20specifications), it was noted that we currently consider JSON target specifications unstable, in the sense tha | labels: A-stability, T-compiler, A-target-specs, C-discussion


Current handling of Unix close() can lead to silent data loss | While working on #98209 , I went searching for where close() is called. I found it in std/src/os/fd/owned.rs: ``` impl Drop for OwnedFd { #[inline] fn drop(&mut self) { unsafe { // Note that errors are ignored when closing a file descriptor. The // reason for  | labels: T-libs-api, C-bug, A-io


ICE: `assertion failed: layout.is_sized()` with `feature(adt_const_params)` | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: E-easy, I-ICE, E-mentor, T-compiler, C-bug, F-adt_const_params


[ICE]: `Span must not be empty and have no suggestion` | <!-- ICE: Rustc ./a.rs '-Znext-solver=globally -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' ($TID) panicked at compiler/rustc_errors/src/diagnostic.rs:998:9: 'Span must not be empty and have no suggestion'', 'thread 'rustc' ($TID) panicked at comp | labels: A-diagnostics, I-ICE, T-compiler, C-bug, requires-debug-assertions, WG-trait-system-refactor


unreachable_pub lint false positive | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code: ```rust #![warn(unreachable_pub)] mod foo { pub struct Foo; } use foo::Foo; ``` [He | labels: A-lints, C-bug, L-unreachable_pub


Potential in-module UB in alloc | `HOOK` is a static variable: https://github.com/rust-lang/rust/blob/5ac8ecea36e7548534e0bc3d4aa1c12bd4908566/library/std/src/alloc.rs#L297 `rust_oom` transmutes a pointer `hook` obtained from HOOK into a function: https://github.com/rust-lang/rust/blob/5ac8ece | labels: C-bug, T-libs


Partial pointers in padding can make const-eval fail | I'm not sure if this is a bug or not. ```rust #![allow(unused)] #[repr(C, align(16))] #[derive(Clone, Copy)] struct Thing { x: u128, y: u64, // Replace the above line with the below line to make it stop compiling // y: std::mem::MaybeUninit<u64>, // 8 bytes of | labels: T-lang, T-compiler, C-bug, A-const-eval, A-ABI, T-opsem


[ICE]: assertion failed: layout.is_sized() | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, T-compiler, C-bug


[ICE]: generics_of: unexpected node kind Crate(Mod | <!-- ICE: Rustc ./18074FF2C0026A2CB1DAE74699BC86DCF7076BEED1E87DC391BFFFB43561B701.rs '-Zcrate-attr=feature(min_generic_const_args) -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: compiler/rustc_hir_analysis/src/collect/generics_of.r | labels: I-ICE, T-compiler, C-bug, F-min_generic_const_args


ICE: `span context mismatch` | <!-- ICE: Rustc ./meta-variable-misuse.rs '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' ($TID) panicked at compiler/rustc_mir_transform/src/coverage/spans.rs:56:13: 'span context mismatch: body_span=/tmp/im/meta-variable-misu | labels: I-ICE, T-compiler, C-bug, A-code-coverage, requires-debug-assertions


Deriving Default for non-default generics should work in trivial cases | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> ```rust struct NoDefault {} #[derive(Default)] struct VecHolder<T> { data: Vec<T>, } fn main() { let x | labels: C-bug


rustc `--color always` doesn't always output color | Zulip discussion: [#t-compiler > Rustc `--color always` doesn't always color output](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Rustc.20.60--color.20always.60.20doesn't.20always.20color.20output/with/568526766) While workin | labels: A-diagnostics, T-compiler, C-bug, D-inconsistent, A-error-codes


Miscompilation with vectors | I tried this code: ```rust use std::ops::{Add, Mul}; #[derive(Copy, Clone, Debug, Hash, PartialEq, Eq)] pub struct Vector2<S> { pub x: S, pub y: S, } impl<S> Add<Vector2<S>> for Vector2<S> where S: Add<Output = S> + Copy, { type Output = Vector2<S>; fn add(sel | labels: C-bug


ICE: `assertion failed: layout.is_sized()` with `feature(associated_const_equality)` | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, E-needs-test, T-compiler, C-bug, A-layout, F-associated_const_equality


diagnostic::do_not_recommend can emit an error if it encounters a keyword | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code: ```rust #![crate_type = "lib"] pub trait X{} pub struct Y; #[diagnostic::do_not_rec | labels: A-attributes, T-compiler, C-bug


Missing "unused variable" warning when using a match guard | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code: ```rust fn main() { match Some(42) { Some(unused) if true => (), _ => (), } } ``` I | labels: A-lints, P-medium, T-compiler, regression-from-stable-to-stable, C-bug, L-unused_variables


Function no longer auto-vectorizes in 1.87.0 | <!-- Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --> ### | labels: A-LLVM, I-slow, E-needs-test, P-high, T-compiler, regression-from-stable-to-stable


Tracking Issue for bigint helper methods | <!-- 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 proc | labels: T-libs-api, C-tracking-issue


[ICE]: ` all spans must be disjoint` | <!-- ICE: Rustc ./a.rs '' 'assertion `left == right` failed: all spans must be disjoint ' left: Some([SubstitutionPart { span: /tmp/im/2/a.rs:5:13: 5:16 (#0), snippet: "" }, SubstitutionPart { span: /tmp/im/2/a.rs:5:15: 5:16 (#0), snippet: "/* e */" } | labels: A-diagnostics, I-ICE, T-compiler, C-bug, requires-debug-assertions


Rust 1.90 compiler optimization (O2, O3) triggers UB with Box::from_raw() | ### Code I minimized the issue to the following testcase, which uses serde and `bincode` to serialize a structure by boxing it, serializing the exposed address and reconstructs the box from the deserialized address. I believe this to be valid, as long as one c | labels: A-LLVM, P-medium, T-compiler, regression-from-stable-to-stable, C-bug, T-opsem


Alarming memory use and non-termination. | I cloned the [rust serialization benchmark repository](https://github.com/djkoloski/rust_serialization_benchmark/), which I have been able to `cargo bench`. I made a modification, to use a local checkout of the `columnar` crate, with this diff ``` mcsherry@gal | labels: A-LLVM, I-compiletime, P-high, T-compiler, regression-from-stable-to-stable, C-bug


rustdoc should have some indication of hidden bounds | If you look at <https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#impl-Iterator-for-RangeInclusive%3CA%3E>, for example, it appears as though `RangeInclusive<A>: Iterator` holds *for all `A`*. That's not the case, however, because there's a  | labels: T-rustdoc, C-bug


`if let` not possible in short-hand syntax? | labels: A-diagnostics, C-discussion


Possible AVX2-only performance regression (again). | Hello! Seems I can reproduce a **very similar AVX2-only performance regression** (stable-to-stable) to the one described in the `image-png` issue here: - https://github.com/image-rs/image-png/issues/598 ## Repository / code - Repo: https://github.com/sherman/b | labels: C-bug, regression-untriaged, perf-regression


[ICE]: `expected Binder to have 1 projections, but it has 0` | <!-- ICE: Rustc ./dyn-compat-self-const-projections-in-methods.rs '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -Cunsafe-allow-abi-mismatch=sanitizer -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' ($TID) panicked at compiler/rustc_middle/src/ty/sty.rs:73 | labels: I-ICE, T-compiler, C-bug, requires-debug-assertions, F-min_generic_const_args, A-control-flow-integrity


[ICE]: `expected a projection` | <!-- ICE: Rustc ./DC87D749F7189DB6749EB7B0F246583DCA01BDEC0317D86213F29E3CDF421FE8.rs '-Znext-solver=globally -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' ($TID) panicked at compiler/rustc_type_ir/src/predicate.rs:689:9: 'expected a projection'',  | labels: I-ICE, T-compiler, C-bug, F-type_alias_impl_trait, S-has-mcve, WG-trait-system-refactor


ICE：called `Result::unwrap()` on an `Err` value: ReferencesError(ErrorGuaranteed(())) | **Similar to problem #128094, it may be a duplicate problem, but the compile command is different The issue compilation command I opened is `-C opt-level=1`, and #128094 is `-Zmir-opt-level=5 --edition=2018`** And the code is a little different, so I brought u | labels: I-ICE, E-needs-test, T-compiler, C-bug, A-mir-opt


Sorting Boxes causes Miri to report UB | This issue was discovered by @orxfun on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/miri.20fails.20when.20sorting.20slice.20of.20boxed.20integers/with/570245641). The following code causes Miri to report UB: ```rust fn main() { // | labels: P-high, regression-from-stable-to-stable, I-unsound, C-bug, T-libs, T-opsem


[ICE]: Latest rust cannot build ans1-rs | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: I-ICE, T-compiler, C-bug


Non-deterministic rmeta metadata ordering in rustc 1.95.0-nightly | # Non-deterministic rmeta metadata ordering persists in rustc 1.95.0-nightly ## Summary Building the same crate twice with identical inputs produces `.rlib` files with different hashes due to non-deterministic ordering in `lib.rmeta`. The compiled object code  | labels: T-compiler, C-bug, S-needs-repro


Document FAQ why we have both PartialEq and Eq in PartialEq | The title says it all. It's a frequently asked question; most recently on [reddit](https://www.reddit.com/r/rust/comments/t8d6wb/why_does_rust_have_eq_and_partialeq/). It'd be nice if we could link to the standard library docs to answer this. | labels: A-docs, T-libs


unused_allocation warning should ignore allocations to pass Box to things taking self: &Box | ### Code ```Rust // Copyright 2026 Google LLC. // SPDX-License-Identifier: Apache-2.0 struct MyStruct; trait TraitTakesBoxRef { fn trait_takes_box_ref(&self); } impl TraitTakesBoxRef for Box<MyStruct> { fn trait_takes_box_ref(&self) {} } impl MyStruct { fn inh | labels: A-diagnostics, T-compiler, L-unused_allocation


[ICE]: frontmatter: begin <= end (4 <= 0) when slicing `----` | <!-- ICE: Rustc ./code.rs '' 'thread 'rustc' ($TID) panicked at compiler/rustc_parse/src/lexer/mod.rs:628:30: 'begin <= end (4 <= 0) when slicing `----`'', 'thread 'rustc' ($TID) panicked at compiler/rustc_parse/src/lexer/mod.rs:628:30: 'begin <= end  | labels: I-ICE, T-compiler, C-bug, S-has-mcve, F-frontmatter


Tracking Issue for AArch64 TME intrinsics | <!-- 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 proc | labels: T-libs-api, C-tracking-issue, O-AArch64


rust 1.90.0, 1.91.0 and 1.92.0 on big-endian aarch64 all fail with "internal error: entered unreachable code: found `99`" | As mentioned in issue #145230, rust 1.90.0 can now be cross-built for the `aarch64_be-unknown-netbsd` target. However, trying to use the result to build e.g. `dua-cli` (ref. https://github.com/Byron/dua-cli/), fails on the first invocation of the rust compiler | labels: I-ICE, T-compiler, C-bug, A-targets, E-needs-investigation


-Znext-solver=coherence: stack overflow | <!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-pat | labels: T-compiler, C-bug, I-hang, WG-trait-system-refactor


Unstable fingerprints in `evaluate_obligation` | ### Code https://github.com/Noratrieb/evaluate_obligation-fingerprints All credits for running into this and creating an initial reproduction and minimization goes to @muja via the Rust Community Discord, I just picked it up and continued minimizing it. This i | labels: I-ICE, T-compiler, A-incr-comp, C-bug


checksum-freshness: does not work with binary embedded files | <!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> I tried this code with `-Zchecksum-freshness` enabled on cargo side: ```rust // random_bytes have to b | labels: T-compiler, C-bug


Failure when compiling rustc due to file permissions in /usr | ### Summary I'm compiling rustc in an openSUSE docker container. When running `make` I very quickly get an error because it's trying to copy `/usr` to `stage0-sysroot`. The file in question is this one: ```sh -rwsr-x--- 1 root messagebus 56K Jun 20 2023 /usr/l | labels: T-bootstrap, C-bug


ICE "not a type parameter" on nightly (regression) | Repro: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c4a8f90dada13368b5749e84b7b01108 ```rust pub type PrivacyPolicy<E> = Vec<Box<dyn PrivacyRule<ViewerContext = Self::ViewerContext, Id = Self::Id, Err = E>>>; pub trait PrivacyRule { type ViewerContext; | labels: I-ICE, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


GAT cannot infer implicit lifetime bounds. | I'm trying to simulate closures returning mutable captured variable with GAT-version `FnMut`. It cannot infer implicit bound `'a: 'r` here and emit an error. But there is `self: &'r mut Self` alive while `Self` contains `&'a mut i32`. ```rust #![feature(generic_associated_types)] | labels: A-lifetimes, I-ICE, A-associated-items, T-compiler, A-NLL, C-bug


Exempt Miri from "no tools breakage the week before beta cutoff"? | Would it make sense to exempt Miri from the rule that tools must not regress the week before the beta is branched? Miri is anyway not distributed with the beta, it's a nightly-only tool. And this "no breakage" rule makes landing PRs during that timeframe very painful. Cc @rust-la | labels: T-infra, A-miri


error[E0432]: unresolved import `std::sync::atomic::AtomicU64` | https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:Factory/rust/p/ppc Dist RLS stage2 (powerpc-unknown-linux-gnu) Building stage2 tool clippy-driver (powerpc-unknown-linux-gnu) Finished release [optimized] target(s) in 0.59s Building stage2 tool rls (powerpc-un | labels: A-codegen, A-resolve, T-compiler, O-PowerPC, C-bug


Unconditionally breaking `loop`s not allowed in constants. | *Technically* a regression from 1.24 to 1.25, but I don't think anyone used this. Example code which used to be allowed: ```rust pub const FOO: () = loop { break; }; ``` I'm pretty sure this changed with #47802, which added the `FalseUnwind` terminator to MIR, but didn't handle i | labels: A-MIR, regression-from-stable-to-stable, A-const-eval


Initialization by assignment not allowed for "drop-ful" types in constants. | In the following example, `FOO` and `ASSIGN` are allowed but `FOO_ASSIGN` isn't: ```rust pub struct Foo; impl Drop for Foo { fn drop(&mut self) {} } pub const FOO: Foo = { let x = Foo; x }; pub const ASSIGN: i32 = { let x; x = 0; x }; pub const FOO_ASSIGN: Foo = { let x; x = Foo; | labels: T-compiler, A-MIR, C-bug, A-const-eval


DOS Line Endings in install.sh on some rust-std nightlies | Since the change from travis to azure pipelines some of the rust-std archives have DOS line endings in their `install.sh` script, which results in errors like the following when trying to execute: ``` # ./install.sh bash: ./install.sh: /bin/bash^M: bad interpreter: No such file o | labels: P-high, regression-from-stable-to-beta, T-infra, C-bug


Move `compile-pass` tests to `check-pass` or `build-pass` | `compile-pass` was the old way to assert that UI tests were able to successfully build. However, it would do a full build of the code, including codegen and linking. Many of our tests don't need this, however, and should instead use the new `check-pass`, introduced in https://git | labels: C-cleanup, A-testsuite, E-mentor, T-compiler, E-medium, A-compiletest


Tracking issue for `slice_take` | Feature gate: `#![feature(slice_take)]` ### Public API ```rust impl<T> [T] { fn split_off<'a, R: OneSidedRange<usize>>(self: &mut &'a Self, range: R) -> Option<&'a Self>; fn split_off_mut<'a, R: OneSidedRange<usize>>(self: &mut &'a mut Self, range: R) -> Option<&'a mut Self>; fn  | labels: T-libs-api, C-tracking-issue, disposition-merge, finished-final-comment-period, A-slice


Box::into_pin is unstable but has #0 as the tracking issue | Please see https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#method.into_pin : ![screenshot](https://cdn.discordapp.com/attachments/273541522815713281/595422844398075919/unknown.png) | labels: T-libs-api, C-bug


Leak when returning out of box syntax | @nils-ohlmeier mentioned a leak coming from `vec![f()?]` but not `vec![f()?; 1]` [here](https://github.com/mozilla/webrtc-sdp/blob/master/src/attribute_type.rs#L2158-L2160), I think I tracked this down to the use of `box` in `vec!` when given a comma-separated list. I've made [a  | labels: T-compiler, A-MIR, C-bug


There's a bug when you multiply two Numbers | use std::ops::Mul; amount is 2224.0001_f64 my result=== amount_clone.mul(10000.0)=22240001.000000004----amount_clone.mul(10000.0).floor()=22240001 my code== println!("amount_clone.mul(10000.0)={}----amount_clone.mul(10000.0).floor()={}",amount_clone.mul(10000.0),amount_clone.mul(


1.36 changes the `UnwindSafe` impl precondition for HashMap | https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0e5a528fc978a90aa15bbf01f68dd1bf ```rust assert_unwind_safe::<HashMap<(), UnsafeCell<()>>>(); ``` Successfully compiles on stable 1.35, fails on beta/pre 1.36. | labels: A-collections, T-libs-api, regression-from-stable-to-beta, C-bug


provide thread name to OS for Solarish systems | Both Solaris 11 and recentish Illumos provide the same `pthread_setname_np()` API. While libstd can't presume the existence of the symbol, it seems like using `weak!` works sufficiently to set the thread name when necessary. While the implementation is different, the API is basic | labels: T-libs-api, O-solaris


Any trait should be unsafe | ## What is wrong? Since `type_id()` is stable rust programs rely on `Any` to be implemented correctly for rust safety relevant thinks (like downcast). Given the coding guide lines `Any` needs to be a `unsafe`-to-implement trait as implementing it wrongly causes unsafety. ## Is it | labels: A-DSTs, T-lang, T-libs-api, C-bug


Nightly compiler panic on using Self with associated type in type alias | ## Description The `nightly` compiler panics when using `Self` in a type alias along with an associated type. This does not happen on `stable` or `beta`. Code snippet: ``` type Target = Self::Target; ``` [Playground Link](https://play.rust-lang.org/?version=nightly&mode=debug&edi | labels: regression-from-stable-to-nightly, A-associated-items, P-high, T-compiler, C-bug


structural_match bug:  deep refs like `& &B` leak use of PartialEq | (Spawned off of investigation of #61188) rust-lang/rfcs#1445 says that we're supposed to reject uses of consts with ADT's that don't implement `#[structural_match]` (i.e. ADT's that do not do `#[derive(PartialEq, Eq)]`. Unfortunately, we did not quite finish the job. Consider the | labels: T-compiler, C-bug


libstd requires explicit version of rand crate | Most everything else in the rustc repo that needs the rand crate is specifying "0.6" for the version, while libstd has "0.6.1" in its Cargo.toml. Unfortunately, this prevented rust from building on illumos systems without manually patching the rand crate (and is a blocker for rus | labels: C-enhancement, T-libs-api


Future compat warning with `.await`ing a `BoxFuture` | The code is the same as in https://github.com/rust-lang/rust/issues/62284: ```rust #![feature(async_await)] use std::future::Future; use std::pin::Pin; type BoxFuture = Pin<Box<dyn Future<Output = ()>>>; async fn foo() -> BoxFuture { Box::pin(bar()) as _ } async fn bar() { let _  | labels: P-high, T-compiler, A-MIR, I-unsound, C-bug, A-async-await


Conflicting documentation on the alignment requirements for `ptr::copy` | The docs for [`ptr::drop_in_place`](https://doc.rust-lang.org/nightly/std/ptr/fn.drop_in_place.html) state: > Unaligned values cannot be dropped in place, they must be copied to an aligned location first: And include an example which uses `ptr::copy` to copy the value from an una | labels: T-lang, T-libs-api, A-docs, C-bug


stdlib incorrectly handles O_PATH | There are several bugs here, but they all stem from the same problem -- the stdlib doesn't handle `O_PATH` correctly in a few places. ## `O_PATH` requires you to set an extra (unused) mode. ## `O_PATH` causes most other flags to be ignored, so requiring a mode is a little bit wei


Use DataflowResultsCursor instead of FlowAtLocation | #61922 introduced `DataflowResultsCursor`, which provides a stateful caching interface atop `FlowAtLocation`. It would be better to use `DataflowResultsCursor` from more places, both because it's a more convenient / less error-prone interface, and because it's best to have more t | labels: C-cleanup, T-compiler, A-MIR


Support panic=abort without #[should_panic] from libtest | When a project wants to turn on `panic=abort` today, they are forced to choose between 1. Re-compiling their whole project with `panic=unwind` for the purpose of running tests (this not only creates longer build times, but also changes the behavior of code between testing and pro | labels: T-lang, T-compiler, T-dev-tools, C-feature-request, A-libtest


$crate incorrectly substituted in attribute macro invocation containing bang macro invocation | When an attribute macro input contains `$ident`, it is correctly substituted both inside and outside of a function-like macro invocation i.e. both of the $ident's in `[u8; $ident + m!($ident)]` would be substituted as expected. But when an attribute macro input contains `$crate`, | labels: A-macros, T-compiler, C-bug


ICE with generic associated types | Hi, Following code: ```rust #![feature(generic_associated_types)] trait Iterator { type Item<'a>: 'a; } ``` ... fails with: ``` error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=None) (index=1) thread 'rustc' panicked at 'no e | labels: A-lifetimes, I-ICE, A-associated-items, T-compiler, C-bug, F-generic_associated_types


Increasing Rc::strong_count above u8::MAX causes alignment issues and segfault in FFI code | ```console $ rustc --version --verbose rustc 1.37.0-nightly (d132f544f 2019-06-07) binary: rustc commit-hash: d132f544f9d74e3cc047ef211e57eae60b78e5c5 commit-date: 2019-06-07 host: x86_64-apple-darwin release: 1.37.0-nightly LLVM version: 8.0 ``` The following program segfaults i | labels: A-FFI, T-libs-api


Change "A non-empty glob must import something with the glob's visibility" to be a lint? | Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the `bar` in B) may br | labels: E-easy, A-lints, A-resolve, E-mentor, T-lang


wart: non-Eq [T; 0] can be matched as if T were `#[structural_match]` | Spawned off of investigation of issue #62307 and PR #55837 We currently allow constants that are empty arrays of any type to be used as patterns in `match`. We allow this regardless of whether they are an array of an ADT that does not derive `PartialEq`/`Eq` This may be a feature | labels: T-lang, A-patterns, A-ZST, A-array


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


library compilation problem on s390x | I'm getting the following error when building `Parity Ethereum`: ``` LLVM ERROR: Cannot select: 0x3ff58cd1598: i32 = SystemZISD::GET_CCMASK 0x3ff58cd13f8, Constant:i32<15>, Constant:i32<3> 0x3ff58cd13f8: i32 = srl 0x3ff58a47040, Constant:i32<31> 0x3ff58a47040: i32 = add 0x3ff58cd | labels: A-LLVM, T-compiler, C-bug, O-SystemZ


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


const fns have no documentation | `const` functions seems to be an entirely undocumented language feature. As far as I can see, it's not mentioned anywhere in book or the reference. Judging by the release notes, they've been in the language since before 1.33, so it seems to just have been forgotten? | labels: A-docs, A-const-eval


FFI broken with many parameters | We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: https://github.com/aosmond/myrustffi It is a very simple test ca | labels: A-codegen, A-FFI, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable


ICE: `rustc` crashes in a `chroot` sandbox | This error happens when running `cargo` from `bazel`, which is in turn running in a `chroot` sandbox on Centos 7. Running with `RUST_BACKTRACE=1` unfortunately makes the error disappear, so we don't know why `rustc` needs to read `/proc/self/exe` and why only when compiling DD. T | labels: I-ICE, P-medium, T-compiler, C-bug


Add valid examples to `std::ptr::{read,write}_unaligned` | With https://github.com/rust-lang/rust/pull/62323 the only example (that had UB and was thus invalid) in `std::ptr::read_unaligned` and `std::ptr::write_unaligned` is removed. We should add a valid example of using the aforementioned functions. cc @rust-lang/wg-unsafe-code-guidel | labels: E-easy, C-enhancement, A-docs


Tracking issue for `Option::contains` and `Result::contains` | This is a tracking issue for `Option::contains` and `Result::contains`. The implementations are as follows: ```rust pub fn contains(&self, x: &T) -> bool where T: PartialEq { match self { Some(y) => y == x, None => false, } } pub fn contains(&self, x: &T) -> bool where T: Partial | labels: T-libs-api, B-unstable, C-tracking-issue, finished-final-comment-period, disposition-close, A-result-option


compiler optimized out function call which has side effects ? | I found following code ```rst TcpListener::bind("127.0.0.1:1234"); std::thread::sleep_ms(99999999); ``` didn't listen during running, but if I change it to ```rst let _s=TcpListener::bind("127.0.0.1:1234"); std::thread::sleep_ms(99999999); ``` it listened as expected, is this a b


`miri` no longer builds after rust-lang/rust#62355 | Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#62355, 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 on self-referential typedef | So, while writing some _really nasty_ code for an interpreter, I ended up with an overcomplicated version of this code: ```rust use std::sync::Arc; pub enum ThingOrRef<S> where S: AsRef<Self> { ThingRef(S), Thing } pub type ThingArena<'ctx, T> = ThingOrRef<Arc<Self>>; ``` ([Playg | labels: I-ICE, regression-from-stable-to-nightly, P-high, T-compiler


Tracking issue for Box::into_pin (feature `box_into_pin`) | This is a tracking issue for `Box::into_pin` implemented in https://github.com/rust-lang/rust/pull/57313 ```rust impl<T: ?Sized> Box<T> { pub fn into_pin(boxed: Box<T>) -> Pin<Box<T>>; } ``` | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, Libs-Tracked


Improve diagnostics on self types in function signature | ```rust struct A; impl A { fn foo(self: Box<Self>) {} } fn main() { A.foo() } ``` gives ```text error[E0599]: no method named `foo` found for type `A` in the current scope --> src/main.rs:8:7 | 1 | struct A; | --------- method `foo` not found for this ... 8 | A.foo() | ^^^ ``` Wh | labels: C-enhancement, A-diagnostics, A-trait-system, T-compiler


Internal compiler error with enums | Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: ``` struct TypeA { attr: String, attr2: usize, } struct TypeB { attr: usize, attr2: Vec<String>, } enum En { Value(TypeA), OtherValue(TypeB), None } fn main() | labels: I-ICE, E-needs-test, T-compiler, C-bug


Unhelpful span in async type inference error | The following snippet [(playground)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=1af2816e9147c55126a2658e46f1453e): ```rust #![feature(async_await)] use std::future::Future; fn get_future() -> impl Future<Output = ()> { panic!() } async fn foo() { let | labels: C-enhancement, A-diagnostics, T-compiler, A-inference, A-async-await


Invalid suggestion when attempting to call async closure | The following snippet: ```rust #![feature(async_await)] fn main() { async || ({ })(); } ``` produces the following error: ``` error[E0618]: expected function, found `()` --> src/main.rs:4:14 | 4 | async || ({ | ______________^ | |______________| | || 5 | || })(); | ||______^_- ca | labels: A-closures, T-compiler, C-bug, A-async-await, A-suggestion-diagnostics, AsyncAwait-Triaged


diagnostics: suggest iter_mut() where trying to modify .iter()'ed vector elements inplace | code: ````rust #[derive(Debug)] struct A { a: i32, } impl A { fn double(&mut self) { self.a += self.a } } fn main() { let mut v = [A { a: 4 }]; v.iter().for_each(|a| a.double()); println!("{:?}", v); } ```` The code gives the following not-very-helpful warning: ```` error[E0596]: | labels: C-enhancement, A-diagnostics, T-compiler, D-newcomer-roadblock


Crater runs for Rust 1.37.0 | labels: S-waiting-on-review


future doc in doc.rs still use await! | it supposed to be .await? https://doc.rust-lang.org/std/future/trait.Future.html > The core method of future, poll, attempts to resolve the future into a final value. This method does not block if the value is not ready. Instead, the current task is scheduled to be woken up when


Const generics with function pointers produces linker error. | When attempting to compile a program using const generic function pointers, I get the following linker error: ``` error: linking with `cc` failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/root/.rustup/toolchains/nightly-x86_64-unknown-linux | labels: A-linkage, T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


Get rid of uses of mem::uninitialized | https://github.com/rust-lang/rust/commit/007d87f1719e2fcf2ff36aef8b6dc866fa276386 added a bunch of `allow(deprecated)` because there are still a few places where we use `mem::uninitialized`. These should all be fixed, to remove the `allow` (and hopefully prevent other deprecated  | labels: T-libs-api


Confusing diagnostic for lifetime mismatch | This [came up on StackOverflow](https://stackoverflow.com/q/56897524) today. In reduced form, this function ```rust fn foo<T>(x: &mut &mut T) { *x = *x; } ``` results in this error message ``` error[E0623]: lifetime mismatch --> src/lib.rs:2:10 | 1 | fn foo<T>(x: &mut &mut T) { | | labels: C-enhancement, A-diagnostics, A-lifetimes, T-compiler, A-NLL, fixed-by-NLL


Group all ABI tests. | There are a bunch of run-pass tests that should be in `run-pass/abi` (or some other directory if anyone has a better suggestion), and many of them are mentioned here: https://github.com/rust-lang/rust/blob/baab1914ec9a9742776a8147780947b48fddf54d/src/test/run-pass/abi-sysv64-arg- | labels: E-easy, C-cleanup, A-testsuite, E-mentor, T-compiler


`x.py build --warnings deny` does not fail despite warnings | I patched libstd and wanted to be sure it builds without warnings, so I did: ``` $ ./x.py build --stage 0 src/libstd --warnings deny ``` However, this build succeeded despite there being warnings: ``` Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux | labels: T-compiler, T-bootstrap


Tracking issue for `indirect_structural_match` compatibility lint | This is the **summary issue** for the `indirect_structural_match` future-compatibility warning and other related errors. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or regist | labels: C-future-incompatibility, A-maybe-future-edition


Panic in <rustc_mir::monomorphize::item::InstantiationMode as core::fmt::Debug>::fmt | Got this error when running `cargo build`: ``` thread 'rustc' panicked at 'no entry found for key', src\libcore\option.rs:1034:5 stack backtrace: 0: std::sys_common::alloc::realloc_fallback 1: std::panicking::take_hook 2: std::panicking::take_hook 3: rustc::ty::structural_impls:: | labels: I-ICE, T-compiler, A-MIR, A-incr-comp, C-bug, E-needs-mcve


Random lines of code(?) printed into azure logs | Some sample logs: * https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_apis/build/builds/2418/logs/166 has: ``` 2019-07-05T01:49:34.1238250Z r? @matthewjasper 2019-07-05T01:49:34.1238312Z ```rust ``` ``` 2019-07-05T01:49:34.1237351Z match DropTemps($cond) { ``` | labels: P-low, T-infra


Document whether dereferencing a raw pointer requires alignment | I am referring to the following operation, built into the language: ```rust let x: *const u32 = unimplemented!(); unsafe { *x } ``` I checked all over: The [pointer primitive docs](https://doc.rust-lang.org/std/primitive.pointer.html) don't mention alignment. The [`std::ptr` modu | labels: A-docs


align_offset guarantees | The [documentation for `align_offset`](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.align_offset) says > If it is not possible to align the pointer, the implementation returns usize::max_value(). It does not give any details of when it might not be possible | labels: T-lang, T-libs-api, A-const-eval, A-miri


Cleanup: Consistently use `Param` instead of `Arg` | For example, ideally [`fn visit_arg`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/trait.Visitor.html#method.visit_arm) would be named `fn visit_param` since this is about formal parameters (in function signatures and from the POV inside the function body) instead | labels: A-frontend, E-easy, C-cleanup, A-attributes, A-parser, T-compiler


Derive Copy/Clone on generic Union working incorrectly. | The following code reports an error about the value being moved: ``` use std::marker::PhantomData; trait Foo {} struct Bar {} impl Foo for Bar {} #[derive(Copy, Clone)] union U<T> where T: Foo { value1: u32, value2: *const (), phantom: PhantomData<*const T> } fn test() { let a: U


ICE: Rust spins when referencing associated types in `where` clause | The following code broke the the text editor I was editing it in: ## Version rustc 1.35.0 (3c235d560 2019-05-20) ## Minimal test case: ```rust struct MyStruct<'a, 'b, A, B, F>(F, &'a A, &'b B); trait MyTrait { type Input; type Output; } trait MyOtherTrait<A, B> {}; impl<'a, 'b, A | labels: A-parser, P-medium, T-compiler, regression-from-stable-to-stable, I-compilemem, C-bug


Something weird with const generic resolution in macro_rules | This works, so const generic resolution works through macros (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e93e583bc759379eae9dac80ed011361) ```rust #![feature(const_generics)] trait Foo {} struct Bar<T, const N: usize>(T); trait Qux<const N: usize> {} | labels: A-resolve, T-compiler, C-bug, A-const-generics


1.65x performance regression from 1.35.0 to 1.36.0 | Seeing ~2x (46ms vs 28ms) performance regression after updating 1.35.0 to 1.36.0 (probably due to new HashMap implementation?). **Steps to reproduce** 1. Clone this repo: https://github.com/utter-step/advent-2018 2. `rustup override set 1.35.0 && cargo build -p day-6 --release` 3 | labels: I-slow, T-compiler, regression-from-stable-to-stable, T-libs


Size of `fn` can be either 8 or 0 | There is a discrepancy on the size of a `fn`, depending on if you treat it generically or not: ``` fn foo() { } fn main() { generic(foo); function(foo); } fn generic<F>(f: F) { println!("value: {}", std::mem::size_of_val(&f)); // 0 println!("type: {}", std::mem::size_of::<F>());  | labels: T-lang


typo in `core::arch::x86_64::_mm_add_epi64` formatting | <https://doc.rust-lang.org/core/arch/x86_64/fn._mm_add_epi64.html> The `b` var is written with an opening double quote instead of an opening backtick.


ICE: index out of bounds with const generics | https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4011d663cd9929c5ab2319beda510a6a ```rust #![feature(const_generics)] use std::fmt; struct Builder<const N: usize> { items: [&'static str; N], } fn new_builder() -> Builder<{0}> { return Builder{items: []}; } | labels: I-ICE, T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


Increase the arity of tuple with automatic implementation of std traits | Currently up to 12-ary tuple have common traits implemented (PartialEq, Eq, ...). (see https://github.com/rust-lang/rust/blob/master/src/libcore/tuple.rs) In my case, I need to have more than that (I currently use 32, but it may be more). In the end, I expect the tuple to have th | labels: T-lang, C-feature-request


Automatically add crate to workspace with `cargo new` | I think it would make sense if there was a flag to `cargo new` such as `--workspace` that would add the new crate to the workspace. There is already workspace detection: ``` ~/rust-comp master $ cargo new --lib abc warning: compiling this new crate may not work due to invalid wor


Internal compiler error with labeled break inside closure | **Toolchain version**: rustc 1.38.0-nightly (dfd52ba6a 2019-07-06) The following code produces internal compiler error ```rust #![feature(label_break_value)] fn main() { let a = 'a: { let a = |x: i32| break 'a; 1 }; } ``` <details><summary>backtrace</summary> <p> ``` thread 'rust | labels: A-type-system, I-ICE, P-medium, A-closures, T-compiler, C-bug


Tracking issue for debug_map_key_value | This is a tracking issue for `debug_map_key_value` (https://github.com/rust-lang/rfcs/pull/2696) **Steps:** - [x] Implement the RFC (#60458) - [x] Adjust documentation ([see instructions on rustc-guide][doc-guide]) - [x] Stabilization PR ([see instructions on rustc-guide][stabili | labels: B-RFC-approved, T-libs-api, B-RFC-implemented, C-tracking-issue


The total Rust archive size has intensified recently | **Edit**: > I forgot that with nightly, I also installed clippy, rustfmt, musl target. > The new edit will not contains those. The total Rust archive size has intensified recently. ```console % rustc +nightly-2019-07-07-x86_64-unknown-linux-gnu -V rustc 1.38.0-nightly (dfd52ba6a  | labels: T-compiler, I-heavy


typo in `core::arch::x86_64::_mm_prefetch` | > * _MM_HINT_T0: Fetch into all levels of the cache hierachy. Should be `hierarchy`


`core::arch::x86_64::_mm_shuffle_ps` input doesn't match official docs | [x86_64::_mm_shuffle_ps](https://doc.rust-lang.org/core/arch/x86_64/fn._mm_shuffle_ps.html) (and by extension [x86::_mm_shuffle_ps](https://doc.rust-lang.org/core/arch/x86/fn._mm_shuffle_ps.html)) have `i32` as the mask type, but the [intel intrinsics guide](https://software.inte | labels: E-easy, T-libs-api, T-compiler, A-docs, A-intrinsics


Doc: issue about const_generic_impls_guard link return 404 | The issue link (https://github.com/rust-lang/rust/issues/0) in std doc page https://doc.rust-lang.org/nightly/std/array/trait.LengthAtMost32.html returns 404. Is this issue number mistaken? I suppose that the No.0 issue of rust is talking about const generics is a little ridiculo


install.sh miplaces codegen-backends directory with libdir = "/lib/something" | opening here for visibility original issue here https://github.com/rust-lang/rust-installer/issues/93 if someone passes `libdir = "lib/rust-1.x.x"` via config.toml install.sh misplaces codegen-backends directory, because `/lib` path is treated as a special case. this code here at | labels: T-bootstrap, C-bug


rustdoc: Trait methods with default implementations are never hidden | ## Background Rustdoc currently hides implementated trait methods behind a _"Show hidden undocumented items"_ switch, unless a new doc comment was supplied on the method implementation. For example, consider this code: ```rust pub trait Test { /// This trait method does X... fn f | labels: T-rustdoc


move async unsafe fn to distinct feature gate | Per @Centril's [comment](https://github.com/rust-lang/rust/issues/62149#issuecomment-508947381), we want to move `async unsafe fn` to its own feature gate: > I would also like to move `async unsafe fn` out of the MVP into its own feature gate because I think a) it has seen little | labels: E-easy, E-mentor, T-compiler, A-async-await, AsyncAwait-Polish


Tracking issue for `#!feature(async_unsafe)]` (RFC 2394) | This is a tracking issue for `#![feature(async_unsafe)]` (rust-lang/rfcs#2394). The feature gate provides the `async unsafe fn` syntax. **Steps:** - [ ] Split the feature gate (https://github.com/rust-lang/rust/issues/62500) - [ ] Adjust documentation ([see instructions on rustc- | labels: A-frontend, T-lang, B-unstable, B-RFC-implemented, C-tracking-issue, A-async-await


Consider moving std::error::Error to `alloc` | Now that `alloc` is stable, this is a somewhat visible omission from `no_std` contexts. In practice, it being in `std` means that library crates that would otherwise be `no_std` (+ `alloc`) compatible which expose some sort of error type have to either: 1. Skip implementing `std: | labels: T-libs-api


ICE (const generics) with const generics in trait | ```rust #![feature(const_generics)] trait HasSize { const SIZE: usize; } impl<const X: usize> HasSize for ArrayHolder<{X}> { const SIZE: usize = X; } struct ArrayHolder<const X: usize>([u32; X]); impl<const X: usize> ArrayHolder<{X}> { pub const fn new() -> Self { ArrayHolder([0; | labels: I-ICE, E-needs-test, T-compiler, C-bug, A-const-generics, requires-nightly


ICE on generator type check with a must_use type | ICE is happening on code that awaits a future that has a `Output` type that is `must_use`. Original code: ```rust // src/transport/mod.rs pub trait Broadcast { type Error: std::error::Error; type Future: Future<Output = Vec<Result<Response, Self::Error>>> + Unpin; fn broadcast(&m | labels: I-ICE, T-compiler, A-async-await, AsyncAwait-Polish


libstd: Drop RHEL 5 support, Increase Minimum kernel version to 2.6.27 | The docs currently claim that the minimum Linux kernel version for `libstd` is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for `libstd`, or should we i | labels: C-cleanup, O-linux, T-libs-api


async fn with elided lifetime causes rustc panic | Code to reproduce: ```rust use futures::Stream; use std::any::Any; async fn foo(x: &str) -> impl Stream<Item = Box<dyn Any>> {} ``` and then run `cargo check`... (with full backtrace) ``` thread 'rustc' panicked at 'assertion failed: !erased_self_ty.has_escaping_bound_vars()', sr | labels: I-ICE, P-high, T-compiler, C-bug, A-async-await, AsyncAwait-Polish


lifetime-parametric GATs cause ICEs (with feature(generic_associated_types)) | Many people playing with `#[feature(generic_associated_types)]` have noticed that they break very easily when you attempt to use a lifetime formal parameter. Examples follow ## ICE: Region parameter out of range #62326 ([play](https://play.rust-lang.org/?version=nightly&mode=debu | labels: A-lifetimes, I-ICE, P-medium, A-associated-items, T-compiler, C-bug


Is Rc’s and Arc’s data_offset correct? | In the implementation of `Arc`, we find: https://github.com/rust-lang/rust/blob/09ab31bc64f4ede9f9498440cb4225c173767c1e/src/liballoc/sync.rs#L258-L269 https://github.com/rust-lang/rust/blob/09ab31bc64f4ede9f9498440cb4225c173767c1e/src/liballoc/sync.rs#L2288-L2304 (And similarly  | labels: T-lang, T-libs-api


compiler panic: "byte index 10 is not a char boundary" | ``` $ rustc -Vv rustc 1.36.0 (a53f9df32 2019-07-03) binary: rustc commit-hash: a53f9df32fbb0b5f4382caaad8f1a46f36ea887c commit-date: 2019-07-03 host: x86_64-apple-darwin release: 1.36.0 LLVM version: 8.0 $ echo Zm4gbWFpbigo2Lw= | base64 -D > main.rs $ rustc main.rs error: this fi | labels: I-ICE, A-parser, A-Unicode, P-medium, T-compiler, regression-from-stable-to-stable


missing symbol in codegen backend when built with llvm-libunwind | When enabling llvm-libunwind, I get this error while building stage2 compiler: ``` error: couldn't load codegen backend "/var/tmp/paludis/build/dev-lang-rust-scm/work/rust-scm/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/codegen-nightly-backends/libr | labels: A-LLVM, T-compiler, C-bug


ICE rink: higher-rank trait bound (HRTB) `for<'a> ...` hits OutputTypeParameterMismatch in librustc/traits/codegen | I have seen many `OutputTypeParameterMismatch` ICEs filed, so I decided to try to make a single representative issue for all of them. * Its possible that not all of these share the same root cause. But until I see a more fine grain way to categorize them, I'm going to at least tr | labels: I-ICE, A-trait-system, P-medium, T-compiler, C-bug, A-lazy-normalization


Account for coercions in trait resolution? | This came up in https://github.com/rust-lang/rust/pull/62528, see “Joining strings with `char`”. Reduced test case: ```rust fn takes_str(_x: &str) {} fn takes_type_parameter<T>(_x: T) where T: SomeTrait {} trait SomeTrait {} impl SomeTrait for &'_ str {} impl SomeTrait for char { | labels: A-trait-system, T-lang, A-coercions


Missed optimization on array comparison | The godbolt link: https://godbolt.org/z/dc9o3x I think this snippet should just return `true`: ```rust pub fn compare() -> bool { let bytes = 12.5f32.to_ne_bytes(); bytes == if cfg!(target_endian = "big") { [0x41, 0x48, 0x00, 0x00] } else { [0x00, 0x00, 0x48, 0x41] } } ``` The ge | labels: A-LLVM, I-slow, C-enhancement, A-codegen, E-needs-test, T-compiler


ICE: "can't hash a TyVid" when failing to infer a const generic | A clean rust project on the latest nightly rustc with just this `src/main.rs`: ```rust #![feature(const_generics)] struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); } ``` produces the following error on cargo check/bu | labels: I-ICE, T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


diagnostic for naive recursive async functions is really unfriendly | The following Rust source ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=137001df1ae7afa5b2b4b0fe649b8ed6)): ```rust #![feature(async_await)] async fn foo(n: usize) { if n > 0 { foo(n - 1).await; } } fn main() { } ``` gives the error: ``` e | labels: T-compiler, A-async-await, AsyncAwait-Polish


ICE with turbofish "no type for node" | Compiler panics when using turbofish and `.parse()` I tried this code: ```rust use std::str::FromStr; struct Six(); impl FromStr for Six { type Err = String; fn from_str(s: &str) -> Result<Self, Self::Err> { if s.len() != 6 { return Err(format!("Incorrect length {}", s.len())); }


internal compiler error: Error constructed but not emitted | I see the following error on the `beta` and `nightly` channels, but not on `stable`: ``` $ echo "pub t(#" > main.rs $ rustc main.rs error: this file contains an un-closed delimiter --> main.rs:1:9 | 1 | pub t(# | - ^ | | | un-closed delimiter error: internal compiler error: Error | labels: I-ICE, A-parser, P-high, T-compiler, regression-from-stable-to-beta, E-needs-bisection


Paragraphs in block doc comments are broken | I returned to a crate of mine for the first time in quite a while and was perplexed to see that all of the paragraphs in my doc comments were gone, and instead had been turned into line breaks (so all of the paragraphs were squashed together). Upon investigation I discovered that | labels: T-rustdoc, C-bug


CString::into_raw() trigger miri | ```rust use std::ffi::CString; fn main() { let _hello = CString::new("Hello") .expect("CString::new failed") .into_raw(); } ``` This simple code should not trigger any error, except a leak of course. But miri report an error before: ```none error[E0080]: Miri evaluation error: tr | labels: A-FFI, A-miri


ICE: thread 'rustc' panicked at 'capacity overflow' | I'm seeing the following error on the `nightly` channel, but not on `stable` or `beta`: ``` $ echo "fn foo(u: u8) { if u8 macro_rules! u8 { (u6) => { fn uuuuuuuuuuu() { use s loo mod u8 {" > main.rs $ rustc main.rs error: this file contains an un-closed delimiter --> main.rs:1:89 | labels: I-ICE, P-medium, regression-from-stable-to-nightly, T-compiler, I-compilemem, C-bug


Tools are not available on cross compiled platforms since #61861 | Moved from https://github.com/rust-lang/rust-clippy/issues/4267 #61861 was merged in #61962, since then Rustfmt fails to build when cross compiling which is the case for almost all non Tier 1 platforms. Clippy and RLS are failing with similar error. Error on `aarch64-unknown-linu | labels: O-Arm, A-cross, regression-from-stable-to-stable, O-freebsd, T-bootstrap, T-infra


serde no longer builds with latest rustc (master) | Looks like something that landed in the commit range https://github.com/rust-lang/rust/compare/0b680cfce544ff9a59d720020e397c4bf3346650...d4e15655092d1bdae79619eb0ff2c3cb5468fc36 broke [building serde](https://travis-ci.com/rust-lang/miri/jobs/214779163): ``` error[E0433]: failed | labels: A-resolve, regression-from-stable-to-nightly, P-high, T-compiler, C-bug


test triagebot issue body commands | This appears to work in a test repo (https://github.com/foreign-rust-tester/triagebot-test/issues/6) but didn't work earlier today (https://github.com/rust-lang/rust/issues/62558). @rustbot modify labels: T-dev-tools A-rustbuild | labels: T-bootstrap, T-dev-tools


include material on async fn in the Rust reference | This is a "rust-lang/rust" placeholder for https://github.com/rust-lang-nursery/reference/issues/634, since that exists in another repo/org. | labels: T-lang, A-async-await, AsyncAwait-Polish


Compile times suddenly extremly high | Since one of my latest changes to my project, the compile times have been extremly high (jumping to >1min from about 15secs). I tried compiling the lib of this crate (it is to large to post here): https://github.com/fabianvdW/ChessInRust with `cargo build--release --lib` Compiler | labels: A-LLVM, I-compiletime, T-compiler, C-bug


Async blocks are leaky about wording wrt. `?` in diagnostics | E.g. consider: ```rust #![feature(async_await)] fn foo() { let x = async move { Err(())?; 1 }; } ``` which yields the diagnostic: ``` error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `std::ops::Try`)  | labels: A-diagnostics, T-compiler, A-async-await, AsyncAwait-Polish, AsyncAwait-Triaged, F-on_unimplemented


rustdoc crashes parsing strange doc-comment on 1.36 | After upgrading to 1.36 rustdoc is crashing like this when run on my crate: ``` thread 'rustc' panicked at 'unexpected item body MaybeEmphasis(2, true, false)', /work/toolchain/packages/rust/rustc-1.36.0-src/vendor/pulldown-cmark/src/parse.rs:2418:14 note: Some details are omitte | labels: T-rustdoc, I-ICE, C-bug


Pretty-printing support for Rust generators | Support printing Rust generators in a way that looks more like enums. Generators (as of #59897) are represented in Rust as variant layouts with some extra fields on the outer layout. These extra fields (which are upvars, captured from the environment of the generator closure) see | labels: A-debuginfo, C-enhancement, T-compiler, A-async-await, AsyncAwait-Triaged


"overflow evaluating the requirement" documenting synstructures in rustdoc beta, but not rustdoc stable nor rustc beta | I'm in a project which depends on both `syn` and `synstructures` crates. Using rustc `1.37.0-beta.2` or `rustc 1.38.0-nightly (78ca1bda3 2019-07-08)`, I can no longer document this crate with its dependencies. The following error occurs: ```rust $ cargo doc Downloaded synstructur | labels: T-rustdoc


Cross-compile to windows using clang fails | Trying to cross-compile to Windows (`x86_64-pc-windows-gnu`) with clang and lld fails as it tries to use the `--enable-long-section-names` which lld does not have. ``` $ cargo build --target x86_64-pc-windows-gnu --release […] error: linking with `/opt/llvm-mingw/bin/x86_64-w64-m | labels: A-linkage, A-LLVM, A-cross, T-compiler, O-windows-gnu, C-bug


ICE: "non-Scalar ConstValue encountered in super_relate_consts" with const generics | The following code: ```rust #![feature(const_generics)] struct NoMatch; fn foo<const T: NoMatch>() -> bool { return true } fn main() { foo::<{NoMatch}>(); } ``` Produces an ICE: ``` error: internal compiler error: src/librustc/ty/relate.rs:598: non-Scalar ConstValue encountered i | labels: I-ICE, T-compiler, C-bug, A-const-generics, requires-nightly, F-const_generics


rustc wrongly reports conflicting implementation | **`String` is not a `Copy`, there should be no conflicts.** ```rust struct S<V>(V); trait T<V> { fn m(&self) -> V; } impl<V: Copy> T<V> for S<V> { fn m(&self) -> V { self.0 } } impl T<String> for S<String> { fn m(&self) -> String { String::from("String") } } ``` ``` error[E0119]:


Wrong linker order on Linux produces error. | <!-- Thanks for filing a 🐛 bug report 😄! --> **Background** _Same background as #62588._ We have a Rust project (lets call it `dylib`) where we want to produce a shared library (.dll, .dylib, .so) for various platforms. As part of the build process we also want to verify the prov | labels: A-linkage, O-linux, T-compiler, C-bug


Regression with macros in types on serde_derive | serde_derive 0.0.94 compiles just fine with 2019-06-06's nightly, but is broken with 2019-06-11: ``` error[E0433]: failed to resolve: unresolved import --> src/internals/ast.rs:142:44 | 142 | variants: &'a Punctuated<syn::Variant, Token![,]>, | ^^^^^^^^^ | | | unresolved import | | labels: regression-from-stable-to-nightly


rust-cssparser doesn't compile anymore, complaining about `syn::Token!` | The latest nightly doesn't compiler [cssparser](https://github.com/servo/rust-cssparser). The error message is the following: ``` error[E0433]: failed to resolve: unresolved import --> build/match_byte.rs:48:31 | 48 | input.parse::<syn::Token![,]>()?; | ^^^^^^^^^^^^^^ | | | unres


Meaningless usage of comment decorators | We have a number of places in the code base that use 'comment decorators' i.e. from `rustlib/src/rust/src/libcore/option.rs` ``` ///////////////////////////////////////////////////////////////////////////// // Type implementation ////////////////////////////////////////////////// | labels: E-easy, C-cleanup, T-compiler


Update error message for `self` | I did some search and find no similar issue, so here is my report: Compile the following code: ```rust struct Data; impl Data { fn rc(self: &std::rc::Rc<Self>) { println!("&rc"); } } ``` Give the error: ``` error[E0658]: `&std::rc::Rc<Data>` cannot be used as the type of `self` w | labels: C-enhancement, A-diagnostics, T-compiler


LLVM ERROR: out of memory with latest nightly (Windows 32bit) | I am trying to upgrade rust nightly in a project of mine and getting `out of memory` errors due to that, only on Windows though. - old rust version: rustc 1.37.0-nightly (0dc9e9c10 2019-06-15) - new rust version: rustc 1.38.0-nightly (0b680cfce 2019-07-09) Build log of the failur | labels: A-LLVM, T-compiler, I-compilemem, C-bug


indirect_structural_match lint misfiring on enum variant unused in const item | (Spawned off of https://github.com/rust-lang/rust/issues/62411#issuecomment-510604193) Consider this code ([play](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=449daf68183e9566fc106b070fdaeb10)): ```rust struct Sum(u32, u32); impl PartialEq for Sum { fn | labels: A-lints, P-medium, T-compiler


[1.38] rayon failing test | * rayon-1.1.0: [start](https://crater-reports.s3.amazonaws.com/beta-1.37-1/1.36.0/reg/rayon-1.1.0/log.txt) v. [end](https://crater-reports.s3.amazonaws.com/beta-1.37-1/beta-2019-07-04/reg/rayon-1.1.0/log.txt); cc @cuviper Haven't actually attempted to reproduce this locally but l | labels: T-libs-api, T-compiler, regression-from-stable-to-beta


[1.38] Placement new syntax no longer parses | root: mbox 0.3.1; cc @kennytm causes: * resin-os/healthdog-rs: [start](https://crater-reports.s3.amazonaws.com/beta-1.37-1/1.36.0/gh/resin-os.healthdog-rs/log.txt) v. [end](https://crater-reports.s3.amazonaws.com/beta-1.37-1/beta-2019-07-04/gh/resin-os.healthdog-rs/log.txt); cc ` | labels: A-parser, T-lang, regression-from-stable-to-beta


Dependency check of the tidy tool should verify the license | Currently, in the dependency-check of the tidy tool, dependencies having an incompatible license are white-listed, and the actual license is documented in a comment. Instead, the actual license should be documented in code, and the tool should check that the license is actually c | labels: A-testsuite, C-enhancement, T-infra


Dependency check of the tidy tool should verify libstd dependencies | There is a documentation comment explicitly saying that it is **crucial** for libcore,liballoc,libstd not to depend on any crate with incompatible licenses, yet a couple of lines after there is an exemption that does precisely this: https://github.com/rust-lang/rust/blob/master/s | labels: A-runtime, A-testsuite, C-bug


Code under the 2-clause-BSD license is not documented as a compatible license for the Rust runtime | The 2-clause-BSD license is not documented in the tidy script as being a compatible license for the rust runtime dependencies. We used to ship BSD licensed code as part of libstd until recently: https://github.com/rust-lang/rust/commit/0b85b64d6b70b100f6222a96ff2337c302b386f1#dif | labels: A-testsuite, C-bug


Function items will not coerce to function pointers when inferring the type of a generic function argument with a trait bound | Function items do not coerce to fn pointer types when they are passed as a generic function parameter with a trait bound. A manual cast or type annotation is required. trait Foo {} impl Foo for fn() {} fn non_generic(_f: fn()) {} fn generic_without_bound<F>(_f: F) {} fn generic_w | labels: T-lang, C-feature-request, A-coercions, needs-rfc


Add Option::err_or* to complement Option::ok_or* | We already have `Option::ok_or` and `Option::ok_or_else` to go from `Option<T>` to `Result<T, _>`, but we have no method to perform the opposite conversion from `Option<E>` to `Result<_, E>`. (Eventual) tracking issue for #62624. | labels: T-libs-api, C-tracking-issue


Pretty-printing/tokenization of `final` has changed to `r#final` | Given a procedural macro like: ```rust extern crate proc_macro; use proc_macro::*; #[proc_macro_attribute] pub fn foo(a: TokenStream, b: TokenStream) -> TokenStream { assert_eq!(a.to_string(), "final"); return b.into_iter().collect(); } ``` and a consumer like: ```rust #[foo::foo | labels: A-parser, A-macros, T-compiler, C-bug


Odd type mismatch error? | I got the following while working on #58281. I messed up the condition of an `if` (so that its type was `usize` instead of `bool`) as the error correctly points: ```console Compiling rustc_mir v0.0.0 (/nobackup/rust2/src/librustc_mir) error[E0308]: mismatched types --> src/librus | labels: A-diagnostics, T-compiler, C-bug


rustc panics when trying to get session directory when building project on ramdisk | Seems similar to #52440, but no cross platform weirdness is in play. Project builds fine on a normal C drive on windows, but when the same repo is cloned to a ramdisk (created by imdisk driver) on windows, rustc panics. First incremental compilation gives an error so it appears t | labels: I-ICE, T-compiler, A-incr-comp, C-bug


Bring back suggestion for splitting `<-` in a comparison | ```rust fn main() { if x<-1 { } } ``` produces: ``` error: expected `{`, found `<-` ``` It would be nice if it produced a suggestion to split it up: ```rust if x < -1 { ``` (This [used to happen](https://github.com/rust-lang/rust/pull/60803#discussion_r303081575), but was broken  | labels: E-easy, C-enhancement, A-diagnostics, T-compiler


Tracking issue for Option::expect_none(msg) and unwrap_none() | ```rust impl<T: fmt::Debug> Option<T> { pub fn expect_none(self, msg: &str); pub fn unwrap_none(self); } ``` **Steps:** - [x] Merge the implementation (#62596) - [ ] Stabilization PR - [ ] Update the `must_use` message on `is_none` (per https://github.com/rust-lang/rust/pull/6243 | labels: T-libs-api, B-unstable, C-tracking-issue, finished-final-comment-period, disposition-close, A-result-option


Running out of RAM during compilation | Hi Incorrectly closing the parentheses around an if expression causes the compiler to be stuck in endless recursion (probably), causing the computer to run out of memory. I encountered this bug while trying to return `Some(if cond { ... } else { ... })` from a function by acciden | labels: P-medium, T-compiler, regression-from-stable-to-stable, I-compilemem, C-bug


Suggest removal of `.as_str()` when called on a `&str` | Given ``` fn make_lipographic(banned: char, line: &str) -> String { line.as_str().chars().filter(|&c| c != banned).collect() } fn main() { let passage = String::from("If Youth, throughout all history, had had a champion to stand up for it"); assert_eq!(make_lipographic('e', &pass | labels: C-enhancement, A-diagnostics, P-low, T-compiler, A-suggestion-diagnostics


Nonsensical error message with const generics and std::mem::sized_of | The following code: ```rust #![feature(const_generics)] trait IsZst { type ZST; } impl<T: Sized> IsZst for T where T: Sized { type ZST = ZstHelper<{std::mem::size_of::<T>() == 0}>; } struct ZstHelper<const T: bool>; ``` produces the following error: ``` error[E0277]: the size for | labels: A-diagnostics, T-compiler, C-bug, A-const-generics, requires-nightly, F-on_unimplemented


Rustbuild rebuilt when checkout branch and checkout back | For example, when I am on my branch `feature`, I checkout to `master` and check back to `feature`, rustbuid rebuilt from stage 0. | labels: T-bootstrap, T-infra


ICE in incr comp after s/trait/struct/: src/librustc/dep_graph/graph.rs:688: DepNode Hir(...) should have been pre-allocated but wasn't. | Hi, I just got a crash on Travis, on stable (1.35.0), when enabling edition="2018" Commands ran by Travis: ``` git clone https://github.com/fflorent/nom_locate.git cd nom_locate git checkout -qf 77e08c3bfb1cadee8176f96ea78ba8c68308d9c8 cargo build --no-default-features --features | labels: I-ICE, P-high, T-compiler, regression-from-stable-to-stable, A-incr-comp, C-bug


diagnostics: suggest "Self::" on missing type not found in trait definition | ````rust trait A { type Bla; fn to_bla(&self) -> Bla; } ```` yields ```` error[E0412]: cannot find type `Bla` in this scope --> src/main.rs:3:25 | 3 | fn to_bla(&self) -> Bla; | ^^^ not found in this scope error: aborting due to previous error ```` it would be helpful to suggest  | labels: A-diagnostics, A-associated-items, A-suggestion-diagnostics


"unresolved import" message makes little sense with 2018 edition | ``` $ cargo check error[E0432] unresolved import `foo` | x | foo::{Bar, Baz}, | ^^^ maybe a missing `extern crate foo;`? ``` The above message makes little sense with the 2018 edition of Rust, since `extern crate` isn't required anymore. | labels: E-easy, A-diagnostics, E-needs-test, P-medium, T-compiler, A-suggestion-diagnostics


Unhelpful error message for lifetime parameter E0495 | Code to reproduce ``` #![feature(async_await)] use std::future::Future; struct Test; async fn foo(_: &Test) {} impl Test { fn test(&self) -> Box<dyn Future<Output=()> + 'static> { Box::new(async { foo(self).await }) } } ``` Error message: ``` Compiling playground v0.0.1 (/playgro | labels: C-enhancement, A-diagnostics, A-lifetimes, T-compiler, D-newcomer-roadblock


ICE: assertion failed: `(left == right)` in type_of.rs | I just ran into this ICE: ``` thread 'rustc' panicked at 'assertion failed: `(left == right)` left: `Size { raw: 404 }`, right: `Size { raw: 400 }`', src/librustc_codegen_llvm/type_of.rs:148:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. error: i | labels: A-codegen, I-ICE, O-Arm, regression-from-stable-to-nightly, P-high, T-compiler


ICE with wrong method receiver as second parameter | The following code ([on compiler explorer](https://godbolt.org/z/_Qo2zy)) leads to an ICE: ```rust struct Foo; impl Foo { // mind the missing `>` of the receiver pub fn foo(_: i32, self: Box<Self) {} } ``` Broken since 1.32.0 up to the current nightly, earlier versions are not af | labels: A-diagnostics, I-ICE, A-parser, T-compiler, regression-from-stable-to-stable


Rust binaries seem a bit large | Rust newbie here, going through the rust-lang book, specifically chapter 1.2. >$ rustc --version >rustc 1.36.0 (a53f9df32 2019-07-03) >$ cat main.rs >fn main() >{ > println!("Hello, world!"); >} > >$ rustc main.rs >$ ls -la >total 528 >drwxr-xr-x 4 zzy staff 128 Jul 13 12:21 . >d


./x.py build OSError: [Errno 2] No such file or directory | Trying to build from source on Ubuntu 18.04 x64 ``` Traceback (most recent call last): File "./x.py", line 11, in <module> bootstrap.main() File "/tmp/z/rust/src/bootstrap/bootstrap.py", line 866, in main bootstrap(help_triggered) File "/tmp/z/rust/src/bootstrap/bootstrap.py", li


e0308 possibly confusing error message | I got the following error today: ``` error[E0308]: mismatched types --> src/util.rs:13:33 | 13 | fn from_str(input: &str) -> Result<Self, Self::Err> { | -------- ^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found () | | | this function's body doesn't return | = no | labels: A-diagnostics, T-compiler, C-bug


Add tests for overlapping explicitly dropped locals in generators | #61922 allows us to overlap `x` and `y` in this example: ```rust fn gen() { let x = [0u8; 1024]; yield; drop(x); let y = [0u8;1024]; yield; drop(y); } ``` Come to think of it, this is a pretty important behavior that I should have added an explicit test for. | labels: E-needs-test, T-compiler, A-coroutines


Suboptimal niche usage within the fields of a variant. | On x86_64, this prints the values in comments: ```rust pub enum Option2<A, B> { Some(A, B), None } fn main() { use std::mem::size_of; dbg!(size_of::<Option<Option<(bool, &())>>>()); // = 16 dbg!(size_of::<Option<Option<(&(), bool)>>>()); // = 16 dbg!(size_of::<Option<Option2<bool | labels: T-compiler, C-bug


ICE: Can't hash a TyVid (const generics???) | I'm not sure if this happens due to const generics, but while working on a codebase I stumbled upon this ICE multiple times: <details> <summary>Backtrace:</summary> ``` error: internal compiler error: src\librustc\ich\impls_ty.rs:213: ty::TyKind::hash_stable() - can't hash a TyVi | labels: I-ICE, T-compiler, C-bug, E-needs-mcve, requires-nightly, F-const_generics


Failed in tidy due to submodule | In the latest rust-lang/rust master, we see many tidy (`x.py test src/tools/tidy`) errors probably due to stdarch(stdsimd). Errors, for example: - CR characters - line longer than 100 chars - tab characters I already ran `x.py clean` but the issue hasn't been fixed.


ICE using associated constant in generic type | I'd like to use an associated constant when telling `arrayvec::ArrayVec` how big the underlying array should be and encountered an ICE while running the following code: ```rust use arrayvec::ArrayVec; pub struct MultiDriver<D: ?Sized> { drivers: ArrayVec<[Driver<D>; MultiDriver:: | labels: I-ICE, A-trait-system, P-medium, A-associated-items, T-compiler, C-bug


Which is accessor method of MetadataExt? | https://github.com/rust-lang/rust/blob/4b65a86ebace8600c8e269e8bfe3365cdc460e68/src/libstd/os/linux/fs.rs#L36-L41 | labels: O-linux, C-enhancement, A-docs


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


ICE "no ImplicitCtxt stored in tls" in Servo on Windows and macOS | Compiling Servo with rustc 1.38.0-nightly (4b65a86eb 2019-07-15) works fine on Linux. On a Windows or macOS host the compiler panics on the `script` crate: ```rust thread 'rustc' panicked at 'no ImplicitCtxt stored in tls', src\libcore\option.rs:1065:5 stack backtrace: 0: std::sy | labels: I-ICE, P-high, T-compiler, regression-from-stable-to-beta, C-bug


Send trait bound failure error message doesn't refer to Send at all | If a trait method expects a `Future` to be `Send` but we try to use it for a `Future` that doesn't implement `Send`, the compiler error message doesn't mention the missing `Send` trait at all, which makes it very hard to debug the issue. Example: https://play.rust-lang.org/?versi | labels: A-diagnostics, T-compiler, C-bug


String truncate assertion failed with some chars | This assertion failed when using a specific charset : `liballoc/string.rs:1557` Step to reproduce : ```rust fn main() { let mut s = "ボルテックス".to_string(); s.truncate(4); } ``` ## Meta `rustc --version --verbose`: ``` rustc 1.36.0 (a53f9df32 2019-07-03) binary: rustc commit-hash: a | labels: C-enhancement, A-diagnostics, T-libs-api


Why is Rust free? | Hello Rust developers, I have tried searching on rust-lang.org and related websites. I've searched wikipedia and the Internet. But I can't find the answer to my question: Why is Rust free? May I ask if you could add that answer to rust-lang.org? Just in case other people have tha


Improving error for unnecessary parentheses in `for` loop head | The following code: ```rust fn main() { let v = vec![1,2,3]; for (x in v) { } } ``` leads to this error: ``` error: expected one of `)`, `,`, or `@`, found `in` --> src/main.rs:4:12 | 4 | for (x in v) { } | ^^ expected one of `)`, `,`, or `@` here ``` ([playground](https://play.r | labels: C-enhancement, A-diagnostics, A-parser, P-low, T-compiler, A-suggestion-diagnostics


Tracking issue for io_slice_advance | This is a tracking issue for `IoSlice::{advance, advance_slices}` and `IoSliceMut::{advance, advance_slices}`. Feature gate: #![feature(io_slice_advance)]. Steps: - [x] Implement the RFC. * #62987 * #85802 - [ ] FCP - [ ] Stabilization PR. Current API additions: ```rust impl<'a>  | labels: T-libs-api, B-unstable, C-tracking-issue, disposition-merge, finished-final-comment-period, A-io


core::fmt::Formatter needs setter methods | If you're given a format string when formatting a struct there's no way to 1) read some of that data 2) decide how to format the struct fields. 3) have those fields then format themselves according to an alternate `Formatter` based on your decision above. **Example:** if you get  | labels: T-libs-api, C-feature-request


rustc-guide submodule issues | Recent PR (#62733) failed due to some issues with updating the rustc-guide submodule. It's not clear exactly the extent of what's wrong, but here are some issues I see: - I can't find anything that actually runs the rustc-guide tests. - Running them locally, they fail with bad li | labels: T-compiler, T-infra, C-bug


rustdoc doesn't render links in Trait Implementations sections | https://doc.rust-lang.org/nightly/std/iter/struct.Flatten.html#method.scan ![image](https://user-images.githubusercontent.com/15225902/61345900-28c8b300-a881-11e9-8454-90b780310685.png) https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.scan ![image](https://us | labels: T-rustdoc


ICE: Generic type alias to invalid type crashes during type check on latest stable | This also crashes on the latest nightly [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0d49e84d11fd24aa8d24c1da1be6a428) ```rust use std::marker::PhantomData; fn _alias_check() { WrongImpl::foo(0i32); // crash WrongImpl::<()>::foo(0i32); // f | labels: I-ICE, A-trait-system, P-high, T-compiler, regression-from-stable-to-stable, C-bug


_mm_storeu_si16 and _mm_storeu_si64 are missing but not documented as such | * [_mm_storeu_si16](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#=undefined&text=_mm_storeu_si16&techs=SSE) * [_mm_storeu_si64](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#=undefined&text=_mm_storeu_si64&techs=SSE) They're both missing from `cor | labels: O-x86_64, T-libs-api, A-SIMD, O-x86_32


Docker build stopped due to lot of memory usage during dependencies compilation | Hello, I'm currently face to a big issue for me. Trying to build the docker image of this project: https://github.com/FTV-Subtil/rs_http_worker I cannot achieve it as lot of memory is used, so workers swap a lot and build take more than 1h. Do you have some ideas to optimise buil


core: undefined symbol: Z3_mk_config" | repo is @ bf16480f9cf124630f4a4ffc6d8a57b72fbd5ce9 ```` Compiling core v0.0.0 (/home/matthias/vcs/github/rust/src/libcore) error: couldn't load codegen backend "/home/matthias/vcs/github/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backe | labels: A-linkage, A-LLVM, A-codegen, T-compiler, C-bug