jiebi/CodeConvo huggingface dataset:
Change:
let fresh = sess.one_time_diagnostics.borrow_mut().insert(error_id); if fresh { if is_soft { <del> sess.buffer_lint(lint::builtin::SOFT_UNSTABLE, CRATE_NODE_ID, span, &msg); </del> <ins> soft_handler(lint::builtin::SOFT_UNSTABLE, span, &msg) </ins> } else { emit_feature_err( &sess.parse_sess, feature, span, GateIssue::Library(Some(issue)), &msg

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!
Change:
} } <del> unreachable!( "we captured two identical projections: capture1 = {:?}, capture2 = {:?}", capture1, capture2 </del> <ins> self.tcx.sess.delay_span_bug( closure_span, &format!( "two identical projections: ({:?}, {:?})", capture1.place.projections, capture2.place.projections ), </ins> ); <ins> std::cmp::Ordering::Equal </ins> }); }

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. --<!-- 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
searched toolchains through Regression in
Alternative: As long as the variants for and are different.
label +S-bug-has-mcve
This ICE caused by different root cause.
Change:
<ins> error[E0053]: method `call` has an incompatible type for trait --> $DIR/inline-wrong-abi.rs:7:5 | LL |     extern "C" fn call(&self, _: ()) -> T { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected "rust-call" fn, found "C" fn | = note: expected signature `extern "rust-call" fn(&Foo<_>, ()) -> _` found signature `extern "C" fn(&Foo<_>, ()) -> _` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0053`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=0 -Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'', 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'' 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
cc
Change:
<del> error[E0045]: C-variadic function must have a compatible calling convention, like `C`, `cdecl`, `aapcs`, `win64`, `sysv64` or `efiapi` </del> <ins> error[E0045]: C-variadic function must have a compatible calling convention, like `C`, `cdecl`, `system`, `aapcs`, `win64`, `sysv64` or `efiapi` </ins> --> $DIR/variadic-ffi-2.rs:4:11 | LL | fn baz(f: extern "stdcall" fn(usize, ...)) {

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
LL | const A: isize = Foo::B as isize; |                  ^^^^^^^^^^^^^^^ = note: ...which again requires processing `Foo::B::{{constant}}#0`, completing the cycle <del> note: cycle used when const-evaluating `Foo::B::{{constant}}#0` </del> <ins> note: cycle used when processing `Foo::B::{{constant}}#0` </ins> --> $DIR/issue-36163.rs:4:9 | LL |     B = A,

Discussion:
Super-High-Level Instructions: Replace with And then follow up by making sure that the compiler doesn't ICE anywhere (e.g. during MIR building). It should probably "just work" nowadays. A crater run isn't necessary, as this will only ICE if an error wasn't handled properly. Successfully compiling code is unaffected.
I took a look at this and all tests seem fine in just dropping in the code you have above as you said. However I just wanted to check is no longer needed? Pretty unfamiliar with this code so I wanted to confirm before submitting as it's not explicitly mentioned in the other thread that it should be removed.
Yes that should be removed, too. It will automatically be run when fetching the MIR of the current constant.
ok, cool! I have filed a PR for this in Let me know if anything needs to be updated!
Change:
use rustc_hir::{GeneratorKind, HirIdMap, Node}; use rustc_index::vec::{Idx, IndexVec}; use rustc_infer::infer::TyCtxtInferExt; <del> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; </del> use rustc_middle::middle::region; use rustc_middle::mir::*; use rustc_middle::ty::subst::Subst;

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
.find(|elem| matches!(elem.1, mir::ProjectionElem::Deref)) { base = elem.0 + 1; <del> self.codegen_consume( </del> <ins> let cg_base = self.codegen_consume( </ins> bx, mir::PlaceRef { projection: &place_ref.projection[..elem.0], ..place_ref }, <del> ) .deref(bx.cx()) </del> <ins> ); // a box with a non-zst allocator should not be directly dereferenced if cg_base.layout.ty.is_box() && !cg_base.layout.field(cx, 1).is_zst() { let ptr = cg_base.extract_field(bx, 0).extract_field(bx, 0); ptr.deref(bx.cx()) } else { cg_base.deref(bx.cx()) } </ins> } else { bug!("using operand local {:?} as place", place_ref); }

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. --Only when building with or do I trigger this issue. Found while working on . Compile test that triggers the issue: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: +A-allocators +A-lto
claim
claim
Hey thanks for looking into this bug (and for fixing my last reports as well :)). I've figured out some more information since first posting this. I'm able to reproduce the bug in a single crate when compiling with 1 and further minimized the triggering code: The bug seems to be specifically triggered when the allocator is non zero-sized, it doesn't matter whether it's a reference or not. Additionally if the boxed type is a struct or tuple, only accessing past the first non-zero field triggers the bug. Attempting to disassemble the bitcode dumped with with gives the same error, unless I pass the flag which causes the disassembly to succeed. The offending store instruction is encoded as follows: Unfortunately the flag strips all pointer types from the input, turning them to in the output, so I do not know what the original type was that is causing the issue. Using the following which doesn't trigger the issue: without gives:
Thanks for the info and minimized code! That's gonna make this easier.
I still don't know how this actually happens, I just know that the change in fixes it. I suspect it's some code assuming that a wide box is always a wide pointer, but I don't know where...
I think you're right about that assumption, using a wide pointer in the box has no issues:
Change:
`armv7-unknown-linux-musleabi` targets.][63107] - [Added tier 3 support for the `hexagon-unknown-linux-musl` target.][62814] - [Added tier 3 support for the `riscv32i-unknown-none-elf` target.][62784] <ins> - [Upgraded to LLVM 9.][62592] </ins> * Refer to Rust's [platform support page][forge-platform-support] for more information on Rust's tiered platform support.

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
repro() } } <ins> #[test] fn fmt_debug_sender() { let (tx, _) = channel::<i32>(); assert_eq!(format!("{:?}", tx), "Sender { .. }"); } #[test] fn fmt_debug_recv() { let (_, rx) = channel::<i32>(); assert_eq!(format!("{:?}", rx), "Receiver { .. }"); } #[test] fn fmt_debug_sync_sender() { let (tx, _) = sync_channel::<i32>(1); assert_eq!(format!("{:?}", tx), "SyncSender { .. }"); } </ins> }

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
Change:
<ins> // build-pass #![crate_type = "lib"] #![feature(unsized_fn_params)] pub fn f(mut x: [i32]) { x[0] = 1; } </ins>

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. --Changing the commented out snippet to the uncommented one caused a ICE when building on nightly . EDIT: Moving the integer cast to before the shift fixes the ICE. () <!-- 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
This also ICEs on beta on the playground. label regression-from-stable-to-beta
searched nightlies: from nightly-2022-03-01 to nightly-2022-04-23 regressed nightly: nightly-2022-03-25 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
cc perhaps we need to adjust where we run some of these lints you extracted in ?
It seems that this is fixed on , so I wanted to find out when that happened and ran () as described here: and it error'd out on me with: Just thought I'd mention that, I think this can be closed, but I couldn't say when or how it was fixed.
Via godbolt I can't find any stable Rust release where this fails. If it ICEd on beta that means an ICE fix must have been backported? you marked this as regression-from-stable-to-stable, was that an automatic process or did you (or someone else) actually ever see this ICE on stable Rust?
Oh wait, I didn't realize that the code posted in the OP is code that works, and one needs to adjust the code to generate an ICE. That is confusing. Sorry for the noise, it does reproduce on 1.64.0 but not 1.65.0.
Change:
s.push('E'); compress(dict, DictKey::Region(region), &mut s); } <del> RegionKind::ReErased => { </del> <ins> RegionKind::ReEarlyBound(..) | RegionKind::ReErased => { </ins> s.push_str("u6region"); compress(dict, DictKey::Region(region), &mut s); } <del> RegionKind::ReEarlyBound(..) | RegionKind::ReFree(..) </del> <ins> RegionKind::ReFree(..) </ins> | RegionKind::ReStatic | RegionKind::ReError(_) | RegionKind::ReVar(..)

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. --<!-- 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 --
claim
Change:
<ins> error[E0572]: return statement outside of function body --> $DIR/issue-86721-return-expr-ice.rs:9:22 | LL |     const U: usize = return; |                      ^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0572`. </ins>

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. --<!-- 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
} let datadir = prefix.join(default_path(&builder.config.datadir, "share")); <del> let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc/rust")); </del> <ins> let docdir = prefix.join(default_path(&builder.config.docdir, &format!("share/doc/{package}"))); </ins> let mandir = prefix.join(default_path(&builder.config.mandir, "share/man")); let libdir = prefix.join(default_path(&builder.config.libdir, "lib")); let bindir = prefix.join(&builder.config.bindir); // Default in config.rs

Discussion:
In a fresh install of 1.72.0 there are some files: The same thing happens with 1.71.1.
Performed a test on 1.72.0 and was able to reproduce the problem. With HEAD: , it is no longer present(most probably fixed on the cargo side since it doesn't have anything to do with bootstrapping). If you encounter the problem again, please feel free to re-open the issue.
I'm still hitting this with 1.73.0.
Perhaps it's related to my setting. I'll do more experiments tomorrow and report back...
Still happens with 1.74.0. The terminal output of (I've removed the lines):
Would be nice if you can share your Last time I tried I couldn't reproduce it.
I think I see the same with Rust 1.76:
Are you building multiple targets?
No. I just set following in : and .
should handle this problem.
Change:
<ins> // skip-filecheck #![feature(never_type)] #![allow(unreachable_code)] // EMIT_MIR eq_never_type._f.built.after.mir fn _f(a: !, b: !) { // Both arguments must be references (i.e. == should auto-borrow/coerce-to-ref both arguments) // (this previously was buggy due to `NeverToAny` coercion incorrectly throwing out other // coercions) a == b; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: 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: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
pub fn main() { let res: Result<u32, i32> = try { <del> Err("")?; //~ ERROR the trait bound `i32: std::convert::From<&str>` is not satisfied </del> <ins> Err("")?; //~ ERROR `?` couldn't convert the error </ins> 5 };

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!