jiebi/CodeConvo huggingface dataset:
Code change:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)

Related discussion:
text: } } diag.emit(); ty::Binder::bind(fn_sig) } None => AstConv::ty_of_fn(
Code change:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)

Related discussion:
text: const D: _ = 42; //~^ ERROR the type placeholder `_` is not allowed within types on item signatures } <ins> fn map<T>(_: fn() -> Option<&'static T>) -> Option<T> { None } fn value() -> Option<&'static _> { //~^ ERROR the type placeholder `_` is not allowed within types on item signatures Option::<&'static u8>::None } const _: Option<_> = map(value); //~^ ERROR the type placeholder `_` is not allowed within types on item signatures </ins>
Code change:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)

Related discussion:
text: |                         -^ |                         || |                         |not allowed in type signatures <del> |                         help: replace with the correct return type: `&&usize` </del> <ins> |                         help: replace with the correct return type: `&'static &'static usize` </ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/typeck_type_placeholder_item.rs:52:52
Code change:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)

Related discussion:
text: |                     ^ not allowed in type signatures error[E0121]: the type placeholder `_` is not allowed within types on item signatures <ins> --> $DIR/typeck_type_placeholder_item.rs:216:31 | LL | fn value() -> Option<&'static _> { |               ----------------^- |               |               | |               |               not allowed in type signatures |               help: replace with the correct return type: `Option<&'static u8>` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/typeck_type_placeholder_item.rs:221:10 | LL | const _: Option<_> = map(value); |          ^^^^^^^^^ |          | |          not allowed in type signatures |          help: replace `_` with the correct type: `Option<u8>` error[E0121]: the type placeholder `_` is not allowed within types on item signatures </ins> --> $DIR/typeck_type_placeholder_item.rs:140:31 | LL |     fn method_test1(&self, x: _);
Code change:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)

Related discussion:
text: |              not allowed in type signatures |              help: replace `_` with the correct type: `i32` <del> error: aborting due to 67 previous errors </del> <ins> error: aborting due to 69 previous errors </ins> Some errors have detailed explanations: E0121, E0282, E0403. For more information about an error, try `rustc --explain E0121`.
Code change:
() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim

Related discussion:
text: <ins> // run-rustfix #![allow(dead_code, unused_variables)] fn foo1(bar: &str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo2(_bar: &str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo3(_: &str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn main() {} </ins>
Code change:
() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim

Related discussion:
text: <ins> // run-rustfix #![allow(dead_code, unused_variables)] fn foo1(bar: str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo2(_bar: str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo3(_: str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn main() {} </ins>
Code change:
() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim

Related discussion:
text: <ins> error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-function-parameter.rs:5:9 | LL | fn foo1(bar: str) {} |         ^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = help: unsized fn params are gated as an unstable feature help: function arguments must have a statically known size, borrowed types always have a known size | LL | fn foo1(bar: &str) {} |              ^ error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-function-parameter.rs:11:9 | LL | fn foo2(_bar: str) {} |         ^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = help: unsized fn params are gated as an unstable feature help: function arguments must have a statically known size, borrowed types always have a known size | LL | fn foo2(_bar: &str) {} |               ^ error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-function-parameter.rs:17:9 | LL | fn foo3(_: str) {} |         ^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = help: unsized fn params are gated as an unstable feature help: function arguments must have a statically known size, borrowed types always have a known size | LL | fn foo3(_: &str) {} |            ^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details

Related discussion:
text: let dl = self.data_layout(); let pack = repr.pack; if pack.is_some() && repr.align.is_some() { <del> bug!("struct cannot be packed and aligned"); </del> <ins> self.tcx.sess.delay_span_bug(DUMMY_SP, "struct cannot be packed and aligned"); return Err(LayoutError::Unknown(ty)); </ins> } let mut align = if pack.is_some() { dl.i8_align } else { dl.aggregate_align };
Code change:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details

Related discussion:
text: if def.is_union() { if def.repr.pack.is_some() && def.repr.align.is_some() { <del> bug!("union cannot be packed and aligned"); </del> <ins> self.tcx.sess.delay_span_bug( tcx.def_span(def.did), "union cannot be packed and aligned", ); return Err(LayoutError::Unknown(ty)); </ins> } let mut align =
Code change:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details

Related discussion:
text: i: i32, } <ins> #[repr(packed, align(0x100))] pub struct S(u16); //~ ERROR type has conflicting packed and align representation hints #[repr(packed, align(0x100))] pub union U { //~ ERROR type has conflicting packed and align representation hints u: u16 } static B: U = U { u: 0 }; static A: S = S(0); </ins> fn main() {}
Code change:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details

Related discussion:
text: LL | | } | |_^ <del> error: aborting due to 10 previous errors </del> <ins> error[E0587]: type has conflicting packed and align representation hints --> $DIR/conflicting-repr-hints.rs:70:1 | LL | pub struct S(u16); | ^^^^^^^^^^^^^^^^^^ error[E0587]: type has conflicting packed and align representation hints --> $DIR/conflicting-repr-hints.rs:73:1 | LL | / pub union U { LL | |     u: u16 LL | | } | |_^ error: aborting due to 12 previous errors </ins> Some errors have detailed explanations: E0566, E0587, E0634. For more information about an error, try `rustc --explain E0566`.
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 tried this code: I expected to see this happen: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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<summaryBacktrace</summary<p</p</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.

Related discussion:
text: #[unstable(feature = "str_internals", issue = "none")] pub use validations::next_code_point; <ins> #[unstable(feature = "str_internals", issue = "none")] pub use validations::utf8_char_width; </ins> use iter::MatchIndicesInternal; use iter::SplitInternal; use iter::{MatchesInternal, SplitNInternal};