jiebi/CodeConvo huggingface dataset:
Change:
error[E0308]: mismatched types <del> --> $DIR/return-ty-mismatch-note.rs:4:6 </del> <ins> --> $DIR/return-ty-mismatch-note.rs:5:6 </ins> | LL | fn f<T>() -> (T,) { |      - expected this type parameter

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
<ins> //@ check-pass #![feature(trivial_bounds)] #![allow(trivial_bounds)] // Make sure that we still use the where-clauses from the struct when checking // if it may implement `Copy` unconditionally. // Fix for <https://github.com/rust-lang/rust/issues/125394>. pub trait Foo { type Assoc; } pub struct Bar; // This needs to be public pub struct Baz2(<Bar as Foo>::Assoc) where Bar: Foo; fn main() {} </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. --This appears to be an issue in the lint, possibly it assuming can be normalized, when due to the bound and the lack of implementation , the type is effectively <!-- 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. --: locally <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Still crashes with , although the Ice is a bit different.
I would appreciate if you opened a new issue for that, and shared the backtrace, etc there instead.
Change:
terminator.kind = TerminatorKind::Goto { target: destination_block }; } <del> fn combine_duplicate_switch_targets(&self, terminator: &mut Terminator<'tcx>) { let TerminatorKind::SwitchInt { targets, .. } = &mut terminator.kind else { return }; let otherwise = targets.otherwise(); if targets.iter().any(|t| t.1 == otherwise) { *targets = SwitchTargets::new( targets.iter().filter(|t| t.1 != otherwise), targets.otherwise(), ); } } </del> fn combine_intrinsic_assert( &self, terminator: &mut Terminator<'tcx>,

Discussion:
<!-- 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. --I tried this code: I expected to see this happen: no branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
|        ^^^^^^^^^^^^^^ pattern `(_, _)` not covered | = note: the matched value is of type `(usize, bool)` <ins> = note: `usize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `usize` matching </ins> help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown | LL |         match $s { $($t)+ => {}, (_, _) => todo!() }

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
<ins> // #120427 // This test checks that when a single cfg has a value for user's specified name // suggest to use `#[cfg(target_os = "linux")]` instead of `#[cfg(linux)]` // // check-pass // compile-flags: -Z unstable-options // compile-flags: --check-cfg=cfg() #[cfg(linux)] //~^ WARNING unexpected `cfg` condition name: `linux` fn x() {} // will not suggest if the cfg has a value #[cfg(linux = "os-name")] //~^ WARNING unexpected `cfg` condition name: `linux` fn y() {} fn main() {} </ins>

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
<ins> // Check that AST json printing works. #![crate_type = "lib"] // check-pass // compile-flags: -Zast-json-noexpand // normalize-stdout-test ":d+" -> ":0" // Only include a single item to reduce how often the test output needs // updating. extern crate core; </ins>

Discussion:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim
Change:
// This takes much less time to build than all of Servo and supports stable Rust. packages: &["selectors"], }, <del> Test { name: "webrender", repo: "https://github.com/servo/webrender", sha: "a3d6e6894c5a601fa547c6273eb963ca1321c2bb", lock: None, packages: &[], }, </del> ]; fn main() {

Discussion:
Occasionally the builder fails due to a spurious build failure: The WebRender people prepared , but it did not land in yet. Once it lands, we'll need to update to point to the new commit. Putting it so we check in on it weekly during the infrastructure team meeting.
Discussed this at the infra meeting, there is a PR removing webrender. De-prioritizing.
Change:
<ins> error[E0284]: type annotations needed --> $DIR/issue-70082.rs:7:33 | LL |     let y: f64 = 0.01f64 * 1i16.into(); |                          -      ^^^^ |                          | |                          type must be known at this point | = note: cannot satisfy `<f64 as Mul<_>>::Output == f64` help: try using a fully qualified path to specify the expected types | LL |     let y: f64 = 0.01f64 * <i16 as Into<T>>::into(1i16); |                            +++++++++++++++++++++++    ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0284`. </ins>

Discussion:
I tried this code: () The error message: I expected to see this happen: The error is reported on the line for . Instead, this happened: The error is reported for the closure… Nighty, Beta and Stable affected.
modify labels: +A-diagnostics +C-bug +D-incorrect (someone other than the issue creator do this?)
More minimal repro: The closure just needs to be exist anywhere inside . Even this code reports the same error: Edit: this triggers the same issue:
This is essentially the same issue as
Change:
<ins> // check-pass trait Zero { const ZERO: Self; } impl Zero for i32 { const ZERO: Self = 0; } fn main() { match 1 { Zero::ZERO ..= 1 => {}, _ => {}, } } </ins>

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).
Change:
<del> Subproject commit 7a943a9dfcdca98e5988da6d0b7d2f83a364b5ba </del> <ins> Subproject commit 374db5c0b7a8ebc92ecb35ee21e11961da6c754d </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
// Otherwise proceed with linting. _ => {} } <del> let spans = inner .span .find_ancestor_inside(value.span) .map(|inner| (value.span.with_hi(inner.lo()), value.span.with_lo(inner.hi()))); </del> <ins> let spans = if !value.span.from_expansion() { inner .span .find_ancestor_inside(value.span) .map(|inner| (value.span.with_hi(inner.lo()), value.span.with_lo(inner.hi()))) } else { None }; </ins> self.emit_unused_delims(cx, value.span, spans, "pattern", keep_space, false); } }

Discussion:
This code: Creates this diagnostic: I ran (note that I created a local project called playground) which created this output: This told me to create an issue here. Going into more depth regarding the issue - the macro expands after one step like so: and we can see where the issue is: These parentheses are indeed fully removable, and it points to an issue in the macro definition. By changing to the compiler no longer emits the warning, because now it expands to which is properly recognized as a tuple with one element, rather than a type surrounded by redundant parentheses. Another way to fix it is to remove the outer parentheses in the macro call: which does compile without warnings, but breaks usage of the macro with tuples with more than two elements: as while its fine to remove the parentheses when there is only one element between the angle brackets ( to ), it is not fine when there are more than one element in the tuple ( to ). Importantly, the compiler still emits the unused parentheses warning and suggests their removal when the macro is called with three types when you haven't removed the parentheses (). Therefore, part of the issue is that rustc detects the problem, and assumes it can fix it by going straight to the macro and correcting it, neglecting previous expansions of the macro which require the currently redundant parentheses. I say part of the issue, because going back to the original diagnostic: rustc marks and as removable, and it suggests you do so: when the diagnostic should really only be suggesting the removal of the outer brackets. I'm not too sure why this one happens. Using Syn's terminology, my best guess is that it has something to do with the span of the outer parentheses including the inner and after expansion. : Also tried with nightly (had identical results):
Change:
<ins> error[E0425]: cannot find value `z` in this scope --> $DIR/fn-to-method-deeply-nested.rs:8:9 | LL |         z???????????????????????????????????????????????????????????????????????????????????????? |         ^ not found in this scope error[E0425]: cannot find function `e` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:13 | LL |     a(b(c(d(e( |             ^ not found in this scope error[E0425]: cannot find function `d` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:11 | LL |     a(b(c(d(e( |           ^ not found in this scope error[E0425]: cannot find function `c` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:9 | LL |     a(b(c(d(e( |         ^ not found in this scope error[E0425]: cannot find function `b` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:7 | LL |     a(b(c(d(e( |       ^ not found in this scope error[E0425]: cannot find function `a` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:5 | LL |     a(b(c(d(e( |     ^ not found in this scope error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0425`. </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. --<!-- 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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (
Change:
for (idx, (op, _)) in asm.operands.iter().enumerate() { match *op { hir::InlineAsmOperand::In { reg, ref expr } => { <del> self.check_asm_operand_type(idx, reg, expr, asm.template, None); </del> <ins> self.check_asm_operand_type(idx, reg, expr, asm.template, true, None); </ins> } hir::InlineAsmOperand::Out { reg, late: _, ref expr } => { if let Some(expr) = expr { <del> self.check_asm_operand_type(idx, reg, expr, asm.template, None); </del> <ins> self.check_asm_operand_type(idx, reg, expr, asm.template, false, None); </ins> } } hir::InlineAsmOperand::InOut { reg, late: _, ref expr } => { <del> self.check_asm_operand_type(idx, reg, expr, asm.template, None); </del> <ins> self.check_asm_operand_type(idx, reg, expr, asm.template, false, None); </ins> } hir::InlineAsmOperand::SplitInOut { reg, late: _, ref in_expr, ref out_expr } => { <del> let in_ty = self.check_asm_operand_type(idx, reg, in_expr, asm.template, None); </del> <ins> let in_ty = self.check_asm_operand_type(idx, reg, in_expr, asm.template, true, None); </ins> if let Some(out_expr) = out_expr { self.check_asm_operand_type( idx, reg, out_expr, asm.template, <ins> false, </ins> Some((in_expr, in_ty)), ); }

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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Somewhere during compilation of this code, LLVM's ). Because of that, rustccodegenllvm::asm::inlineasmcall , and the parent function then .
I a statement to log the function type and constraints string passed to LLVM:
claim
Change:
// Save the index of all fields regardless of their visibility in case // of error recovery. self.write_field_index(expr.hir_id, index); <ins> let adjustments = self.adjust_steps(&autoderef); </ins> if field.vis.is_accessible_from(def_scope, self.tcx) { <del> let adjustments = self.adjust_steps(&autoderef); </del> self.apply_adjustments(base, adjustments); self.register_predicates(autoderef.into_obligations()); self.tcx.check_stability(field.did, Some(expr.hir_id), expr.span, None); return field_ty; } <del> private_candidate = Some((base_def.did, field_ty)); </del> <ins> private_candidate = Some((adjustments, base_def.did, field_ty)); </ins> } } ty::Tuple(tys) => {

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. --<!-- 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. --: Also checked beta and nightly at : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.
Change:
<ins> // Copyright 2014 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. #[no_std]; #[lang="fail_"] fn fail(_: *i8, _: *i8, _: uint) -> ! { loop {} } #[no_mangle] pub extern "C" fn rust_stack_exhausted() {} </ins>

Discussion:
Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .
Change:
Some('/') => { self.bump(); self.bump(); // line comments starting with "///" or "//!" are doc-comments <del> if self.curr_is('/') || self.curr_is('!') { let start_bpos = self.pos - BytePos(3); while !self.is_eof() { match self.curr.unwrap() { 'n' => break, 'r' => { if self.nextch_is('n') { // CRLF break } else { self.err_span_(self.last_pos, self.pos, "bare CR not allowed in doc-comment"); } </del> <ins> let doc_comment = self.curr_is('/') || self.curr_is('!'); let start_bpos = if doc_comment { self.pos - BytePos(3) } else { self.last_pos - BytePos(2) }; while !self.is_eof() { match self.curr.unwrap() { 'n' => break, 'r' => { if self.nextch_is('n') { // CRLF break } else if doc_comment { self.err_span_(self.last_pos, self.pos, "bare CR not allowed in doc-comment"); </ins> } <del> _ => () </del> } <del> self.bump(); </del> <ins> _ => () </ins> } <del> return self.with_str_from(start_bpos, |string| { // but comments with only more "/"s are not </del> <ins> self.bump(); } return if doc_comment { self.with_str_from(start_bpos, |string| { // comments with only more "/"s are not doc comments </ins> let tok = if is_doc_comment(string) { token::DocComment(token::intern(string)) } else { token::Comment }; <del> return Some(TokenAndSpan{ </del> <ins> Some(TokenAndSpan { </ins> tok: tok, sp: codemap::mk_sp(start_bpos, self.last_pos) <del> }); }); </del> <ins> }) }) </ins> } else { <del> let start_bpos = self.last_pos - BytePos(2); while !self.curr_is('n') && !self.is_eof() { self.bump(); } return Some(TokenAndSpan { </del> <ins> Some(TokenAndSpan { </ins> tok: token::Comment, sp: codemap::mk_sp(start_bpos, self.last_pos) <del> }); </del> <ins> }) </ins> } } Some('*') => {

Discussion:
Image says it all really, running rustdoc on files with windows style line-endings inserts (or doesn't strip?) additional newline characters, screwing up alignment with the line numbers: ! This only seems to affect regular comments, doc comments are fine. Edit: since it's not really obvious from the image due to the nature of the bug, it should look like this: