jiebi/CodeConvo huggingface dataset:
Change:
} has_emitted } <del> ty::Tuple(ref tys) => { </del> <ins> ty::Tuple(_) => { </ins> let mut has_emitted = false; <del> let spans = if let Some(hir::ExprKind::Tup(comps)) = data.expr.map(|e| &e.kind) { debug_assert_eq!(comps.len(), tys.len()); comps.iter().map(|e| e.span).collect() } else { vec![] </del> <ins> let comps = match data.expr.map(|e| &e.kind) { Some(hir::ExprKind::Tup(comps)) => { debug_assert_eq!(comps.len(), ty.tuple_fields().count()); Some(comps) } _ => None, </ins> }; <del> for (i, ty) in tys.iter().map(|k| k.expect_ty()).enumerate() { </del> <ins> for (i, ty) in ty.tuple_fields().enumerate() { </ins> let descr_post = &format!(" in tuple element {}", i); <del> let span = *spans.get(i).unwrap_or(&data.source_span); </del> <ins> let span = comps.and_then(|c| c.get(i)).map(|e| e.span).unwrap_or(data.source_span); </ins> if check_must_not_suspend_ty( fcx, ty, hir_id, <del> SuspendCheckData { descr_post, source_span: span, ..data }, </del> <ins> SuspendCheckData { descr_post, expr: comps.and_then(|comps| comps.get(i)), source_span: span, ..data }, </ins> ) { has_emitted = true; }

Discussion:
This debugassert: Is triggered by the following input, found by : <details<summary<strongBacktrace</strong</summary<p</p</details
Reduced (in terms of unrelated errors):
label +requires-nightly +A-generators +F-generators
Change:
## Quick Start <del> 1. Download a [binary installer][installer] for your platform. 2. Read [The Rust Programming Language][trpl]. 3. Enjoy! </del> <ins> Read ["Installing Rust"][install] from [The Book][trpl]. </ins> <del> > ***Note:*** Windows users can read the detailed > [using Rust on Windows][win-wiki] notes on the wiki. [installer]: http://www.rust-lang.org/install.html </del> <ins> [install]: http://doc.rust-lang.org/book/installing-rust.html </ins> [trpl]: http://doc.rust-lang.org/book/index.html <del> [win-wiki]: https://github.com/rust-lang/rust/wiki/Using-Rust-on-Windows </del> ## Building from Source

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
<ins> // aux-crate:aux=assoc-inherent-unstable.rs // edition: 2021 type Data = aux::Owner::Data; //~ ERROR use of unstable library feature 'data' fn main() {} </ins>

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
use rustc::hir::map::definitions::*; use rustc_ast::ast::*; use rustc_ast::token::{self, Token}; <del> use rustc_ast::visit; </del> <ins> use rustc_ast::visit::{self, FnKind}; </ins> use rustc_expand::expand::AstFragment; use rustc_hir::def_id::DefIndex; use rustc_span::hygiene::ExpnId;

Discussion:
I was migrating my library (Mammut) to use reqwest and be async, and the compiler ICEd. I don't know how to reduce it further than this. I tried this code: I expected to see this happen: A successful build or another compile error Instead, this happened: I also tried this on the latest nightly and it emits the same error. : Backtrace:
Reproduced with lastest nighlty: ICE from macro resolving I believe. cc
cc
triage: P-high, removing nomination tag. (instead, going to proritize going through the P-high issues that have accumulated over last two weeks.)
Visiting from triage.. the next step is to reduce the reproducer.
Reduced ():
Further reduced:
Fixed in
Change:
<ins> error[E0594]: cannot assign to `x`, as it is a captured variable in a `Fn` closure --> $DIR/wrong-closure-arg-suggestion-125325.rs:23:21 | LL |     fn assoc_func(&self, _f: impl Fn()) -> usize { |                              --------- change this to accept `FnMut` instead of `Fn` ... LL |     s.assoc_func(|| x = ()); |       --------------^^^^^^- |       |          |  | |       |          |  cannot assign |       |          in this closure |       expects `Fn` instead of `FnMut` error[E0594]: cannot assign to `x`, as it is a captured variable in a `Fn` closure --> $DIR/wrong-closure-arg-suggestion-125325.rs:25:13 | LL | fn func(_f: impl Fn()) -> usize { |             --------- change this to accept `FnMut` instead of `Fn` ... LL |     func(|| x = ()) |     ---- -- ^^^^^^ cannot assign |     |    | |     |    in this closure |     expects `Fn` instead of `FnMut` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0594`. </ins>

Discussion:
I tried this code: I expected to see this happen: Code compilation, or at least a sensible error. Instead, this happened: I tried to make a reproducer using the following code that expresses the same type and fn signatures on Rust Playground, but I'm unable to trigger it. : tested on Nightly as well. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
- and even smaller example
Thank you!!
claim
Change:
let suggest_eq = if self.token.kind == token::Dot && let _ = self.bump() && let mut snapshot = self.create_snapshot_for_diagnostic() <del> && let Ok(_) = snapshot.parse_dot_suffix_expr( colon_sp, self.mk_expr_err( </del> <ins> && let Ok(_) = snapshot .parse_dot_suffix_expr( </ins> colon_sp, <del> self.dcx().delayed_bug("error during `:` -> `=` recovery"), ), ) { </del> <ins> self.mk_expr_err( colon_sp, self.dcx() .delayed_bug("error during `:` -> `=` recovery"), ), ) .map_err(Diag::cancel) { </ins> true } else if let Some(op) = self.check_assoc_op() && op.node.can_continue_expr_unambiguously()

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
cc
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags:-Zmir-opt-level=2 trait Array { type Item; } fn foo<A: Array>() { let _: *mut A::Item = std::ptr::null_mut(); } struct Foo; impl Array for Foo { type Item = i32; } fn main() { foo::<Foo>(); } </ins>

Discussion:
Compiling v0.2.10 and v0.4.4 with , I get the following ICEs:
reproduction:
Change:
| help: consider cloning the value if the performance cost is acceptable | <del> LL -     *u.d LL +     u.d.clone() | </del> <ins> LL |     (*u.d).clone() |     +    +++++++++ </ins> error: aborting due to 4 previous errors

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
} } } <ins> struct DetectNonGenericPointeeAttr<'a, 'b> { cx: &'a ExtCtxt<'b>, } impl<'a, 'b> rustc_ast::visit::Visitor<'a> for DetectNonGenericPointeeAttr<'a, 'b> { fn visit_attribute(&mut self, attr: &'a rustc_ast::Attribute) -> Self::Result { if attr.has_name(sym::pointee) { self.cx.dcx().emit_err(errors::NonGenericPointee { span: attr.span }); } } fn visit_generic_param(&mut self, param: &'a rustc_ast::GenericParam) -> Self::Result { let mut error_on_pointee = AlwaysErrorOnGenericParam { cx: self.cx }; match &param.kind { GenericParamKind::Type { default } => { // The `default` may end up containing a block expression. // The problem is block expressions  may define structs with generics. // A user may attach a #[pointee] attribute to one of these generics // We want to catch that. The simple solution is to just // always raise a `NonGenericPointee` error when this happens. // // This solution does reject valid rust programs but, // such a code would have to, in order: // - Define a smart pointer struct. // - Somewhere in this struct definition use a type with a const generic argument. // - Calculate this const generic in a expression block. // - Define a new smart pointer type in this block. // - Have this smart pointer type have more than 1 generic type. // In this case, the inner smart pointer derive would be complaining that it // needs a pointer attribute. Meanwhile, the outer macro would be complaining // that we attached a #[pointee] to a generic type argument while helpfully // informing the user that #[pointee] can only be attached to generic pointer arguments rustc_ast::visit::visit_opt!(error_on_pointee, visit_ty, default); } GenericParamKind::Const { .. } | GenericParamKind::Lifetime => { rustc_ast::visit::walk_generic_param(&mut error_on_pointee, param); } } } fn visit_ty(&mut self, t: &'a rustc_ast::Ty) -> Self::Result { let mut error_on_pointee = AlwaysErrorOnGenericParam { cx: self.cx }; error_on_pointee.visit_ty(t) } } struct AlwaysErrorOnGenericParam<'a, 'b> { cx: &'a ExtCtxt<'b>, } impl<'a, 'b> rustc_ast::visit::Visitor<'a> for AlwaysErrorOnGenericParam<'a, 'b> { fn visit_attribute(&mut self, attr: &'a rustc_ast::Attribute) -> Self::Result { if attr.has_name(sym::pointee) { self.cx.dcx().emit_err(errors::NonGenericPointee { span: attr.span }); } } } </ins>

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
} Ok(self) } <ins> fn pretty_closure_as_impl( mut self, closure: ty::ClosureSubsts<'tcx>, ) -> Result<Self::Const, Self::Error> { let sig = closure.sig(); let kind = closure.kind_ty().to_opt_closure_kind().unwrap_or(ty::ClosureKind::Fn); write!(self, "impl ")?; self.wrap_binder(&sig, |sig, mut cx| { define_scoped_cx!(cx); p!(print(kind), "("); for (i, arg) in sig.inputs()[0].tuple_fields().iter().enumerate() { if i > 0 { p!(", "); } p!(print(arg)); } p!(")"); if !sig.output().is_unit() { p!(" -> ", print(sig.output())); } Ok(cx) }) } </ins> } // HACK(eddyb) boxed to avoid moving around a large struct by-value.

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
let s = format!("{}", b); assert_eq!(s, "&Any"); } <ins> #[test] fn deref() { fn homura<T: Deref<i32>>(_: T) { } homura(box 765i32); } </ins> }

Discussion:
As titled. Currently Box does not implement Deref: But Box should be able to implement Deref.
(Tagged E-easy in the hope that it's as simple as adding the impls gives in the issue. There is the chance that there is some compiler peculiarities that make this not-easy.)
has kindly volunteered to mentor; catch him here or as on IRC.
Can I have a go at this? Looks easy enough...
it's already been done/attempted in . :smile:
Oh well, never mind, I must've overlooked the cross-ref...
This issue seems resolved due to close and merge.
unfortunately it wasn't merged.
Change:
<ins> error: any use of this value will cause an error --> $DIR/dangling-alloc-id-ice.rs:10:1 | LL | / const FOO: &() = { //~ ERROR any use of this value will cause an error LL | |     let y = (); LL | |     unsafe { Foo { y: &y }.long_live_the_unit } LL | | }; | |__^ type validation failed: encountered dangling pointer in final constant | = note: #[deny(const_err)] on by default error: aborting due to previous error </ins>

Discussion:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.
Change:
<ins> running 4 tests test short_test_name ... ignored test this_is_a_really_long_test_name ... ignored test short_bench_name                 ... bench:           ?? ns/iter (+/- ??) test this_is_a_really_long_bench_name ... bench:           ?? ns/iter (+/- ??) test result: ok. 0 passed; 0 failed; 2 ignored; 2 measured; 0 filtered out; finished in ??s </ins>

Discussion:
libtest output recently started indenting some but not all test results: Seems like benchmarks are indented but regular tests are not.
Cc any idea which change might have caused this? I think this must be fairly recent but haven't tried bisecting yet.
Is this still reproducable?
With this can no longer be tested using x.py, since bootstrap now does test output formatting itself. So this now needs a little cargo project with a test and a benchmark, to check what libtest actually does.
It is because benches are dynamic, and they always use padding (and tests are static): I'm not sure why padding is different for static vs dynamic. Here is a repro:
Seems like that could use context if the bench is only being run as a test, then don't pad. The padding is desirable for benchmark output so the numeric values line up, for easier visual comparison. You could argue either way about tests -- maybe ok/FAILED would stand out even more with padded alignment.
PR with regression tests and a fix (in that order):
Change:
pub struct Thread(!); <del> pub const DEFAULT_MIN_STACK_SIZE: usize = 4096; </del> <ins> pub const DEFAULT_MIN_STACK_SIZE: usize = 64 * 1024; </ins> impl Thread { // unsafe: see thread::Builder::spawn_unchecked for safety requirements

Discussion:
The DEFAULTMINSTACK_SIZE is the default stack size assigned when creating a thread. This value varies across different platforms. The issue is that there isn't enough explanation as to why these values are different, and users might not realize that the stack size can vary. Recently, I was running existing Windows code on a WASI target, and I kept encountering font decoding failures. Since it worked correctly on Windows, I suspected WASI's instability and spent considerable time debugging. After several days, I discovered that the root cause was the stack size: WASI has a very small stack size of 4KB, while Windows has a much larger stack size of 2MB. Once I forcibly increased the thread's stack size, all issues were resolved. I felt quite frustrated that such a simple reason caused the problem. Although this is my personal experience, I believe that rather than setting different default stack sizes for different platforms without a compelling reason, it would be better to have a consistent stack size across all platforms in Rust. However, I acknowledge that this suggestion might not be very effective because the required memory can vary depending on the instruction set or architecture. I would like to discuss this matter further.
Different platforms have different useful minimum stack sizes. I have no idea why only 4KiB is reserved on wasi.
In my opinion, this isn't an issue of "inconsistency" this is an issue of a target having an absurdly low value, period. Please open a PR to raise it.
What are the criteria for determining that? Since I don't know, I can't tell whether the 4KB for WASI is inappropriate or not, and I also can't open a PR because I don't know the appropriate value.
...a zillion insanely low-level minutiae like how big the registers are, mostly. an article that might help: as that article explains, the smallest thread stack size of all platforms that I'm aware of, aside from the ones in our repo that only ask for 4096 bytes, is 64KiB. the current 4096 bytes boundary has caused you significant pain so it seems sensible to raise it to at least that much, then fool around and see how it works.

having done some review of our platform code, I am pretty sure 4096 bytes was just picked as the "unsupported" value and platforms that initially lacked thread support, like wasm32-wasi, just inherited that value.
I understand. The differences between the platforms are indeed huge..! Before proceeding, I would like to hear the opinion or history from Alex Crichton, the main maintainer of the wasi target. , could you please share your thoughts on this issue?
I commented a bit on but I've no recollection for the current value for wasi. I suspect it was a number of historical accidents that led to this, and stack sizes should definitely be larger than 4k by default on wasi. Thanks for the issue
Change:
// EMIT_MIR gvn.generic_cast_metadata.GVN.diff // EMIT_MIR gvn.cast_pointer_eq.GVN.diff // EMIT_MIR gvn.cast_pointer_then_transmute.GVN.diff <ins> // EMIT_MIR gvn.remove_casts_must_change_both_sides.GVN.diff </ins>

Discussion:
<!-- 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. --Compiling the following code with results in ICE. Strangely, this code compiles fine without . Replace with plain comparison also works. : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This seems to bisect to cc
Thanks for the ping! I'll take a look. I thought I'd checked for this with , but clearly I missed something.
Change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e−11; // m³⋅kg⁻¹⋅s⁻² //~^ ERROR expected at least one digit in exponent fn main() {} </ins>

Discussion:
This code: () Looks pretty identical to this code: But the first one doesn't compile because I accidentally used a unicode minus sign (−) instead of a dash (-). This happened to me when I pasted a constant from Wikipedia. We already produce an error about things like this in other cases. For example with an en space: We produce the following: Maybe we could do the same for the minus sign since it is a pretty confusing error to receive?
The unicode minus sign is already on the list of similar characters: However it looks like it doesn't work in this context.