jiebi/CodeConvo huggingface dataset:
Code change:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: needs_to_be_read = true; } } <del> PatKind::TupleStruct(..) | PatKind::Path(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { // If the PatKind is a TupleStruct, Path, Struct or Tuple then we want to check // whether the Variant is a MultiVariant or a SingleVariant. We only want // to borrow discr if it is a MultiVariant. // If it is a SingleVariant and creates a binding we will handle that when // this callback gets called again. // Get the type of the Place after all projections have been applied let place_ty = place.place.ty(); if let ty::Adt(def, _) = place_ty.kind() { if def.variants.len() > 1 { </del> <ins> PatKind::Path(qpath) => { // A `Path` pattern is just a name like `Foo`. This is either a // named constant or else it refers to an ADT variant let res = self.mc.typeck_results.qpath_res(qpath, pat.hir_id); match res { Res::Def(DefKind::Const, _) | Res::Def(DefKind::AssocConst, _) => { // Named constants have to be equated with the value // being matched, so that's a read of the value being matched. // // FIXME: We don't actually  reads for ZSTs. </ins> needs_to_be_read = true; } <del> } else { // If it is not ty::Adt, then it should be read needs_to_be_read = true; </del> <ins> _ => { // Otherwise, this is a struct/enum variant, and so it's // only a read if we need to read the discriminant. needs_to_be_read |= is_multivariant_adt(place.place.ty()); } </ins> } } <ins> PatKind::TupleStruct(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { // For `Foo(..)`, `Foo { ... }` and `(...)` patterns, check if we are matching // against a multivariant enum or struct. In that case, we have to read // the discriminant. Otherwise this kind of pattern doesn't actually // read anything (we'll get invoked for the `...`, which may indeed // perform some reads). let place_ty = place.place.ty(); needs_to_be_read |= is_multivariant_adt(place_ty); } </ins> PatKind::Lit(_) | PatKind::Range(..) => { // If the PatKind is a Lit or a Range then we want // to borrow discr.
Code change:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: } } } <ins> fn is_multivariant_adt(ty: Ty<'tcx>) -> bool { if let ty::Adt(def, _) = ty.kind() { def.variants.len() > 1 } else { false } } </ins>
Code change:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: <ins> // edition:2021 #[derive(Copy, Clone, PartialEq, Eq)] pub struct Opcode(pub u8); impl Opcode { pub const OP1: Opcode = Opcode(0x1); } pub fn example1(msg_type: Opcode) -> impl FnMut(&[u8]) { move |i| match msg_type { //~^ ERROR: non-exhaustive patterns: `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered Opcode::OP1 => unimplemented!(), } } #[derive(Copy, Clone, PartialEq, Eq)] pub struct Opcode2(Opcode); impl Opcode2 { pub const OP2: Opcode2 = Opcode2(Opcode(0x1)); } pub fn example2(msg_type: Opcode2) -> impl FnMut(&[u8]) { move |i| match msg_type { //~^ ERROR: non-exhaustive patterns: `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered Opcode2::OP2=> unimplemented!(), } } fn main() {} </ins>
Code change:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: <ins> error[E0004]: non-exhaustive patterns: `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered --> $DIR/issue-88331.rs:11:20 | LL | pub struct Opcode(pub u8); | -------------------------- `Opcode` defined here ... LL |     move |i| match msg_type { |                    ^^^^^^^^ patterns `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `Opcode` error[E0004]: non-exhaustive patterns: `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered --> $DIR/issue-88331.rs:27:20 | LL | pub struct Opcode2(Opcode); | --------------------------- `Opcode2` defined here ... LL |     move |i| match msg_type { |                    ^^^^^^^^ patterns `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `Opcode2` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0004`. </ins>
Code change:
<!-- 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. --code from glacier/fixed/-1.rs <!-- 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
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

Related discussion:
text: use rustc_middle::mir::visit::{MutatingUseContext, NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::*; use rustc_middle::ty::cast::CastTy; <del> use rustc_middle::ty::subst::GenericArgKind; </del> <ins> use rustc_middle::ty::subst::{GenericArgKind, InternalSubsts}; </ins> use rustc_middle::ty::{self, adjustment::PointerCast, Instance, InstanceDef, Ty, TyCtxt}; use rustc_middle::ty::{Binder, TraitPredicate, TraitRef}; use rustc_span::{sym, Span, Symbol};
Code change:
<!-- 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. --code from glacier/fixed/-1.rs <!-- 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
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

Related discussion:
text: let fn_ty = func.ty(body, tcx); <del> let (mut callee, substs) = match *fn_ty.kind() { </del> <ins> let (mut callee, mut substs) = match *fn_ty.kind() { </ins> ty::FnDef(def_id, substs) => (def_id, substs), ty::FnPtr(_) => {
Code change:
<!-- 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. --code from glacier/fixed/-1.rs <!-- 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
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

Related discussion:
text: .iter() .find(|did| tcx.item_name(**did) == callee_name) { <ins> // using internal substs is ok here, since this is only // used for the `resolve` call below substs = InternalSubsts::identity_for_item(tcx, did); </ins> callee = did; } } <del> _ => { if !tcx.is_const_fn_raw(callee) { // At this point, it is only legal when the caller is marked with // #[default_method_body_is_const], and the callee is in the same // trait. let callee_trait = tcx.trait_of_item(callee); if callee_trait.is_some() { if tcx.has_attr(caller, sym::default_method_body_is_const) { if tcx.trait_of_item(caller) == callee_trait { nonconst_call_permission = true; } </del> <ins> _ if !tcx.is_const_fn_raw(callee) => { // At this point, it is only legal when the caller is marked with // #[default_method_body_is_const], and the callee is in the same // trait. let callee_trait = tcx.trait_of_item(callee); if callee_trait.is_some() { if tcx.has_attr(caller, sym::default_method_body_is_const) { if tcx.trait_of_item(caller) == callee_trait { nonconst_call_permission = true; </ins> } } <ins> } </ins> <del> if !nonconst_call_permission { self.check_op(ops::FnCallNonConst); return; } </del> <ins> if !nonconst_call_permission { self.check_op(ops::FnCallNonConst); return; </ins> } } <ins> _ => {} </ins> } // Resolve a trait method call to its concrete implementation, which may be in a
Code change:
<!-- 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. --code from glacier/fixed/-1.rs <!-- 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
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

Related discussion:
text: <ins> // build-pass #![feature(const_trait_impl)] trait Func<T> { type Output; fn call_once(self, arg: T) -> Self::Output; } struct Closure; impl const Func<&usize> for Closure { type Output = usize; fn call_once(self, arg: &usize) -> Self::Output { *arg } } enum Bug<T = [(); Closure.call_once(&0) ]> { V(T), } fn main() {} </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!

Related discussion:
text: <del> Subproject commit 7a2f1cadcd5120c44eda3596053de767cd8173a2 </del> <ins> Subproject commit 035933186957cf81c488261fb48a98bf523e8006 </ins>
Code change:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

Related discussion:
text: //! Enforces the Rust effect system. Currently there is just one effect, /// `unsafe`. <del> use middle::ty::{ty_bare_fn, ty_closure, ty_ptr}; </del> use middle::ty; use middle::typeck::method_map; use util::ppaux; <del> use syntax::ast::{UnDeref, ExprCall, ExprInlineAsm, ExprMethodCall}; use syntax::ast::{ExprUnary, unsafe_fn, ExprPath}; </del> use syntax::ast; use syntax::codemap::Span; <del> use syntax::visit::{fk_item_fn, fk_method}; </del> use syntax::visit; <del> use syntax::visit::{Visitor,fn_kind}; use syntax::ast::{fn_decl,Block,NodeId,Expr}; </del> <ins> use syntax::visit::Visitor; </ins> #[deriving(Eq)] enum UnsafeContext {
Code change:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

Related discussion:
text: UnsafeBlock(ast::NodeId), } <del> struct Context { /// The method map. method_map: method_map, /// Whether we're in an unsafe context. unsafe_context: UnsafeContext, } </del> fn type_is_unsafe_function(ty: ty::t) -> bool { match ty::get(ty).sty { <del> ty_bare_fn(ref f) => f.purity == unsafe_fn, ty_closure(ref f) => f.purity == unsafe_fn, </del> <ins> ty::ty_bare_fn(ref f) => f.purity == ast::unsafe_fn, ty::ty_closure(ref f) => f.purity == ast::unsafe_fn, </ins> _ => false, } } struct EffectCheckVisitor { tcx: ty::ctxt, <del> context: @mut Context, </del> <ins> /// The method map. method_map: method_map, /// Whether we're in an unsafe context. unsafe_context: UnsafeContext, </ins> } impl EffectCheckVisitor { fn require_unsafe(&mut self, span: Span, description: &str) { <del> match self.context.unsafe_context { </del> <ins> match self.unsafe_context { </ins> SafeContext => { // Report an error. self.tcx.sess.span_err(span,
Code change:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

Related discussion:
text: <ins> // Copyright 2013 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. fn main() { let mut s = ~"test"; s[0] = 3; //~ ERROR: not allowed s[0] += 3; //~ ERROR: not allowed { let _a = &mut s[0]; //~ ERROR: not allowed } } </ins>