jiebi/CodeConvo huggingface dataset:
Code change:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

Related discussion:
text: _ => None }; if let Some(def_id) = maybe_def_id { <del> fn_warned = check_must_use(cx, def_id, s.span, "return value of ", ""); </del> <ins> fn_warned = check_must_use_def(cx, def_id, s.span, "return value of ", ""); </ins> } else if type_permits_lack_of_use { // We don't warn about unused unit or uninhabited types. // (See https://github.com/rust-lang/rust/issues/43806 for details.)
Code change:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

Related discussion:
text: if attr.check_name(sym::must_use) { let msg = format!("unused {}`{}`{} that must be used", descr_pre_path, cx.tcx.def_path_str(def_id), descr_post_path); <del> let mut err = cx.struct_span_lint(UNUSED_MUST_USE, sp, &msg); </del> <ins> let mut err = cx.struct_span_lint(UNUSED_MUST_USE, span, &msg); </ins> // check for #[must_use = "..."] if let Some(note) = attr.value_str() { err.note(&note.as_str());
Code change:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

Related discussion:
text: <ins> #![deny(unused_must_use)] fn foo() -> (Result<(), ()>, ()) { (Ok::<(), ()>(()), ()) } fn main() { (Ok::<(), ()>(()),); //~ ERROR unused `std::result::Result` (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); //~^ ERROR unused `std::result::Result` //~^^ ERROR unused `std::result::Result` foo(); //~ ERROR unused `std::result::Result` ((Err::<(), ()>(()), ()), ()); //~ ERROR unused `std::result::Result` } </ins>
Code change:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

Related discussion:
text: <ins> error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:8:6 | LL |     (Ok::<(), ()>(()),); |      ^^^^^^^^^^^^^^^^ | note: lint level defined here --> $DIR/must_use-tuple.rs:1:9 | LL | #![deny(unused_must_use)] |         ^^^^^^^^^^^^^^^ = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:10:6 | LL |     (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); |      ^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 2 that must be used --> $DIR/must_use-tuple.rs:10:27 | LL |     (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); |                           ^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:14:5 | LL |     foo(); |     ^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:16:6 | LL |     ((Err::<(), ()>(()), ()), ()); |      ^^^^^^^^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: aborting due to 5 previous errors </ins>
Code change:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

Related discussion:
text: self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }
Code change:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>
Code change:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>
Code change:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

Related discussion:
text: <ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>
Code change:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

Related discussion:
text: <ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>
Code change:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>
Code change:
Unit tests should not be doing multi-second sleeps as this is bad for turnaround during development.
Fair enough, I will try to get around to looking at this.
Done.

Related discussion:
text: p.destroy(); // ...and nor should this (and nor should the destructor) } <del> #[cfg(unix)] // there is no way to sleep on windows from inside libcore... </del> fn test_destroy_actually_kills(force: bool) { <del> let path = Path(fmt!("test/core-run-test-destroy-actually-kills-%?.tmp", force)); os::remove_file(&path); </del> <ins> #[cfg(unix)] static BLOCK_COMMAND: &'static str = "cat"; </ins> <del> let cmd = fmt!("sleep 5 && echo MurderDeathKill > %s", path.to_str()); let mut p = run::start_program("sh", [~"-c", cmd]); </del> <ins> #[cfg(windows)] static BLOCK_COMMAND: &'static str = "cmd"; </ins> <del> p.destroy(); // destroy the program before it has a chance to echo its message </del> <ins> #[cfg(unix)] fn process_exists(pid: libc::pid_t) -> bool { run::program_output("ps", [~"-p", pid.to_str()]).out.contains(pid.to_str()) } </ins> <del> unsafe { // wait to ensure the program is really destroyed and not just waiting itself libc::sleep(10); </del> <ins> #[cfg(windows)] fn process_exists(pid: libc::pid_t) -> bool { use libc::types::os::arch::extra::DWORD; use libc::funcs::extra::kernel32::{CloseHandle, GetExitCodeProcess, OpenProcess}; use libc::consts::os::extra::{FALSE, PROCESS_QUERY_INFORMATION, STILL_ACTIVE }; unsafe { let proc = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid as DWORD); if proc.is_null() { return false; } // proc will be non-null if the process is alive, or if it died recently let mut status = 0; GetExitCodeProcess(proc, &mut status); CloseHandle(proc); return status == STILL_ACTIVE; } </ins> } <del> // the program should not have had chance to echo its message assert!(!path.exists()); </del> <ins> // this program will stay alive indefinitely trying to read from stdin let mut p = run::start_program(BLOCK_COMMAND, []); assert!(process_exists(p.get_id())); if force { p.force_destroy(); } else { p.destroy(); } assert!(!process_exists(p.get_id())); </ins> } #[test] <del> #[cfg(unix)] </del> fn test_unforced_destroy_actually_kills() { test_destroy_actually_kills(false); } #[test] <del> #[cfg(unix)] </del> fn test_forced_destroy_actually_kills() { test_destroy_actually_kills(true); }
Code change:
Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:

Related discussion:
text: <ins> // This previously triggered an ICE. pub(in crate::r#mod) fn main() {} //~^ ERROR expected module, found unresolved item </ins>
Code change:
Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:

Related discussion:
text: <ins> error[E0577]: expected module, found unresolved item `crate::r#mod` --> $DIR/issue-61732.rs:3:8 | LL | pub(in crate::r#mod) fn main() {} |        ^^^^^^^^^^^^ not a module error: Compilation failed, aborting rustdoc error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0577`. </ins>
Code change:
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!

Related discussion:
text: let mut indirect_outputs = vec![]; for (i, (out, &place)) in ia.outputs.iter().zip(&outputs).enumerate() { if out.is_rw { <del> inputs.push(self.load_operand(place).immediate()); </del> <ins> let operand = self.load_operand(place); if let OperandValue::Immediate(_) = operand.val { inputs.push(operand.immediate()); } </ins> ext_constraints.push(i.to_string()); } if out.is_indirect { <del> indirect_outputs.push(self.load_operand(place).immediate()); </del> <ins> let operand = self.load_operand(place); if let OperandValue::Immediate(_) = operand.val { indirect_outputs.push(operand.immediate()); } </ins> } else { output_types.push(place.layout.llvm_type(self.cx())); }
Code change:
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!

Related discussion:
text: <ins> // build-fail // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm!("nop" : "+r"("r15")); //~^ malformed inline assembly } } </ins>
Code change:
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!

Related discussion:
text: <ins> error[E0668]: malformed inline assembly --> $DIR/issue-62046.rs:8:9 | LL |         asm!("nop" : "+r"("r15")); |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0668`. </ins>
Code change:
Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?

Related discussion:
text: <ins> // check-pass struct Foo { foo: Option<&'static Foo> } static FOO: Foo = Foo { foo: Some(&FOO), }; fn main() {} </ins>