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. --<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

Related discussion:
text: <ins> //@ check-pass #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use pub fn y<'a, U: 'a>() -> impl IntoIterator<Item = impl IntoIterator<Item = [u8; { 1 + 2 }]> + 'a> { [[[1, 2, 3]]] } // Make sure that the `predicates_of` for `{ 1 + 2 }` don't mention the duplicated lifetimes of // the *outer* iterator. Whether they should mention the duplicated lifetimes of the *inner* // iterator are another question, but not really something we need to answer immediately. 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. --<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

Related discussion:
text: <ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/double-opaque-parent-predicates.rs:3:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: use std::fs::File; use std::io; use std::iter; <ins> use std::mem::ManuallyDrop; </ins> use std::path::Path; use std::slice; use std::sync::Arc;
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: let llcx = llvm::LLVMRustContextCreate(cgcx.fewer_names); let llmod_raw = parse_module(llcx, module_name, thin_module.data(), &diag_handler)? as *const _; let mut module = ModuleCodegen { <del> module_llvm: ModuleLlvm { llmod_raw, llcx, tm }, </del> <ins> module_llvm: ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(tm) }, </ins> name: thin_module.name().to_string(), kind: ModuleKind::Regular, };
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: use std::any::Any; use std::ffi::CStr; use std::io::Write; <ins> use std::mem::ManuallyDrop; </ins> mod back { pub mod archive;
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: llcx: &'static mut llvm::Context, llmod_raw: *const llvm::Module, <del> // independent from llcx and llmod_raw, resources get disposed by drop impl tm: OwnedTargetMachine, </del> <ins> // This field is `ManuallyDrop` because it is important that the `TargetMachine` // is disposed prior to the `Context` being disposed otherwise UAFs can occur. tm: ManuallyDrop<OwnedTargetMachine>, </ins> } unsafe impl Send for ModuleLlvm {}
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: unsafe { let llcx = llvm::LLVMRustContextCreate(tcx.sess.fewer_names()); let llmod_raw = context::create_module(tcx, llcx, mod_name) as *const _; <del> ModuleLlvm { llmod_raw, llcx, tm: create_target_machine(tcx, mod_name) } </del> <ins> ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(create_target_machine(tcx, mod_name)), } </ins> } }
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: unsafe { let llcx = llvm::LLVMRustContextCreate(tcx.sess.fewer_names()); let llmod_raw = context::create_module(tcx, llcx, mod_name) as *const _; <del> ModuleLlvm { llmod_raw, llcx, tm: create_informational_target_machine(tcx.sess) } </del> <ins> ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(create_informational_target_machine(tcx.sess)), } </ins> } }
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: } }; <del> Ok(ModuleLlvm { llmod_raw, llcx, tm }) </del> <ins> Ok(ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(tm) }) </ins> } }
Code change:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with

Related discussion:
text: impl Drop for ModuleLlvm { fn drop(&mut self) { unsafe { <ins> ManuallyDrop::drop(&mut self.tm); </ins> llvm::LLVMContextDispose(&mut *(self.llcx as *mut _)); } }
Code change:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

Related discussion:
text: // current number of evaluated terminators is a power of 2. The latter gives us a cheap // way to implement exponential backoff. let span = ecx.cur_span(); <del> ecx.tcx.dcx().emit_warn(LongRunningWarn { span, item_span: ecx.tcx.span }); </del> <ins> // We store a unique number in `force_duplicate` to evade `-Z deduplicate-diagnostics`. // `new_steps` is guaranteed to be unique because `ecx.machine.num_evaluated_steps` is // always increasing. ecx.tcx.dcx().emit_warn(LongRunningWarn { span, item_span: ecx.tcx.span, force_duplicate: new_steps, }); </ins> } }
Code change:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

Related discussion:
text: pub span: Span, #[help] pub item_span: Span, <ins> // Used for evading `-Z deduplicate-diagnostics`. pub force_duplicate: usize, </ins> } #[derive(Subdiagnostic)]