jiebi/CodeConvo huggingface dataset:
Code change:
} } <ins> const LOADERS: &Vec<&'static u8> = &Vec::new(); pub fn break_code() -> Option<&'static u8> { for loader in *LOADERS { //~ ERROR cannot move out of a shared reference return Some(loader); } None } </ins> fn main() {}

Related discussion:
text: <!-- 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. --Compiles with replaced for <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
let stdin = stdin.to_handle(c::STD_INPUT_HANDLE, &mut pipes.stdin)?; let stdout = stdout.to_handle(c::STD_OUTPUT_HANDLE, &mut pipes.stdout)?; let stderr = stderr.to_handle(c::STD_ERROR_HANDLE, &mut pipes.stderr)?; <del> si.hStdInput = stdin.as_raw_handle(); si.hStdOutput = stdout.as_raw_handle(); si.hStdError = stderr.as_raw_handle(); </del> <ins> let mut si = zeroed_startupinfo(); si.cb = mem::size_of::<c::STARTUPINFO>() as c::DWORD; // If at least one of stdin, stdout or stderr are set (i.e. are non null) // then set the `hStd` fields in `STARTUPINFO`. // Otherwise skip this and allow the OS to apply its default behaviour. // This provides more consistent behaviour between Win7 and Win8+. let is_set = |stdio: &Handle| !stdio.as_raw_handle().is_null(); if is_set(&stderr) || is_set(&stdout) || is_set(&stdin) { si.dwFlags |= c::STARTF_USESTDHANDLES; si.hStdInput = stdin.as_raw_handle(); si.hStdOutput = stdout.as_raw_handle(); si.hStdError = stderr.as_raw_handle(); } </ins> unsafe { cvt(c::CreateProcessW(

Related discussion:
text: More importantly, this is de facto the default way of how a process is created in Windows. Defaulting to really makes me confused before reading the internal source code.
Not always. Parent process can still set those handles to something other than . For example, if you launch App P from IntelliJ it actually prints "Hello World!" in a loop but not in the spawned console which is empty, but in IntelliJ internal terminal. returns non invalid handle. This solution would make behaviour different depending on how you launch your app. Also, you can explicitly ask to create new console with even if your app already uses console subsystem. In this case you also likely want to avoid inheriting handles because you want output of the spawned process to be displayed in the new console, not in the existing one. This solution doesn't help with this.
I can't verify your statements since I don't have IntelliJ atm, but even it's true, isn't it IntelliJ setting up the console with maybe some special debugging API? How to you modify the code of P to achieve the same? And realistically speaking, do people actually do that with GUI apps? I think in this case, it's impossible to be 100% sure where the user wants the output at. New option might be the way to go.
Your prediction was dead-on, as it came true in While we can do this, as is proposing, it seems best here that we create a function, or set of functions, that explicitly handle this kind of situation rather than guessing.
Even with new APIs, we still need reasonable default behaviour. And the Command API is documented as inheriting handles by default. However, currently the API neglects the "no handle set" case entirely as that's not really a thing in POSIX or ISO C (well, you can close stdio but that's usually considered a Bad Thing unless you're being very very careful).
Code change:
return None } None => { <del> if !tcx.sess.has_errors() { </del> <ins> if !tcx.sess.has_errors_or_delayed_span_bugs() { </ins> bug!("try_mark_previous_green() - Forcing the DepNode  should have set its color") } else { <del> // If the query we just forced has resulted // in some kind of compilation error, we // don't expect that the corresponding // dep-node color has been updated. </del> <ins> // If the query we just forced has resulted in // some kind of compilation error, we cannot rely on // the dep-node color having been properly updated. // This means that the query system has reached an // invalid state. We let the compiler continue (by // returning `None`) so it can emit error messages // and wind down, but rely on the fact that this // invalid state will not be persisted to the // incremental compilation cache because of // compilation errors being present. debug!("try_mark_previous_green({:?}) - END -  dependency {:?} resulted in compilation error", dep_node, dep_dep_node); return None </ins> } } }

Related discussion:
text: Creating a recursive type with infinite size by removing a leads to an internal compiler error. Might be the same issue as . To reproduce this bug, run on this code: Replace by and run again: I expected to see this happen: Instead, this happened: :
triage: P-high. Removing nomination.
assigning to with expectation that they will delegate.
nominating to try to find someone to investigate this.
well spotted ;) Because this issue has the tag and the other doesn't I will post the incremental test here:
triage: Reassigning to self and in hopes that one of us will find time to investigate, since it seems to be an issue with the dep-graph/incr-comp infrastructure.
triage: Downgrading to P-medium. I still want to resolve this, but it simply does not warrant revisiting every week during T-compiler triage.
I encountered the same bug. I starting to create a new issue, but it's exactly the same than this one. In case it's needed, I uploaded the code on on the branch (there is two commits, the first is fine, the second generate the ICE) in case you want to validate your patch when you will eventually have time to fix it.
I am running into this issue as well. Since the corresponding pr has been merged 24 days ago and the latest version was tagged 14 days ago, I am not sure, if this error should have been fixed with . (I did not find the commit on the master but I am also unsure if it was squashed with other commits.) Therefore, I thought I would at least post my error as well, just in case this is supposed to work. In my case I have an enum which holds a struct which in turn references that enum. I know that this can't work and I know how the correct way of handling this scenario is, I just wanted to let you know that this crashes the compiler. If you need a more detailed code sample, let me know and I will try to reproduce the error outside of my project.
Code change:
<ins> // Checks that `SimplifyArmIdentity` is not applied if enums have incompatible layouts. // Regression test for issue #66856. // // compile-flags: -Zmir-opt-level=2 enum Src { Foo(u8), Bar, } enum Dst { Foo(u8), } fn main() { let e: Src = Src::Foo(0); let _: Dst = match e { Src::Foo(x) => Dst::Foo(x), Src::Bar => Dst::Foo(0), }; } // END RUST SOURCE // START rustc.main.SimplifyArmIdentity.before.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.before.mir // START rustc.main.SimplifyArmIdentity.after.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.after.mir </ins>

Related discussion:
text: PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are
Code change:
<ins> // Checks that `SimplifyArmIdentity` is not applied if enums have incompatible layouts. // Regression test for issue #66856. // // compile-flags: -Zmir-opt-level=2 enum Src { Foo(u8), Bar, } enum Dst { Foo(u8), } fn main() { let e: Src = Src::Foo(0); let _: Dst = match e { Src::Foo(x) => Dst::Foo(x), Src::Bar => Dst::Foo(0), }; } // END RUST SOURCE // START rustc.main.SimplifyArmIdentity.before.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.before.mir // START rustc.main.SimplifyArmIdentity.after.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.after.mir </ins>

Related discussion:
text: Since few Rustc nightly versions I see a miscompilation problem with the code below. I am using: If I compile with: The code:
NB: this is because it needs an unstable CLI flag to reproduce.
cc since this might have something to do with recent const-eval work (apologies if I left anyone out)
I've managed to minify it to
Bisected it to , most probably the same issue as
Code change:
traits_in_scope: DefIdMap<Vec<TraitCandidate>>, all_traits: Vec<DefId>, all_trait_impls: Vec<DefId>, <ins> document_private_items: bool, </ins> } impl IntraLinkCrateLoader<'_, '_> {

Related discussion:
text: The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.
Code change:
pub fn has_errors(&self) -> bool { self.inner.borrow().has_errors() } <ins> pub fn has_errors_or_delayed_span_bugs(&self) -> bool { self.inner.borrow().has_errors_or_delayed_span_bugs() } </ins> pub fn print_error_count(&self, registry: &Registry) { self.inner.borrow_mut().print_error_count(registry)

Related discussion:
text: When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly
Code change:
<del> Subproject commit 5f28fda13efeb85097fe082af4b4827a58b0ecf6 </del> <ins> Subproject commit 58e01ea4d7df69e658c034afbfa6d0abd90808ed </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I suspect the or-pattern PR, , is to blame.
Fix for Clippy repo:
Code change:
<ins> //! This is a regression test for #129020 //! It ensures we can use `/WHOLEARCHIVE` to link a rust staticlib into DLL //! using the MSVC linker //@ only-msvc // Reason: this is testing the MSVC linker use std::path::PathBuf; use run_make_support::{cc, cmd, env_var, extra_c_flags, rustc}; fn main() { // Build the staticlib rustc().crate_type("staticlib").input("static.rs").output("static.lib").run(); // Build an empty object to pass to the linker. cc().input("c.c").output("c.obj").args(["-c"]).run(); // Find the C toolchain's linker. let mut linker = PathBuf::from(env_var("CC")); let linker_flavour = if linker.file_stem().is_some_and(|s| s == "cl") { linker.set_file_name("link.exe"); "msvc" } else if linker.file_stem().is_some_and(|s| s == "clang-cl") { linker.set_file_name("lld-link.exe"); "llvm" } else { panic!("unknown C toolchain"); }; // As a sanity check, make sure this works without /WHOLEARCHIVE. // Otherwise the actual test failure may be caused by something else. cmd(&linker) .args(["c.obj", "./static.lib", "-dll", "-def:dll.def", "-out:dll.dll"]) .args(extra_c_flags()) .run(); // FIXME(@ChrisDenton): this doesn't currently work with llvm's lld-link for other reasons. // May need LLVM patches. if linker_flavour == "msvc" { // Link in the staticlib using `/WHOLEARCHIVE` and produce a DLL. cmd(&linker) .args([ "c.obj", "-WHOLEARCHIVE:./static.lib", "-dll", "-def:dll.def", "-out:dll_whole_archive.dll", ]) .args(extra_c_flags()) .run(); } } </ins>

Related discussion:
text: Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.
Code change:
<ins> From 0d741cf82c3c908616abd39dc84ebf7d8702e0c3 Mon Sep 17 00:00:00 2001 From: Chris Denton <chris@chrisdenton.dev> Date: Tue, 16 Apr 2024 15:51:34 +0000 Subject: [PATCH] Revert use raw-dylib for Windows futex APIs --- library/std/src/sys/pal/windows/c.rs | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/library/std/src/sys/pal/windows/c.rs b/library/std/src/sys/pal/windows/c.rs index 9d58ce05f01..1c828bac4b6 100644 --- a/library/std/src/sys/pal/windows/c.rs +++ b/library/std/src/sys/pal/windows/c.rs @@ -357,19 +357,7 @@ pub fn GetTempPath2W(bufferlength: u32, buffer: PWSTR) -> u32 { } #[cfg(not(target_vendor = "win7"))] -// Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. -#[cfg_attr( -    target_arch = "x86", -    link( -        name = "api-ms-win-core-synch-l1-2-0", -        kind = "raw-dylib", -        import_name_type = "undecorated" -    ) -)] -#[cfg_attr( -    not(target_arch = "x86"), -    link(name = "api-ms-win-core-synch-l1-2-0", kind = "raw-dylib") -)] +#[link(name = "synchronization")] extern "system" { pub fn WaitOnAddress( address: *const c_void, -- 2.42.0.windows.2 </ins>

Related discussion:
text: EDIT: Filed Depending on their response, if they decide not to update, it's possible could be fixed instead to stop trying to install Rust over an incompatible version of MinGW.
For some reason, my original issue description code snippet mentioned instead of . I think that's because I copy/pasted the wrong version, when I was seeing whether the workaround worked (which I believe it did). I apologize if that caused any confusion. I've now edited the description to fix this mistake.
Given that seems to be in progress and would close this issue, I mentioned that in for extra transparency.
Thank you for all your help on this! It's awesome that all this happened in only 4 days. I can confirm on my end that this issue is now fully resolved on the latest nightly release of Rust (2024-04-19).
Code change:
<ins> error: custom derive attribute panicked --> $DIR/issue-36935.rs:17:15 | 17 | #[derive(Foo, Bar)] |               ^^^ | = help: message: lolnope </ins>

Related discussion:
text: Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:
Code change:
<ins> warning: unused variable: `Mod` --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:12:9 | LL |     let Mod: usize = 0; |         ^^^ help: if this is intentional, prefix it with an underscore: `_Mod` | note: the lint level is defined here --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:1:9 | LL | #![warn(unused)] |         ^^^^^^ = note: `#[warn(unused_variables)]` implied by `#[warn(unused)]` warning: unused variable: `Super` --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:16:9 | LL |     let Super: usize = 0; |         ^^^^^ help: if this is intentional, prefix it with an underscore: `_Super` error: module `Impl` should have a snake case name --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:5:5 | LL | mod Impl {} |     ^^^^ | note: the lint level is defined here --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:3:9 | LL | #![deny(non_snake_case)] |         ^^^^^^^^^^^^^^ help: rename the identifier or convert it to a snake case raw identifier | LL | mod r#impl {} |     ^^^^^^ error: function `While` should have a snake case name --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:8:4 | LL | fn While() {} |    ^^^^^ | help: rename the identifier or convert it to a snake case raw identifier | LL | fn r#while() {} |    ^^^^^^^ error: variable `Mod` should have a snake case name --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:12:9 | LL |     let Mod: usize = 0; |         ^^^ | help: rename the identifier or convert it to a snake case raw identifier | LL |     let r#mod: usize = 0; |         ^^^^^ error: variable `Super` should have a snake case name --> $DIR/lint-non-snake-case-identifiers-suggestion-reserved.rs:16:9 | LL |     let Super: usize = 0; |         ^^^^^ help: rename the identifier | = note: `super` cannot be used as a raw identifier error: aborting due to 4 previous errors; 2 warnings emitted </ins>

Related discussion:
text: When you write a mod with a capital name of a keyword, we suggest changing it to the lowercase version of the keyword, which is, well, a keyword and not going to work. We should suggest converting the identifier to snake case and making it a raw identifier, or maybe suggest switching to an altogether separate name? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hey you might want to comment here to claim this issue :)
claim
Code change:
if !(eps[1].expr.hir_id == expr.hir_id && lit_val - 1 == max) { return false; }; <del> let Ok(start) = cx.sess().source_map().span_to_snippet(eps[0].span) else { return false }; </del> use rustc_ast::{LitIntType, LitKind}; let suffix = match lit.node {

Related discussion:
text: <!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim