jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> fn clear_dbg_loc(&mut self) { unsafe { llvm::LLVMSetCurrentDebugLocation2(self.llbuilder, ptr::null()); } } </ins> fn insert_reference_to_gdb_debug_scripts_section_global(&mut self) { gdb::insert_reference_to_gdb_debug_scripts_section_global(self) }

Discussion:
<!-- 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: Setting a breakpoint on in rust-gdb results in gdb stopping before 's stack slot is initialized, and gdb dereferences it to print wrong values based on : Note the incorrect different values of as I step past initialization. The breakpoint should trigger just after that , not before it. The other functions in that program indeed do it correctly. Oddly, it seems like the operator is necessary for my repro, though maybe that has something to do with the hidden var. (Note that vs is necessary to actually avoid accidental correct values of due to stack reuse, so the other functions can't print wrong as written. But I'm just looking at where the breakpoint hits in disassembly.) Here's relevant llvm-dwarfdump from this binary, with a pointing at at the () rather than the : This looks pretty related to and Like , the repro hits on 1.71 but not 1.70. I'm filing separately because, unlike it, disabling SingleUseConsts doesn't seem to fix the breakpoint. I'm not 100% sure I'm disabling it right - you can see my command above. <!-- 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<summaryBacktrace</summary<p</p</details
I'm not familiar with github's notification rules, so pinging
Thanks for the tag, I wouldn't have seen this otherwise. From , we can see that the "prologue end" marker that tells the debugger where to stop is indeed placed on the mov I suspect this is due to the desugaring of the ? operator since the column number provided is 29.
label +A-debuginfo
Sure enough, ConstDebugInfo is in there.
I guess you probably saw, but does suggest that the bisect is somehow misleading.
Yes, getting the values wrong at function entry is especially bad because it messes up conditional breakpoints.
Disabling the pass doesn't do anything here because the is created by when it removes . Otherwise this is identical to .

The easiest way to fix this would be for DILocation to carry a "this is not a statement" flag that overrides LLVM's usual line based inference of statement markers. I'll run it by the LLVM folks and see what they say.
Actually, in this particular case, because the const is a ZST I think we can do better today without LLVM changes.
Thanks for reporting this. The linked PR will fix this particular degenerate case.
Change:
temp_dir, image_dir, overlay_dir, <ins> bulk_dirs: Vec::new(), </ins> include_target_in_component_name: false, is_preview: false,

Discussion:
CC On today's git () seems to get stuck if you are building docs. In : will get stuck at: The underlying command is: Adding this to the config seems to work around the hang: Thanks!
How long did you let the command run before killing it? I remember installing the docs taking a long time last time I did it.
I left it for half an hour or so IIRC. I'll run it for longer and see if it goes away. How long do you think it should take to install on a modern SSD?
I don't remember exactly how long it takes, but it doesn't depend on the speed of the disk. is just really inefficient. You can see if it's actually hanging by checking the contents of this command while it's installing:
The log file is empty, but I can see new files appearing on the disk (using and ) so progress must be occurring. Slowly.
It's been about 40 minutes now. It seems to be adding files to is that right?
So it's just very slow.
I took a look into this. The main issue is that the generated is very inefficient; it takes about 5 minutes to copy 2500 files (there are more than 2500, but I got bored and cancelled it). what do you think about rewriting this inner loop in Rust so it's not launching so many external processes?
This issue is compounded on macOS, where it seems to be even more inefficient to launch lots of processes from a shell. Sorry I don't have timings, but it takes tens of minutes at least for this step [edit: over an hour]; long enough that I would expect most users who are trying to build our software from source in macOS (it's Zcash, which installs a pinned version of Rust in order to build) are likely to think it's hanging and give up.
I think the problem may largely be that the generated for rust-docs component (at least) is a file: list instead of using the directory: command; directory commands should be much more efficient. This change may be a recent(ish) regression; I suspect that fixing that is likely the right solution here.
Oops I forgot to link back here: we discussed this briefly and it was difficult to do in a cross-platform way.
We solved our problem for Zcash by just not installing rust-docs (passing to ).

This reduced our total build time on macOS ! Obviously it doesn't solve the underlying issue.
FYI, addresses this (not the underlying cause of the inefficiency but the majority of its extent).
I bisected the underlying issue to “bootstrap: convert rust-docs to use Tarball” (). Before this commit, rust-docs installs in half a second, and is 1 line: After this commit, rust-docs installs in some twenty minutes, and is lines:
Proposed fix in . (We should also do the optimization in rust-lang/rust-installer of course.)
Change:
<ins> // Copyright 2016 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. // Tests that the result of type ascription has adjustments applied #![feature(rustc_attrs, type_ascription)] #[rustc_mir] fn main() { let x = [1, 2, 3]; // The RHS should coerce to &[i32] let _y : &[i32] = &x : &[i32; 3]; } </ins>

Discussion:
Compiling the crate with on ARM Linux: or : This was my first contact with mir and it wasn't peaceful :) Maybe I should have tried a , erm instead...
More ICEy stuff: coming from crate.
Minimal reproduction: It's the that is the problem. What happens is that we first reify to a function pointer, then try to cast the function pointer itself. It seems that we don't expect an cast in the MIR. I'm pretty sure that is only valid when it's a no-op, so we can probably just handle it MIR translation. that seem correct?
I some code to not build noop casts, the lifetimes may be different here though?
possibly, doing first and using in the cast works, so I'd say that lifetimes are the most likely source of difference between the two types in the cast. Do we have a lifetime-ignoring comparison we could use in this case?
Problem is, you can't ignore lifetimes, what if this is a to cast? There might be another way to tell that a cast only triggered a coercion, at the HAIR level. EDIT: Well, actually, the good old is a reification coercion + ptr-to-int cast.
do you mind giving a backtrace for that second error and opening a new issue for it (since it's unrelated to the two in the main post). If you could reduce it to a smaller reproduction, that would be even better.
There were no backtraces, unfortunately. Let's clarify one thing though - is turning off for a single crate and then resuming the mir'ed build, ok? That's how I arrived at the latter issue. (edit: wasn't the problem)
Actually MIR compilation has been bootstrappable for the compiler for a while now, so trying to use it for more complex codebases is really valuable, since it finds bugs like this.
The compiler doesn't generate a backtrace even if you set ?
That was the case indeed. (both ended in a segfault) -original message- Subject: Re: From: Eduard-Mihai Burtescu Date: 01.05.2016 12:22 The compiler doesn't generate a backtrace even if you set ? You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:
Yeah, that's why I tried it - that whole sentence was a big pun on the word mir. (meaning both peace and world)
Change:
vec![self.rustc(stage)] } Source::DistStd { compiler } => { <del> vec![self.libtest(compiler)] </del> <ins> // We want to package up as many target libraries as possible // for the `rust-std` package, so if this is a host target we // depend on librustc and otherwise we just depend on libtest. if build.config.host.iter().any(|t| t == self.target) { vec![self.librustc(compiler)] } else { vec![self.libtest(compiler)] } </ins> } Source::Dist { stage } => {

Discussion:
When I try to compile a simple program using the syntax crate on FreeBSD, it seems to be unable to find the library: I first got the error when trying to compile , but from the above test it seems clear that the issue is not in the crate itself. I'm currently running nightly-2016-04-13 (installed from the newly-avaliable multirust toolchain for FreeBSD). In case it's helpful to know, there does seem to be a in , but I'm not sure how to figure out why I'm unable to use it.
I'm seeing the same on host=armv7-unknown-linux-gnueabihf (installed via rustup). But I think this is expected because there is no in the .multirust directory. cc
Oh man, first off thanks for testing FreeBSD :). Second, thanks for the report! Third, gah this is a rustbuild bug. It turns out that the rust-std package is actually "all target libraries" in the sense that it's more than just libstd, it's every target library we have available for that platform. Consequently, rustbuild needs to package librustc target libs into the rust-std package if the target is configured as a host. cc seems surprising in the sense that "rust-std" is an odd name, but makes sense in terms of "that package contains all libraries for the target we have available".
Same problem in a RaspberryPi
I already mentioned the same problem happens on host=armv7-unknown-linux-gnueabihf :smile:. And there's a fix in . OT: Is that an RPi 1 or RPi 2? Because you are not supposed to use the armv7-unknown-linux-gnueabihf target with the RPi 1. I actually expect would crash in that case.
Sorry about that!. I am using RPi 2.
It's okay! We got a confirmation of the bug :+1:. Never mind what I said then. (I was wondering if there was a bug where armv7 toolchain gets installed on the RPi 1. I'm glad that's not the case!)
Change:
<ins> error[E0425]: cannot find value `oops` in this scope --> $DIR/issue-104609.rs:2:5 | LL |     oops; |     ^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
Found with a <details<summaryBacktrace</summary</details<details<summaryBacktrace</summary</detailsRegression in nightly-2022-05-28, perhaps from () nightly: 2022-11-18 on playground with debug assertions: slightly newer, built locally from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might be a duplicate of
Should be an easy fix, just need to delay a bug if the transmute source/target has (non-region) infer vars and bail from the fn.
claim
Change:
AllocDecodingSession { state: self, session_id } } <del> pub fn new(data_offsets: Vec<u32>) -> Self { </del> <ins> pub fn new(data_offsets: Vec<u64>) -> Self { </ins> let decoding_state = std::iter::repeat_with(|| Lock::new(State::Empty)).take(data_offsets.len()).collect();

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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:
Change:
return None; }; <del> self.commit_if_ok(|_| { </del> <ins> self.commit_if_ok(|snapshot| { let outer_universe = self.universe(); </ins> let ocx = ObligationCtxt::new(self); let impl_args = self.fresh_args_for_item(base_expr.span, impl_def_id); let impl_trait_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. --<!-- 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
Regression in nightly-2023-04-20 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests, r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3 ERROR: no CI builds available between and within last 167 days
Oh this might be contained in the first rollup ping reduced a bit: `
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
//~^ ERROR mismatched types foo::<i16>(x_u16.try_into().unwrap()); //~^ ERROR mismatched types <del> foo::<i16>(x_u8.try_into().unwrap()); </del> <ins> foo::<i16>(x_u8.into()); </ins> //~^ ERROR mismatched types foo::<i16>(x_isize.try_into().unwrap()); //~^ ERROR mismatched types

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
// Wrap the call in a catch to ensure unwinding is caught in the event // a panic takes place in a destructor. if let Err(_) = panic::catch_unwind(panic::AssertUnwindSafe(|| unsafe { <del> let value = (*ptr).inner.take(); (*ptr).dtor_state.set(DtorState::RunningOrHasRun); </del> <ins> let Key { inner, dtor_state } = &*ptr; let value = inner.take(); dtor_state.set(DtorState::RunningOrHasRun); </ins> drop(value); })) { rtabort!("thread local panicked on drop");

Discussion:
At , acquire a pointer of type from a shared reference , and subsequently, in the , we reinterpret as and use it as a mutable pointer At the method of the field requires as defined in The whole process can be that we use to acquire a and call a mutable method on that variable, which seems problematic.
The code is sound if it uses , and all the fields inside that type is covered by . It should use or instead of pointer-casting.
Edit: I think what I want to ask about is the following example, which is almost identical to the original question and passes miri's check:
No, you should not do that.
So this is what is happening in the standard library: There is a structure like ; In , is converted to and passed to ; In , is converted to , then is called. requires , so it is actually , which means that a is born from a . In the entire process, we haven’t touched on anything related to . And, I also believe that containing an is not a reason for to be treated differently.
Yes, should be and not .
I should clarify that my "should not" here is that it can potentially pass miri, but my understanding is that it is brittle and relying on the operational semantics being a certain way, rather than being a "necessarily true" interpretation of Rust's semantics. Programs which are slight modifications easily become unsound, and libstd unfortunately has slight modifications done to it all the time, so... aiui this code currently passes miri because we do run miri on libstd's tests, but is not what I would consider "durable".
( probably. )
Change:
fn main() { assert_eq!(aux::v(), crate::v()); F(); <ins> G(); </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. --Sorry, haven't tried to minimise this yet. The repro steps are here: <!-- 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. --: Also reproduces in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Hoisting the inline structure initialisation into s makes the ICE go away. That... doesn't make a lot of sense to me. <details<summary<strongDiff</strong</summary<p</p</details
Also reproduces in which is our current MSRV
The implementation here should probably also recurse into :
I can confirm that the ICE goes away with the suggested patch.
Possibly related -- while this made the ICE go away, the code when compiled in mode seems to not link. <details<summary<strongmysterious link error</strong</summary<p</p</detailsNaively -- with no understanding of rustc internals -- it feels like a reachability pass that doesn't find these values won't emit them into the library? Slapping some extra attributes around the place is a workaround.
Change:
<ins> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
<ins> #[derive(PartialEq)] struct Comparable; #[derive(PartialEq, PartialOrd)] struct Nope(Comparable); fn main() {} </ins>

Discussion:
attempts to derive in an invalid situation, and is rewarded with a barrage of duplicate errors: The error only appears once. However, the error (along with note ... gee, really?) appears eight times, four for and four for . I assume this is because an error is generated at several points within the (invisible) generated implementation. But since they are all assigned the same span, maybe we can deduplicate.
Would the following be possible?: bound failure error true for the further compilation It doesn't address all cases, but it would significantly improve this one.
Should this be a UI or compile-fail test? I think cfail is out of favor these days, but a UI test will have to include a bug:
It should be a UI test, I'd say and we should fix that bug