jiebi/CodeConvo huggingface dataset:
Code change:
// types are fine though. ty::ConstKind::Value(_) => c.ty().is_primitive(), ty::ConstKind::Unevaluated(..) | ty::ConstKind::Expr(..) => false, <ins> // This can happen if evaluation of a constant failed. The result does not matter // much since compilation is doomed. ty::ConstKind::Error(..) => false, </ins> // Should not appear in runtime MIR. ty::ConstKind::Infer(..) | ty::ConstKind::Bound(..) <del> | ty::ConstKind::Placeholder(..) | ty::ConstKind::Error(..) => bug!(), </del> <ins> | ty::ConstKind::Placeholder(..) => bug!(), </ins> }, Const::Unevaluated(..) => false, // If the same slice appears twice in the MIR, we cannot guarantee that we will

Related discussion:
text: File: /tmp/icemaker/issue--2.rs 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
cc
Code change:
span: Span,            // span of the field pattern, e.g., `x: 0` def: &'tcx ty::AdtDef, // definition of the struct or enum field: &'tcx ty::FieldDef, <ins> in_update_syntax: bool, </ins> ) { // definition of the field let ident = Ident::new(kw::Invalid, use_ctxt); let current_hir = self.current_item; let def_id = self.tcx.adjust_ident_and_get_scope(ident, def.did, current_hir).1; if !def.is_enum() && !field.vis.is_accessible_from(def_id, self.tcx) { <ins> let label = if in_update_syntax { format!("field `{}` is private", field.ident) } else { "private field".to_string() }; </ins> struct_span_err!( self.tcx.sess, span,

Related discussion:
text: In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)
Code change:
#[cfg(test)] mod bench { <del> use test::Bencher; </del> use super::VecMap; <del> use bench::{insert_rand_n, insert_seq_n, find_rand_n, find_seq_n}; #[bench] pub fn insert_rand_100(b: &mut Bencher) { let mut m = VecMap::new(); insert_rand_n(100, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.remove(&i); }); } #[bench] pub fn insert_rand_10_000(b: &mut Bencher) { let mut m = VecMap::new(); insert_rand_n(10_000, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.remove(&i); }); } // Insert seq #[bench] pub fn insert_seq_100(b: &mut Bencher) { let mut m = VecMap::new(); insert_seq_n(100, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.remove(&i); }); } #[bench] pub fn insert_seq_10_000(b: &mut Bencher) { let mut m = VecMap::new(); insert_seq_n(10_000, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.remove(&i); }); } </del> <ins> map_insert_rand_bench!{insert_rand_100,    100,    VecMap} map_insert_rand_bench!{insert_rand_10_000, 10_000, VecMap} </ins> <del> // Find rand #[bench] pub fn find_rand_100(b: &mut Bencher) { let mut m = VecMap::new(); find_rand_n(100, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.get(&i); }); } #[bench] pub fn find_rand_10_000(b: &mut Bencher) { let mut m = VecMap::new(); find_rand_n(10_000, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.get(&i); }); } </del> <ins> map_insert_seq_bench!{insert_seq_100,    100,    VecMap} map_insert_seq_bench!{insert_seq_10_000, 10_000, VecMap} </ins> <del> // Find seq #[bench] pub fn find_seq_100(b: &mut Bencher) { let mut m = VecMap::new(); find_seq_n(100, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.get(&i); }); } </del> <ins> map_find_rand_bench!{find_rand_100,    100,    VecMap} map_find_rand_bench!{find_rand_10_000, 10_000, VecMap} </ins> <del> #[bench] pub fn find_seq_10_000(b: &mut Bencher) { let mut m = VecMap::new(); find_seq_n(10_000, &mut m, b, |m, i| { m.insert(i, 1); }, |m, i| { m.get(&i); }); } </del> <ins> map_find_seq_bench!{find_seq_100,    100,    VecMap} map_find_seq_bench!{find_seq_10_000, 10_000, VecMap} </ins> }

Related discussion:
text: the closure being passed into in BTreeMap and VecMap's benches has a trailing semi-colon making the return value , and thus making the entire operation a no-op. Removing the semi-colon causes lifetime conflict issues. CC
I have a branch that just gives up and replaces these with macros. This results in clearer and more concise code like . Confirmed produces sane results in benchmark output. Hope to submit something tomorrow.
Code change:
<ins> error[E0716]: temporary value dropped while borrowed --> $DIR/promote-no-mut.rs:3:50 | LL | static mut TEST1: Option<&mut [i32]> = Some(&mut [1, 2, 3]); |                                        ----------^^^^^^^^^- |                                        |         |        | |                                        |         |        temporary value is freed at the end of this statement |                                        |         creates a temporary which is freed while still in use |                                        using this value as a static requires that borrow lasts for `'static` error[E0716]: temporary value dropped while borrowed --> $DIR/promote-no-mut.rs:6:18 | LL |     let x = &mut [1,2,3]; |                  ^^^^^^^ creates a temporary which is freed while still in use LL |     x |     - using this value as a static requires that borrow lasts for `'static` LL | }; | - temporary value is freed at the end of this statement error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0716`. </ins>

Related discussion:
text: Consider the following code: This should just work. But instead it throws an error: The reason for this is that gets lifetime extended via promotion, so this reference now points to a separate mutable static -- but mutable statics cannot be mutated during CTFE. I see no way to fix this, other than stopping to promote mutable references -- which we should IMO do anyway, they are a very strange and unprincipled special case. Just imagine doing this in a loop, suddenly all these different and mutable allocations share the same address... Cc
Ugh, that's an ancient rule (believe it or not, it's a workaround for not being able to write and have the length be inferred!) and it was never meant to get this far, I guess I didn't think it through properly when adding the "outermost scope" rule, which is the only position where allowing it makes sense. In the current implementation, it should've never been promoted, only allowed, my bad!
Code change:
( &ty::Dynamic(ref data_a, _, src_dyn_kind), &ty::Dynamic(ref data_b, _, target_dyn_kind), <del> ) => { assert_eq!(src_dyn_kind, target_dyn_kind); </del> <ins> ) if src_dyn_kind == target_dyn_kind => { </ins> let old_info = old_info.expect("unsized_info: missing old info for trait upcasting coercion"); if data_a.principal_def_id() == data_b.principal_def_id() {

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. --<!-- 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
label +F-dyn_star
:laughing: the code thinks that this is a upcast, I think, rather than an unsize coercion. shouldn't be too hard to fix, but I may leave it for someone else. edit: nvm I'll just fix it.
Code change:
<ins> // compile-pass // edition:2018 // aux-build:gensymed.rs extern crate gensymed; fn main() {} </ins>

Related discussion:
text: The error happens on latest stable and nightly. Steps to reproduce: ; : : returns error: The error only happens if the module is named (for instance, and work without error). The error is not produced if doesn't use in any way. If doesn't contain imports but uses the library directly (e.g. ), the error is produced. always succeeds. I don't know if this is supposed to be forbidden but the error message seems to be misleading.
The second instance is injected implicitly. The error could be better, yes.
Where exactly is injected - in the library or in the test? Why does the library work on its own? Why does conflict with in the test?
Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue. is injected into both the library and the test, but only the first one causes the error. If you set in , then you'll see the error immediately while compiling - conflicts with . On 2018 edition, however, is injected in more subtle way, as where is some unique symbol that still has the string representation , but doesn't clash with anything in the same crate. Unfortunately, turns into "just " after encoding into metadata in the compiled library (this is the bug). So, when we load that library from the test it looks like the library defines two conflicting items.
The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected specifically from being encoded (it doesn't really need to be encoded).
Fixed in
Code change:
self.per_ns(|this, ns| { let key = BindingKey::new(target, ns); let _ = this.try_define(import.parent_scope.module, key, dummy_binding, false); <ins> this.update_resolution(import.parent_scope.module, key, false, |_, resolution| { resolution.single_imports.remove(&import); }) </ins> }); self.record_use(target, dummy_binding, false); } else if import.imported_module.get().is_none() {

Related discussion:
text: <!-- [31mICE[0m: Rustc '--crate-type=lib --edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' File: --code: 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
Regression in nightly-2023-02-12 found 8 bors merge commits in the specified range commit[0] 2023-02-10: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2023-02-10: Auto merge of - JulianKnodt:arrayconstval, r=cjgillot commit[2] 2023-02-11: Auto merge of - BoxyUwU:deferredprojectionequality, r=lcnr commit[3] 2023-02-11: Auto merge of - Dylan-DPC:rollup-fkl9swa, r=Dylan-DPC commit[4] 2023-02-11: Auto merge of - petrochenkov:doclink2, r=oli-obk commit[5] 2023-02-11: Auto merge of - the8472:rawvec-simpler-layout, r=thomcc commit[6] 2023-02-11: Auto merge of - matthiaskrgr:rollup-qnn380r, r=matthiaskrgr commit[7] 2023-02-11: Auto merge of - cjgillot:sroa-const, r=oli-obk ERROR: no CI builds available between and within last 167 days maybe ? ping
Code change:
#[stable(feature = "move_cell", since = "1.17.0")] pub fn swap(&self, other: &Self) { if ptr::eq(self, other) { <ins> // Swapping wouldn't change anything. </ins> return; } <ins> if !is_nonoverlapping(self, other, 1) { // See <https://github.com/rust-lang/rust/issues/80778> for why we need to stop here. panic!("`Cell::swap` on overlapping non-identical `Cell`s"); } </ins> // SAFETY: This can be risky if called from separate threads, but `Cell` // is `!Sync` so this won't happen. This also won't invalidate any // pointers since `Cell` makes sure nothing else will be pointing into <del> // either of these `Cell`s. </del> <ins> // either of these `Cell`s. We also excluded shenanigans like partially overlapping `Cell`s, // so `swap` will just properly copy two full values of type `T` back and forth. </ins> unsafe { <del> ptr::swap(self.value.get(), other.value.get()); </del> <ins> mem::swap(&mut *self.value.get(), &mut *other.value.get()); </ins> } }

Related discussion:
text: You can use , which led me to this issue (it'd be good if we could support field projection inside of and ).
While you could use to check that the tuple layout conforms to the C-like layout needed to do such projection, I don't see how your specific use of would lead to two partially overlapping though. Note that the problem is not with projecting to a single field, but to a group/subset containing multiple fields (or like in the array/slice example, to a subarray/subslice with length ).
Oh I see, you're right. False alarm.
Code change:
<ins> // issue-54966: ICE returning an unknown type with impl FnMut fn generate_duration() -> Oper<impl FnMut()> {} //~^ ERROR cannot find type `Oper` in this scope fn main() {} </ins>

Related discussion:
text: This lets you get a mutable reference to an immutable value under a specific case. Code: From what I can tell, the tuple and at least two depths of Enums are necessary, along with an on the right side. There's probably other variations, but that seems to work well enough. Expected output would be a compile error, instead output is This works on both stable and nightly
would fix this as well?
Fixed by . Off: I wonder why we can't ship nll yet. It would solve so many issues right now, because of the match ergonomics sigh Match ergonomics produces roughly 10% of all errors/unsoundness/ICEs atm (at least it feels like this)
Yes correctly fixed this issue.
Code change:
<ins> error: `#[target_feature(..)]` can only be applied to `unsafe` functions --> $DIR/issue-68060.rs:8:13 | LL |             #[target_feature(enable = "")] |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can only be applied to `unsafe` functions ... LL |             |_| (), |             ------ not an `unsafe` function error: the feature named `` is not valid for this target --> $DIR/issue-68060.rs:8:30 | LL |             #[target_feature(enable = "")] |                              ^^^^^^^^^^^ `` is not valid for this target error[E0737]: `#[track_caller]` requires Rust ABI --> $DIR/issue-68060.rs:11:13 | LL |             #[track_caller] |             ^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0737`. </ins>

Related discussion:
text: This code () Produces ICE on any channel
This is the same issue as , attributes on expressions are not converted into HIR properly.
I checked on latest nightly - isn't produced anymore while this one still throws ICE.
could you reopen this issue?
triage: P-high. Removing nomination.
Reduced somewhat:
Code change:
pub projection_bounds: Vec<PolyProjectionPredicate<'tcx>>, } <ins> impl<'tcx> ExistentialBounds<'tcx> { pub fn new(region_bound: ty::Region, builtin_bounds: BuiltinBounds, projection_bounds: Vec<PolyProjectionPredicate<'tcx>>) -> Self { let mut projection_bounds = projection_bounds; ty::sort_bounds_list(&mut projection_bounds); ExistentialBounds { region_bound: region_bound, builtin_bounds: builtin_bounds, projection_bounds: projection_bounds } } } </ins> #[derive(Clone, Copy, PartialEq, Eq, Hash, Debug)] pub struct BuiltinBounds(EnumSet<BuiltinBound>);

Related discussion:
text: It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).
Code change:
pub projection_bounds: Vec<PolyProjectionPredicate<'tcx>>, } <ins> impl<'tcx> ExistentialBounds<'tcx> { pub fn new(region_bound: ty::Region, builtin_bounds: BuiltinBounds, projection_bounds: Vec<PolyProjectionPredicate<'tcx>>) -> Self { let mut projection_bounds = projection_bounds; ty::sort_bounds_list(&mut projection_bounds); ExistentialBounds { region_bound: region_bound, builtin_bounds: builtin_bounds, projection_bounds: projection_bounds } } } </ins> #[derive(Clone, Copy, PartialEq, Eq, Hash, Debug)] pub struct BuiltinBounds(EnumSet<BuiltinBound>);

Related discussion:
text: Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/
Code change:
}); let existential_projections = bounds.projection_bounds.iter().map(|(bound, _)| { <del> bound.map_bound(|b| { if b.projection_ty.self_ty() != dummy_self { tcx.sess.delay_span_bug( DUMMY_SP, &format!("trait_ref_to_existential called on {:?} with non-dummy Self", b), ); </del> <ins> bound.map_bound(|mut b| { assert_eq!(b.projection_ty.self_ty(), dummy_self); // Like for trait refs, verify that `dummy_self` did not leak inside default type // parameters. let references_self = b.projection_ty.substs.iter().skip(1).any(|arg| { if arg.walk().any(|arg| arg == dummy_self.into()) { return true; } false }); if references_self { tcx.sess .delay_span_bug(span, "trait object projection bounds reference `Self`"); let substs: Vec<_> = b .projection_ty .substs .iter() .map(|arg| { if arg.walk().any(|arg| arg == dummy_self.into()) { return tcx.ty_error().into(); } arg }) .collect(); b.projection_ty.substs = tcx.intern_substs(&substs[..]); </ins> } ty::ExistentialProjection::erase_self_ty(tcx, b) }) });

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. --<!-- 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 was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:
Code change:
<ins> // only-x86_64 // compile-flags: -Ccode-model=large --crate-type lib // build-pass // // Regression test for issue #37508 #![no_main] #![no_std] #![feature(thread_local, lang_items)] #[lang = "eh_personality"] extern "C" fn eh_personality() {} use core::panic::PanicInfo; #[panic_handler] fn panic(_panic: &PanicInfo<'_>) -> ! { loop {} } pub struct BB; #[thread_local] static mut KEY: Key = Key { inner: BB, dtor_running: false }; pub unsafe fn set() -> Option<&'static BB> { if KEY.dtor_running { return None; } Some(&KEY.inner) } pub struct Key { inner: BB, dtor_running: bool, } </ins>

Related discussion:
text: (allowing specifying code models was to rustc in ) I want to build a large code model binary. But (correct me if I'm wrong) I believe this requires all code to be generated with a large code model (otherwise we could end up with rip relative addressing in the stdlib, which defeats the point). So I tried the obvious (controlling it with ) and got the following build log: Brief explanation of the three parts: command is run tail end of the stage1 stdlib and rustc itself being built by stage0 tail end of the stage1 stdlib and rustc itself being copied out of the stage0 build directory and into the stage1 directory, then the new stage1 rustc attempting to build the first part of the stage2 stdlib (libcore) segfaulting In fact, this stage1 rustc segfaults when not doing much: Reducing the command line used to build rustc: GDB gives the backtrace as I've dumped a bunch of info in the hope that someone might be able to lend a hand, but I can find little discussion of this feature (code models) so they may not be well-tested? I plan to investigate myself, but wanted a) to see if anyone has any pointers and b) make this a searchable issue. As a datapoint, note that redox uses a .json target specification and with , which obviously works fine. Altering the configure+make command I used to use the kernel model rather than large also worked fine. So it looks like the issue is with memory model large.
Compiling statically (with glibc, as described at ) makes it not segfault, which is interesting. Doing --enable-debug in configure also makes it not segfault. I starting to suspect the issue is in llvm (I don't think anything in the rust compiler itself generates asm?) and rust tickles the bug somehow.
Recompiling just the libstd crate without optimisations makes it work. It appears that start , which attempts to calls . calls on linux. By inspection of the parameters passed to in the linux implementation of with gdb, the parameter is an invalid pointer (checked by inspecting by ). In theory should be in steps 2 and 3, though the functions look like they've all been inlined.