jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2015 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. // `/**/` was previously regarded as a doc comment because it starts with `/**` and ends with `*/`. // This could break some internal logic that assumes the length of a doc comment is at least 5, // leading to an ICE. fn main() { println!(/**/); //~ ERROR unexpected end } </ins>

Discussion:
Output: Doesn't occur if the comment isn't empty.
Actually, that's being parsed as a doc comment (which you can see if you remove the macro invocation). This looks like a parsing bug of some kind.
Change:
} } <ins> pub fn type_is_vec(ty: t) -> bool { match get(ty).sty { ty_vec(..) => true, ty_ptr(mt{ty: t, ..}) | ty_rptr(_, mt{ty: t, ..}) | ty_box(t) | ty_uniq(t) => match get(t).sty { ty_vec(_, None) => true, _ => false }, _ => false } } </ins> pub fn type_is_structural(ty: t) -> bool { match get(ty).sty { ty_struct(..) | ty_tup(_) | ty_enum(..) | ty_closure(_) |

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
} if !segments.iter().all(|(name, args)| { let arg = match name.as_str() { <del> "struct_span_err" | "span_note" | "span_label" | "span_help" => &args[1], "note" | "help" => &args[0], </del> <ins> "struct_span_err" | "span_note" | "span_label" | "span_help" if args.len() == 2 => { &args[1] } "note" | "help" if args.len() == 1 => &args[0], </ins> _ => { return false; }

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 --
I've seen this on a few ICE reports, but I'd recommend putting the first ICE in the title instead of any other subsequent ICE messages, since this: really is the root cause of this issue, and the second one (mentioning ) is just a side-effect of panicking during certain queries :smilecat:
searched toolchains nightly-2023-04-21 through nightly-2023-05-06 Regression in nightly-2023-04-27 Regression in Regression in cc
Oops claim
Change:
} } #[stable(feature = "inherent_ascii_escape", since = "1.60.0")] <del> impl<'a> iter::ExactSizeIterator for EscapeAscii<'a> {} #[stable(feature = "inherent_ascii_escape", since = "1.60.0")] </del> impl<'a> iter::FusedIterator for EscapeAscii<'a> {} #[stable(feature = "inherent_ascii_escape", since = "1.60.0")] impl<'a> fmt::Display for EscapeAscii<'a> {

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. --I tried this code: I expected the length of the iterator. Instead, panic: <!-- 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<summaryMy first suspicion would be the sizehint() on the iterator. It also happens in no_std. </summary<pStacktrace: </p</details
This is pretty unfortunate. This type should not implement , but it has for a few stable versions now :( See also (the original tracking issue) and (the PR that it)
Nominating for discussion whether the stabilization should be reverted, the crater run should be expedited and perhaps beta-backported.
I would prefer stabilization to be reverted as there is additional book-keeping required to implement .
We discussed this briefly in the libs-api meeting last week. Reverting it seems okay, even though it's technically a breaking change. It seems like nothing relies on it, as they would have gotten panics anyway. The crater run seems to confirm that.
Thanks for getting the fix for this merged everybody.
Change:
<ins> #![feature(stmt_expr_attributes)] #![deny(unused_doc_comments)] macro_rules! mac { () => {} } /// foo //~ ERROR unused doc comment mac!(); fn foo() { /// a //~ ERROR unused doc comment let x = 12; /// multi-line //~ unused doc comment /// doc comment /// that is unused match x { /// c //~ ERROR unused doc comment 1 => {}, _ => {} } /// foo //~ ERROR unused doc comment unsafe {} #[doc = "foo"] //~ ERROR unused doc comment #[doc = "bar"] //~ ERROR unused doc comment 3; /// bar //~ ERROR unused doc comment mac!(); let x = /** comment */ 47; //~ ERROR unused doc comment /// dox //~ ERROR unused doc comment { } } fn main() { foo(); } </ins>

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
if text.is_empty() { self.span_bug(sp, "found empty literal suffix in Some") } <del> self.struct_span_err(sp, &format!("suffixes on {} are invalid", kind)) .span_label(sp, format!("invalid suffix `{}`", text)) .emit(); </del> <ins> let mut err = if kind == "a tuple index" && ["i32", "u32", "isize", "usize"].contains(&text.to_string().as_str()) { // #59553: warn instead of reject out of hand to allow the fix to percolate // through the ecosystem when people fix their macros let mut err = self.struct_span_warn( sp, &format!("suffixes on {} are invalid", kind), ); err.note(&format!( "`{}` is *temporarily* accepted on tuple index fields as it was  incorrectly accepted on stable for a few releases", text, )); err.help( "on proc macros, you'll want to use `syn::Index::from` or  `proc_macro::Literal::*_unsuffixed` for code that will desugar  to tuple field access", ); err.note( "for more context, see https://github.com/rust-lang/rust/issues/60210", ); err } else { self.struct_span_err(sp, &format!("suffixes on {} are invalid", kind)) }; err.span_label(sp, format!("invalid suffix `{}`", text)); err.emit(); </ins> } } }

Discussion:
from a crater run: crate affected: interact (0.3.3), named-tuple (0.1.2), photonix (0.1.1), serdetuple (0.2.2), susy-codec (3.1.0), thrift (0.12.0), zeroize (0.6.0) authors: logs: https://crater- https://crater- https://crater- https://crater- https://crater- https://crater-, https://crater- probable duplicate of
cc
thrift and zeroize are the regressions that are most notable here; the others don't have notable reverse dependencies.
Change:
match rvalue { Rvalue::NullaryOp(NullOp::UbChecks, _) => Some((tcx.sess.ub_checks() as u128, targets)), Rvalue::Use(Operand::Constant(constant)) => { <del> let bits = eval_mono_const(constant); </del> <ins> let bits = eval_mono_const(constant)?; </ins> Some((bits, targets)) } _ => 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. --I encountered an ICE while playing with 's that has to do with its comptime assertions. I have not been able to reproduce the ICE when inlining the constant value in which the checks are performed. Perhaps it is related with the fact that originally there was a crate boundary? I have an inkling const blocks' merger might be to blame. <!-- 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
It would be useful to have a minimal example that doesn't involve the entire tagged_ptr crate.
Reduced: , needs This bisects to cc label A-monomorphization S-has-mcve -E-needs-mcve
ye olde "compiler must not crash on invalid code" problem
PR with a fix is up. Thanks for catching this before the bug hit beta
No, thanks to you all for not only fixing it, but running this amazing project every day. I hope I have more time in the future so that I can spend it here and be a part of this.
Change:
} }; if self.can_coerce(ref_ty, expected) { <del> if let Ok(src) = cm.span_to_snippet(sp) { </del> <ins> let mut sugg_sp = sp; if let hir::ExprKind::MethodCall(segment, _sp, args) = &expr.node { let clone_trait = self.tcx.lang_items().clone_trait().unwrap(); if let ([arg], Some(true), "clone") = ( &args[..], self.tables.borrow().type_dependent_def_id(expr.hir_id).map(|did| { let ai = self.tcx.associated_item(did); ai.container == ty::TraitContainer(clone_trait) }), &segment.ident.as_str()[..], ) { // If this expression had a clone call when suggesting borrowing // we want to suggest removing it because it'd now be unecessary. sugg_sp = arg.span; } } if let Ok(src) = cm.span_to_snippet(sugg_sp) { </ins> let needs_parens = match expr.node { // parenthesize if needed (Issue #46756) hir::ExprKind::Cast(_, _) |

Discussion:
On type mismatch with a suggestion to borrow in order to dereference a into a , we should notice unnecessary calls: and suggest their removal: From
Change:
<ins> #[diagnostic::on_unimplemented(aa = "broken")] pub trait Test {} </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. --The simplest version uses / however I have also tested this via a sub-crate. : : <!-- 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. --: I can also reproduce this on and on and . When running <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(const_fn)] </ins> const FOO: isize = 10; const BAR: isize = 3; <ins> const fn foo() -> isize { 4 } const BOO: isize = foo(); </ins> pub fn main() { let x: isize = 3; let y = match x { FOO => 1, BAR => 2, <ins> BOO => 4, </ins> _ => 3 }; assert_eq!(y, 2);

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in
Change:
<del> Subproject commit 10bf331d4d1280d773045e57d65031969c51dec6 </del> <ins> Subproject commit 5fde462d8c53b86840100a927a17c8353bba3e3f </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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.
triage: P-medium. Removing nomination.
Change:
let ai = &self.expected_indices; let ii = &self.provided_indices; <ins> // Issue: 100478, when we end the iteration, // `next_unmatched_idx` will point to the index of the first unmatched let mut next_unmatched_idx = 0; </ins> for i in 0..cmp::max(ai.len(), ii.len()) { <del> // If we eliminate the last row, any left-over inputs are considered missing </del> <ins> // If we eliminate the last row, any left-over arguments are considered missing </ins> if i >= mat.len() { <del> return Some(Issue::Missing(i)); </del> <ins> return Some(Issue::Missing(next_unmatched_idx)); </ins> } <del> // If we eliminate the last column, any left-over arguments are extra </del> <ins> // If we eliminate the last column, any left-over inputs are extra </ins> if mat[i].len() == 0 { <del> return Some(Issue::Extra(i)); </del> <ins> return Some(Issue::Extra(next_unmatched_idx)); </ins> } // Make sure we don't pass the bounds of our matrix

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. --I tried this code: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
let (lo, hi) = self.is_valid_span(sp)?; assert!(hi.line >= lo.line); <ins> if sp.is_dummy() { return Ok(FileLines { file: lo.file, lines: Vec::new() }); } </ins> let mut lines = Vec::with_capacity(hi.line - lo.line + 1); // The span starts partway through the first line,

Discussion:
Problem returns invalid span data, particularly and are set to 0, though . This happens with a completly empty file. Tested on the following cargo version: Whilst on the stable version the returned span array is empty: Steps Now you can see invalid span in file. I've already created and formatted and files with the output of different cargo versions. Here are the crutial differences and Context
Moved to rust-lang/rust, where diagnostics live. Seems to be caused by , cc
additional info: The regression is also present on the older version of nightly rustc: This was the version where I initially spotted the issue, then updated and rechecked, but it was still present in .
Probably caused by
triage: P-high. Assigning to self.
Change:
} fn visit_ty(&mut self, t: &'ast Ty) { <del> match t.kind { </del> <ins> match &t.kind { TyKind::Path(None, _) => { // We can sometimes encounter bare trait objects // which are represented in AST as paths. if let Some(partial_res) = self.resolver.get_partial_res(t.id) && let Some(Res::Def(DefKind::Trait | DefKind::TraitAlias, _)) = partial_res.full_res() { self.current_binders.push(t.id); visit::walk_ty(self, t); self.current_binders.pop(); } else { visit::walk_ty(self, t); } } </ins> TyKind::BareFn(_) => { self.current_binders.push(t.id); visit::walk_ty(self, t);

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
This is not an RPITIT bug, for the record.
Change:
pub fn crate_type_allows_lto(crate_type: CrateType) -> bool { match crate_type { <del> CrateType::Executable | CrateType::Dylib | CrateType::Staticlib | CrateType::Cdylib => true, CrateType::Rlib | CrateType::ProcMacro => false, </del> <ins> CrateType::Executable | CrateType::Dylib | CrateType::Staticlib | CrateType::Cdylib | CrateType::ProcMacro => true, CrateType::Rlib => false, </ins> } }

Discussion:
I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact: I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue. Here is the I used: It seems that is enabling LTO for proc-macro crates, but only when cross-compiling?
sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.
I haven't had time to look into this, no. You can always disable LTO as a workaround.
This problem also appears when just the vendor of the target tripple changes (i.e. ).
Thank you for the additional feedback, will look into this issue in couple weeks.
Change:
} } <ins> impl fmt::Debug for Repr { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { match self { &Repr::Os(ref code) => fmt.debug_struct("Os").field("code", code) .field("message", &sys::os::error_string(*code)).finish(), &Repr::Custom(ref c) => fmt.debug_tuple("Custom").field(c).finish(), } } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl fmt::Display for Error { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {

Discussion:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.
Change:
<ins> error: this file contains an unclosed delimiter --> $DIR/issue-81827.rs:11:27 | LL | fn r()->i{0|{#[cfg(r(0{]0 |          -  -             ^ |          |  | |          |  unclosed delimiter |          unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-81827.rs:11:27 | LL | fn r()->i{0|{#[cfg(r(0{]0 |          -  -             ^ |          |  | |          |  unclosed delimiter |          unclosed delimiter error: mismatched closing delimiter: `]` --> $DIR/issue-81827.rs:11:23 | LL | fn r()->i{0|{#[cfg(r(0{]0 |               -       ^^ mismatched closing delimiter |               |       | |               |       unclosed delimiter |               closing delimiter possibly meant for this error: expected one of `)` or `,`, found `{` --> $DIR/issue-81827.rs:11:23 | LL | fn r()->i{0|{#[cfg(r(0{]0 |                       ^ expected one of `)` or `,` 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. --I think this issue is more than an internal compiler error, so I report here. I tried this code: The md5 of is: I expected to see this happen: normal compilation Instead, this happened: rustc crashes <!-- 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. --I test it on nightly, beta, and stable versions. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I am not sure whether it is a security-oriented bug. If so, please close this. But I guess it is ok to be public. Thanks.
This is an explicit : So just an ICE, just somebody used an instead of a .
is the that's being executed.
The problem is that the parsing code is attempting to emit a fatal error, but error emission cannot happen through the function. The stack looks something like this: Two potential fixes here: adjust so that it does not abort on panics or make anything running within the incapable of panicking. The latter is way harder and more prone to eventually break again. I think this is probably P-medium or thereabouts.
It seems like the implementation of is copied from [][1]'s : [1]:
Would this be safe? My understanding is if the callback panics then the pointer will potentially be in an inconsistent state and continuing execution will not be safe.
Well, not in the exact form it is now, but there are a couple avenues that could be explored to make it more resilient to closure panics – e.g. one could replace the old value with some sort of placeholder default while the original value is being processed.
Another test-case. Hope it can help. .
Assigning as discussed as part of the and removing .
No longer crashes due to
Change:
if i > 0 { result.push_str("::"); } <ins> if Ident::with_dummy_span(*name).is_raw_guess() { result.push_str("r#"); } </ins> result.push_str(&name.as_str()); } result } fn path_names_to_string(path: &Path) -> String { <del> names_to_string(&path.segments.iter() .map(|seg| seg.ident.name) .collect::<Vec<_>>()) </del> <ins> names_to_string(&path.segments.iter().map(|seg| seg.ident.name).collect::<Vec<_>>()) </ins> } /// A somewhat inefficient routine to obtain the name of a module.

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
<ins> fn foo() { let x: usize<foo>; //~ ERROR const arguments are not allowed for this type } 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. --<!-- 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 --
Reduced:
This doesn't ICE on 1.46. modify labels: +regression-from-stable-to-stable
We decided to label this as it's unlikely to be hit, it used to be an error in a previous release. Also, it's very esoteric code.
Line triggered the ICE: Regressed in , cc fyi Note that the snippet doesn't have to contain : <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Will look into this in a few weeks so I am claiming this for now so I don't forget. claim If anyone else wants to work on this before that feel free to do so, don't have much time rn
The solution might be as simple as merging the linked match arm with the previous error one, making this a delayspanbug and ignoring it.
I just saw this issue and thought the same thing. I'm testing the fix now.