jiebi/CodeConvo huggingface dataset:
Change:
) = binding.kind { let def_id = (&*self).parent(ctor_def_id).expect("no parent for a constructor"); <del> if let Some(fields) = self.field_names.get(&def_id) { let first_field = fields.first().expect("empty field list in the map"); return Some(fields.iter().fold(first_field.span, |acc, field| acc.to(field.span))); } </del> <ins> let fields = self.field_names.get(&def_id)?; let first_field = fields.first()?; // Handle `struct Foo()` return Some(fields.iter().fold(first_field.span, |acc, field| acc.to(field.span))); </ins> } None }

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. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Minimized:
is the likely cause.
Assigning as and removing .
Change:
<ins> error[E0432]: unresolved import `self::p::nu` --> $DIR/issue-99695-b.rs:14:23 | LL |     pub use self::p::{nu, other_item as _}; |                       ^^ no `nu` in `m::p` | = note: this could be because a macro annotated with `#[macro_export]` will be exported at the root of the crate instead of the module where it is defined help: a macro with this name exists at the root of the crate | LL ~     use ::nu; LL ~ pub use self::p::{other_item as _}; | error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </ins>

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: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
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. // compile-pass // https://github.com/rust-lang/rust/issues/51300 #[derive(PartialEq, Eq, Clone, Copy)] pub struct Stat { pub id: u8, pub index: usize, } impl Stat { pub const STUDENT_HAPPINESS: Stat = Stat{ id: 0, index: 0, }; pub const STUDENT_HUNGER: Stat = Stat{ id: 0, index: Self::STUDENT_HAPPINESS.index + 1, }; } pub fn from_index(id: u8, index: usize) -> Option<Stat> { let stat = Stat{id, index}; match stat { Stat::STUDENT_HAPPINESS => Some(Stat::STUDENT_HAPPINESS), Stat::STUDENT_HUNGER => Some(Stat::STUDENT_HUNGER), _ => None, } } fn main() { } </ins>

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
use rustc_hir::def::DefKind; use rustc_hir::def_id::{DefId, LocalDefId}; use rustc_middle::ty::query::Providers; <del> use rustc_middle::ty::{self, CrateVariancesMap, TyCtxt, TypeSuperVisitable, TypeVisitable}; </del> <ins> use rustc_middle::ty::{self, CrateVariancesMap, SubstsRef, Ty, TyCtxt}; use rustc_middle::ty::{DefIdTree, TypeSuperVisitable, TypeVisitable}; </ins> use std::ops::ControlFlow; /// Defines the `TermsContext` basically houses an arena where we can

Discussion:
The following compiles on the current nightly (1.67.0-nightly (2022-12-03 )) although it shouldn't: It is correctly rejected by the current beta: 1.66.0-beta.2 (2022-11-20 ). This is most likely (I haven't bisected though!). Cc label C-bug T-compiler I-unsound regression-from-stable-to-nightly A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
)); } } <del> ObligationCauseCode::RepeatElementCopy { is_const_fn } => { </del> <ins> ObligationCauseCode::RepeatElementCopy { is_constable, elt_type, elt_span, elt_stmt_span } => { </ins> err.note( "the `Copy` trait is required because this value will be copied for each element of the array", ); <del> if is_const_fn { err.help( "consider creating a new `const` item and initializing it with the result  of the function call to be used in the repeat position, like  `const VAL: Type = const_fn();` and `let x = [VAL; 42];`", ); </del> <ins> let value_kind = match is_constable { IsConstable::Fn => Some("the result of the function call"), IsConstable::Ctor => Some("the result of the constructor"), _ => None }; let sm = tcx.sess.source_map(); if let Some(value_kind) = value_kind && let Ok(snip) = sm.span_to_snippet(elt_span) { let help_msg = format!( "consider creating a new `const` item and initializing it with {value_kind}  to be used in the repeat position"); let indentation = sm.indentation_before(elt_stmt_span).unwrap_or_default(); err.multipart_suggestion(help_msg, vec![ (elt_stmt_span.shrink_to_lo(), format!("const ARRAY_REPEAT_VALUE: {elt_type} = {snip};n{indentation}")), (elt_span, "ARRAY_REPEAT_VALUE".to_string()) ], Applicability::MachineApplicable); </ins> } <del> if self.tcx.sess.is_nightly_build() && is_const_fn { </del> <ins> if self.tcx.sess.is_nightly_build() && matches!(is_constable, IsConstable::Fn|IsConstable::Ctor) { </ins> err.help( "create an inline `const` block, see RFC #2920  <https://github.com/rust-lang/rfcs/pull/2920> for more information",

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
<ins> error: expected `+` between lifetime and Sized --> $DIR/issue-102598.rs:1:20 | LL | fn foo<'a>(_: impl 'a Sized) {} |                    ^^ | help: add `+` | LL | fn foo<'a>(_: impl 'a + Sized) {} |                       + error: expected one of `:`, `@`, or `|`, found `)` --> $DIR/issue-102598.rs:1:28 | LL | fn foo<'a>(_: impl 'a Sized) {} |                            ^ expected one of `:`, `@`, or `|` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) help: if this is a parameter name, give it a type | LL | fn foo<'a>(_: impl 'a Sized: TypeName) {} |                            ++++++++++ help: if this is a type, explicitly ignore the parameter name | LL | fn foo<'a>(_: impl 'a _: Sized) {} |                       ++ error: expected one of `)`, `+`, or `,`, found `Sized` --> $DIR/issue-102598.rs:1:23 | LL | fn foo<'a>(_: impl 'a Sized) {} |                      -^^^^^ expected one of `)`, `+`, or `,` |                      | |                      help: missing `,` error: at least one trait must be specified --> $DIR/issue-102598.rs:1:15 | LL | fn foo<'a>(_: impl 'a Sized) {} |               ^^^^^^^ error: aborting due to 4 previous errors </ins>

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. --I tried this almost-correct code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- 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
Change:
} /// Use the `format!` syntax to write data into a buffer, appending a newline. <ins> /// On all platforms, the newline is the LINE FEED character (`n`/`U+000A`) /// alone (no additional CARRIAGE RETURN (`r`/`U+000D`). </ins> /// /// This macro is typically used with a buffer of `&mut `[`Write`][write]. ///

Discussion:
As I was using writeln! to fill an in-memory buffer for data that explicitly wants a specific type of newlines (LF, fortunately), and I was wondering whether writeln! would always use LF, or would use the type of newline relevant to the platform (essentially, LF on Unix, CR/LF on Windows), and couldn't find the answer in !.html. (I got my answer on IRC, it's always LF) There may be other places where such information is relevant (println! comes to mind). Cc:
Sure, want to add it? :)
I would, if I knew whether there are other places that would benefit from this information as well.
Except for and , I don't see any places... You can already add it to these docs and if another function/macro needs it, then we'll add it.
Change:
let struct_ref = &a_struct; let owned = box 6; <del> let closure = || { zzz(); // #break variable = constant + a_struct.a + struct_ref.a + *owned; }; closure(); </del> <ins> { let closure = || { zzz(); // #break variable = constant + a_struct.a + struct_ref.a + *owned; }; closure(); } { let mut unboxed_closure = |&mut:| { zzz(); // #break variable = constant + a_struct.a + struct_ref.a + *owned; }; unboxed_closure(); } </ins> } fn zzz() {()}

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
let mut filtered = FilteredTests { tests: Vec::new(), benches: Vec::new(), next_id: 0 }; <del> for test in filter_tests(opts, tests) { </del> <ins> let mut filtered_tests = filter_tests(opts, tests); if !opts.bench_benchmarks { filtered_tests = convert_benchmarks_to_tests(filtered_tests); } for test in filtered_tests { </ins> let mut desc = test.desc; desc.name = desc.name.with_padding(test.testfn.padding()); match test.testfn { <del> DynBenchFn(benchfn) => { if opts.bench_benchmarks { filtered.add_bench(desc, DynBenchFn(benchfn)); } else { filtered.add_test(desc, DynBenchAsTestFn(benchfn)); } } StaticBenchFn(benchfn) => { if opts.bench_benchmarks { filtered.add_bench(desc, StaticBenchFn(benchfn)); } else { filtered.add_test(desc, StaticBenchAsTestFn(benchfn)); } </del> <ins> DynBenchFn(_) | StaticBenchFn(_) => { filtered.add_bench(desc, test.testfn); </ins> } testfn => { filtered.add_test(desc, testfn);

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:
<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for functions --> $DIR/method-argument-mismatch-variance-ice-119867.rs:8:23 | LL |     fn deserialize(s: _) {} |                       ^ not allowed in type signatures | help: try replacing `_` with the type in the corresponding trait method signature | LL |     fn deserialize(s: &ArchivedVec<T>) {} |                       ~~~~~~~~~~~~~~~ error[E0186]: method `deserialize` has a `&self` declaration in the trait, but not in the impl --> $DIR/method-argument-mismatch-variance-ice-119867.rs:8:5 | LL |     fn deserialize(&self); |     ---------------------- `&self` used in trait ... LL |     fn deserialize(s: _) {} |     ^^^^^^^^^^^^^^^^^^^^ expected `&self` in impl error: aborting due to 2 previous errors Some errors have detailed explanations: E0121, E0186. For more information about an error, try `rustc --explain E0121`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: unexpected region encountered in variance inference: ReLateParam(DefId(0:22 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::{impl}::deserialize), BrNamed(DefId(0:27 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::Deserialize::deserialize::'), '))', 'error: internal compiler error: unexpected region encountered in variance inference: ReLateParam(DefId(0:22 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::{impl}::deserialize), BrNamed(DefId(0:27 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::Deserialize::deserialize::'), '))' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc
Minimized:
Change:
<ins> error[E0596]: cannot borrow `x` as mutable, as it is not declared as mutable --> $DIR/issue-61452.rs:5:5 | LL | pub async fn f(x: Option<usize>) { |                - help: consider changing this to be mutable: `mut x` LL |     x.take(); |     ^ cannot borrow as mutable error[E0384]: cannot assign twice to immutable variable `x` --> $DIR/issue-61452.rs:10:5 | LL | pub async fn g(x: usize) { |                - |                | |                first assignment to `x` |                help: make this binding mutable: `mut x` LL |     x += 1; |     ^^^^^^ cannot assign twice to immutable variable error: aborting due to 2 previous errors Some errors have detailed explanations: E0384, E0596. For more information about an error, try `rustc --explain E0384`. </ins>

Discussion:
ICE when some lints fail on an async-fn. Make the xs mutable and no ICE. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-async-await C-bug I-ICE
Discussed in async-await meeting. Marking as blocking as this looks pretty bad for the user experience. Hopefully an easy fix. Presumably in the desugared form we are somehow failing because the keyword is missing or something like that.
claim
Change:
<ins> // compile-flags: -Zunstable-options --html-no-source // This test ensures that the `--html-no-source` flag disables // the creation of the `src` folder. #![feature(staged_api)] #![stable(feature = "bar", since = "1.0")] #![crate_name = "foo"] // Ensures that there is no items in the corresponding "src" folder. // @files 'src/foo' '[]' // @has foo/fn.foo.html // @has - '//div[@class="main-heading"]/*[@class="out-of-band"]' '1.0 · ' // @!has - '//div[@class="main-heading"]/*[@class="out-of-band"]' '1.0 · source · ' #[stable(feature = "bar", since = "1.0")] pub fn foo() {} // @has foo/struct.Bar.html // @has - '//div[@class="main-heading"]/*[@class="out-of-band"]' '1.0 · ' // @!has - '//div[@class="main-heading"]/*[@class="out-of-band"]' '1.0 · source · ' #[stable(feature = "bar", since = "1.0")] pub struct Bar; impl Bar { // @has - '//*[@id="method.bar"]/*[@class="since rightside"]' '2.0' // @!has - '//*[@id="method.bar"]/*[@class="rightside"]' '2.0 ·' #[stable(feature = "foobar", since = "2.0")] pub fn bar() {} } </ins>

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
# example. #ninja = false <ins> # LLVM targets to build support for. # Note: this is NOT related to Rust compilation targets. However, as Rust is # dependent on LLVM for code generation, turning targets off here WILL lead to # the resulting rustc being unable to compile for the disabled architectures. # Also worth pointing out is that, in case support for new targets are added to # LLVM, enabling them here doesn't mean Rust is automatically gaining said # support. You'll need to write a target specification at least, and most # likely, teach rustc about the C ABI of the target. Get in touch with the # Rust team and file an issue if you need assistance in porting! #targets = "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc" </ins> # ============================================================================= # General build configuration options # =============================================================================

Discussion:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.
Change:
use middle::ty; use middle::typeck; use util::common::indenter; <del> use util::ppaux::{Repr, ty_to_str}; </del> <ins> use util::ppaux::Repr; </ins> use middle::trans::type_::Type;

Discussion:
Configured with
I found that does not properly emit some information for android assembler. keep digging do you have any idea to fix this ?
some symbol starts with which arm as cannot recognize it [error] [orig]
Ok, I know what the issue is now. I changed the naming of the vtables, since they are internal, in order to make it easier to debug. So they now have the type attached. Apparently the 's don't get changed the same way the '<' and ''s do. I'll get on it.
works with below patch