jiebi/CodeConvo huggingface dataset:
Change:
<ins> // compile-flags: -C opt-level=3 #![crate_type = "lib"] #![feature(c_variadic)] #![no_std] use core::ffi::VaList; extern "C" { fn vprintf(fmt: *const i8, ap: VaList) -> i32; } // Ensure that `va_start` and `va_end` are properly injected even // when the "spoofed" `VaList` is not used. #[no_mangle] pub unsafe extern "C" fn c_variadic_no_use(fmt: *const i8, mut ap: ...) -> i32 { // CHECK: call void @llvm.va_start vprintf(fmt, ap) // CHECK: call void @llvm.va_end } </ins>

Discussion:
This example prints when compiled and run in debug mode: Compiling and running in release mode causes a segfault in  because is nul. Enabling debug info in release mode via makes the segfault go away.
thanks for reporting this. The example should probably look more like the following. The example still segfaults (even in debug mode). If is used in the function the issue does not happen. Essentially we're optimizing to the following Note the missing and . I think this is happening because we're hitting . I'll do some more investigation shortly.
the code I list in the above example should work after is merged.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. enum Test { Foo = 0 } fn main() { let _x = Foo as *const int; //~^ ERROR illegal cast; cast through an integer first: `Test` as `*const int` } </ins>

Discussion:
The following program causes rustc to crash: Obviously it's badly typed (converting void to a pointer type), but the compiler shouldn't crash here right? :) output of rustc -v: rustc 0.12.0-pre-nightly ( 2014-09-11 00:05:41 +0000) backtrace from trying to compile; Let me know if you need more information.
Yes, any ICE is bad. Thanks!
Simpler: Works with every C-like enum.
I'll try to fix this one together with
Fixed in
Change:
pub main_def: Option<MainDefinition>, } <del> #[derive(Clone, Copy)] </del> <ins> #[derive(Clone, Copy, Debug)] </ins> pub struct MainDefinition { pub res: Res<ast::NodeId>, pub is_import: bool,

Discussion:
<!-- 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. --Not minimal, but possibly helpful, from <!-- 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 --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar
Change:
pub const EXCEPTION_MAXIMUM_PARAMETERS: usize = 15; pub const PIPE_ACCESS_INBOUND: DWORD = 0x00000001; <ins> pub const PIPE_ACCESS_OUTBOUND: DWORD = 0x00000002; </ins> pub const FILE_FLAG_FIRST_PIPE_INSTANCE: DWORD = 0x00080000; pub const FILE_FLAG_OVERLAPPED: DWORD = 0x40000000; pub const PIPE_WAIT: DWORD = 0x00000000;

Discussion:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.
Change:
/// assert!(!(0.0..f32::NAN).contains(&0.5)); /// assert!(!(f32::NAN..1.0).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

Discussion:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.
Change:
|(parent_field_idx, parent_capture), (child_field_idx, child_capture)| { // Store this set of additional projections (fields and derefs). // We need to re-apply them later. <del> let child_precise_captures = &child_capture.place.projections[parent_capture.place.projections.len()..]; </del> <ins> let mut child_precise_captures = child_capture.place.projections [parent_capture.place.projections.len()..] .to_vec(); </ins> <del> // If the parent captures by-move, and the child captures by-ref, then we // need to peel an additional `deref` off of the body of the child. let needs_deref = child_capture.is_by_ref() && !parent_capture.is_by_ref(); if needs_deref { assert_ne!( coroutine_kind, ty::ClosureKind::FnOnce, </del> <ins> // If the parent capture is by-ref, then we need to apply an additional // deref before applying any further projections to this place. if parent_capture.is_by_ref() { child_precise_captures.insert( 0, Projection { ty: parent_capture.place.ty(), kind: ProjectionKind::Deref }, ); } // If the child capture is by-ref, then we need to apply a "ref" // projection (i.e. `&`) at the end. But wait! We don't have that // as a projection kind. So instead, we can apply its dual and // *peel* a deref off of the place when it shows up in the MIR body. // Luckily, by construction this is always possible. let peel_deref = if child_capture.is_by_ref() { assert!( parent_capture.is_by_ref() || coroutine_kind != ty::ClosureKind::FnOnce, </ins> "`FnOnce` coroutine-closures return coroutines that capture from  their body; it will always result in a borrowck error!" ); <del> } </del> <ins> true } else { false }; // Regarding the behavior above, you may think that it's redundant to both // insert a deref and then peel a deref if the parent and child are both // captured by-ref. This would be correct, except for the case where we have // precise capturing projections, since the inserted deref is to the *beginning* // and the peeled deref is at the *end*. I cannot seem to actually find a // case where this happens, though, but let's keep this code flexible. </ins> // Finally, store the type of the parent's captured place. We need // this when building the field projection in the MIR body later on.

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:
Change:
} let impl_fn_def_id = leaf_def.item.def_id; <del> let impl_fn_substs = obligation.predicate.substs.rebase_onto(tcx, trait_fn_def_id, data.substs); </del> <ins> // Rebase from {trait}::{fn}::{opaque} to {impl}::{fn}::{opaque}, // since `data.substs` are the impl substs. let impl_fn_substs = obligation.predicate.substs.rebase_onto(tcx, tcx.parent(trait_fn_def_id), data.substs); </ins> let cause = ObligationCause::new( obligation.cause.span,

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim
Change:
/// Panics if `index` is greater than `VecDeque`'s length /// /// # Examples <ins> /// </ins> /// ``` /// use std::collections::VecDeque; /// <del> /// let mut buf = VecDeque::new(); /// buf.push_back(10); /// buf.push_back(12); /// buf.insert(1, 11); /// assert_eq!(Some(&11), buf.get(1)); </del> <ins> /// let mut vec_deque = VecDeque::new(); /// vec_deque.push_back('a'); /// vec_deque.push_back('b'); /// vec_deque.push_back('c'); /// /// vec_deque.insert(1, 'd'); /// /// let vec = vec_deque.into_iter().collect::<Vec<_>>(); /// assert_eq!(vec, ['a', 'd', 'b', 'c']); </ins> /// ``` #[stable(feature = "deque_extras_15", since = "1.5.0")] pub fn insert(&mut self, index: usize, value: T) {

Discussion:
The documentation for describes implementation details of how it internally rearranges the data structure which make it unclear on what the actual behavior of the method call is: "Inserts an element at index within the VecDeque. Whichever end is closer to the insertion point will be moved to make room, and all the affected elements will be moved to new positions. Element at index 0 is the front of the queue." The doc should clearly state that the element will be inserted at this index and the existing element at this index will be pushed towards the back of the deque. The current doc makes it sound like which direction the existing element will be pushed towards could be different depending on that implementation detail.
Opened a PR for this:
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }); ($name:expr,) => ({ /* compiler built-in */ }); } </ins> /// Optionally inspect an environment variable at compile time. ///

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
debug!("check_pat_walk(pat={:?},expected={:?},def_bm={:?})", pat, expected, def_bm); <ins> let mut path_resolution = None; </ins> let is_non_ref_pat = match pat.node { PatKind::Struct(..) | PatKind::TupleStruct(..) |

Discussion:
The following, which I expect to work, fails to infer the type of : In HIR, should correspond to: However, if we change the snippet to: it all works out fine. I also tested changing to a tuple variant and that works also. cc cc
It might be a good idea to trace the difference between and because they look relatively similar and yet they behave differently in terms of inference.
Value (/) and type () namespaces execute very different logic for type inference (/ vs ). It's quite possible that there are intended and unintended observable differences (not necessarily specific to ). checkpatpath and checkpattuplestruct Rather and . ( is the same "value" case as .)
Change:
} } <del> fn check_expr_yield(&self, value: &'tcx hir::Expr, expr: &'tcx hir::Expr) -> Ty<'tcx> { </del> <ins> fn check_expr_yield( &self, value: &'tcx hir::Expr, expr: &'tcx hir::Expr, src: &'tcx hir::YieldSource ) -> Ty<'tcx> { </ins> match self.yield_ty { Some(ty) => { self.check_expr_coercable_to_type(&value, ty); } <del> None => { </del> <ins> // Given that this `yield` expression was generated as a result of lowering a `.await`, // we know that the yield type must be `()`; however, the context won't contain this // information. Hence, we check the source of the yield expression here and check its // value's type against `()` (this check should always hold). None if src == &hir::YieldSource::Await => { self.check_expr_coercable_to_type(&value, self.tcx.mk_unit()); } _ => { </ins> struct_span_err!(self.tcx.sess, expr.span, E0627, "yield statement outside of generator literal").emit(); }

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
/// The local binding that shadows the glob reexport. private_item_span: Span, }, <ins> UnusedQualifications { /// The span of the unnecessarily-qualified path. path_span: Span, /// The replacement unqualified path. unqualified_path: Ident, }, </ins> } /// Lints that are buffered up early on in the `Session` before the

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
Change:
use std::path::{Path, PathBuf}; use std::process::Command; <ins> use build_helper::ci::CiEnv; </ins> use tracing::*; use crate::common::{Config, Debugger, FailMode, Mode, PassMode};

Discussion:
it seems like the source directory in the printout for ui tests uses "fake-test-src-base" rn, e.g. this prevents ctrl+leftclick in vscode to take me directly to the relevant point in the source of the failing test. it would be nice to somehowo keep the actual path in the output for ui tests and only normalize it when writing into the stderr file? see https://rust- for more details
Note that we already print the real path in the "--- [ui] ... stdout ---" line at the top, but it would be nice to have this in addition so that line/column jumping works too.
One possible workaround is to only pass remap-path-prefix in CI. I think it may also be possible to solve the problem on with a different mechanism entirely by stripping out the the directory with test normalization for UI tests involving closures? https://rustc-dev-
I think there are two reasons why this may be a suboptimal solution: 1) You'd still have to deal with the showing up depending on the path length. 2) The difference between and is that the version indicates that has printed a full path, whereas for the non- version only a filename was printed. It may be useful / desirable to be able to distinguish the two cases in the output files.
makes sense - in that case the simplest fix is to gate remap-path-prefix on
Change:
let fallback_locale = langid!("en-US"); let requested_fallback_locale = requested_locale.as_ref() == Some(&fallback_locale); <ins> trace!(?requested_fallback_locale); if requested_fallback_locale && additional_ftl_path.is_none() { return Ok(None); } </ins> // If there is only `-Z additional-ftl-path`, assume locale is "en-US", otherwise use user // provided locale. let locale = requested_locale.clone().unwrap_or(fallback_locale);

Discussion:
<!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.