jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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 ICE is related to : <!-- 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</detailsIdeally, would compile, but generic associated types in trait paths are currently not implemented. Maybe rustc could give a nice error message when the is missing.
Duplicate to and related heavily to others. But this has a nice minimal repro, so worth leaving open. Probably fixed by .
I've tested this locally and I can confirm that fixes this (with this change: ).

Related discussion:
text: <ins> error[E0107]: missing generics for associated type `C::DType` --> $DIR/issue-81712-cyclic-traits.rs:14:10 | LL |     type DType<T>: D<T, CType = Self>; |          ^^^^^ expected 1 type argument | note: associated type defined here, with 1 type parameter: `T` --> $DIR/issue-81712-cyclic-traits.rs:14:10 | LL |     type DType<T>: D<T, CType = Self>; |          ^^^^^ - help: use angle brackets to add missing type argument | LL |     type DType<T><T>: D<T, CType = Self>; |               ^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </ins>
Code change:
<!-- 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

Related discussion:
text: <ins> // error-pattern: this file contains an unclosed delimiter // error-pattern: mismatched closing delimiter: `]` // error-pattern: expected one of `)` or `,`, found `{` #![crate_name="0"] fn main() {} fn r()->i{0|{#[cfg(r(0{]0 </ins>
Code change:
<!-- 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

Related discussion:
text: <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>
Code change:
<!-- 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 code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

Related discussion:
text: }; let last_expr_ty = self.node_ty(last_expr.hir_id); let needs_box = match (last_expr_ty.kind(), expected_ty.kind()) { <ins> (ty::Opaque(last_def_id, _), ty::Opaque(exp_def_id, _)) if last_def_id == exp_def_id => { StatementAsExpression::CorrectType } </ins> (ty::Opaque(last_def_id, last_bounds), ty::Opaque(exp_def_id, exp_bounds)) => { debug!( "both opaque, likely future {:?} {:?} {:?} {:?}", last_def_id, last_bounds, exp_def_id, exp_bounds ); <del> let last_hir_id = self.tcx.hir().local_def_id_to_hir_id(last_def_id.expect_local()); let exp_hir_id = self.tcx.hir().local_def_id_to_hir_id(exp_def_id.expect_local()); </del> <ins> let (last_local_id, exp_local_id) = match (last_def_id.as_local(), exp_def_id.as_local()) { (Some(last_hir_id), Some(exp_hir_id)) => (last_hir_id, exp_hir_id), (_, _) => return None, }; let last_hir_id = self.tcx.hir().local_def_id_to_hir_id(last_local_id); let exp_hir_id = self.tcx.hir().local_def_id_to_hir_id(exp_local_id); </ins> match ( &self.tcx.hir().expect_item(last_hir_id).kind, &self.tcx.hir().expect_item(exp_hir_id).kind,
Code change:
<!-- 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 code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

Related discussion:
text: <ins> // edition:2018 pub struct Test {} impl Test { pub async fn answer_str(&self, _s: &str) -> Test { Test {} } } </ins>
Code change:
<!-- 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 code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

Related discussion:
text: <ins> // aux-build:issue-81839.rs // edition:2018 extern crate issue_81839; async fn test(ans: &str, num: i32, cx: &issue_81839::Test) -> u32 { match num { 1 => { cx.answer_str("hi"); } _ => cx.answer_str("hi"), //~ `match` arms have incompatible types } 1 } fn main() {} </ins>
Code change:
<!-- 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 code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

Related discussion:
text: <ins> error[E0308]: `match` arms have incompatible types --> $DIR/issue-81839.rs:11:14 | LL | /     match num { LL | |         1 => { LL | |             cx.answer_str("hi"); | |             -------------------- | |             |                  | | |             |                  help: consider removing this semicolon | |             this is found to be of type `()` LL | |         } LL | |         _ => cx.answer_str("hi"), | |              ^^^^^^^^^^^^^^^^^^^ expected `()`, found opaque type LL | |     } | |_____- `match` arms have incompatible types | ::: $DIR/auxiliary/issue-81839.rs:6:49 | LL |       pub async fn answer_str(&self, _s: &str) -> Test { |                                                   ---- the `Output` of this `async fn`'s found opaque type | = note:     expected type `()` found opaque type `impl Future` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
<!-- 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 code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim

Related discussion:
text: | LL |         false => async_dummy().await, |                               ^^^^^^ <del> help: consider removing this semicolon and boxing the expressions | LL |             Box::new(async_dummy()) LL | LL |         } LL |         false => Box::new(async_dummy()), </del> <ins> help: consider removing this semicolon </ins> | <ins> LL |             async_dummy() |                         -- </ins> error[E0308]: `match` arms have incompatible types --> $DIR/match-prev-arm-needing-semi.rs:39:18
Code change:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.

Related discussion:
text: struct_span_err!(tcx.sess, span, E0733, "recursion in an `async fn` requires boxing") .span_label(span, "recursive `async fn`") .note("a recursive `async fn` must be rewritten to return a boxed `dyn Future`") <ins> .note( "consider using the `async_recursion` crate: https://crates.io/crates/async_recursion", ) </ins> .emit(); }
Code change:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.

Related discussion:
text: |                  ^ recursive `async fn` | = note: a recursive `async fn` must be rewritten to return a boxed `dyn Future` <ins> = note: consider using the `async_recursion` crate: https://crates.io/crates/async_recursion </ins> error[E0733]: recursion in an `async fn` requires boxing --> $DIR/mutually-recursive-async-impl-trait-type.rs:9:18
Code change:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.

Related discussion:
text: |                  ^ recursive `async fn` | = note: a recursive `async fn` must be rewritten to return a boxed `dyn Future` <ins> = note: consider using the `async_recursion` crate: https://crates.io/crates/async_recursion </ins> error: aborting due to 2 previous errors
Code change:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.

Related discussion:
text: |                                        ^^ recursive `async fn` | = note: a recursive `async fn` must be rewritten to return a boxed `dyn Future` <ins> = note: consider using the `async_recursion` crate: https://crates.io/crates/async_recursion </ins> error: aborting due to previous error
Code change:
Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.

Related discussion:
text: } impl Attribute { <ins> #[inline] </ins> pub fn has_name(&self, name: Symbol) -> bool { match self.kind { AttrKind::Normal(ref item, _) => item.path == name,