jiebi/CodeConvo huggingface dataset:
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. --<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

Related discussion:
text: err.help("you could instead create a new `enum` with a variant for each returned type"); } <del> fn is_return_ty_unsized<'a>(&self, fcx: &FnCtxt<'a, 'tcx>, blk_id: hir::HirId) -> bool { if let Some((_, fn_decl, _)) = fcx.get_fn_decl(blk_id) && let hir::FnRetTy::Return(ty) = fn_decl.output && let ty = fcx.astconv().ast_ty_to_ty( ty) && let ty::Dynamic(..) = ty.kind() { return true; </del> <ins> /// Checks whether the return type is unsized via an obligation, which makes /// sure we consider `dyn Trait: Sized` where clauses, which are trivially /// false but technically valid for typeck. fn is_return_ty_definitely_unsized(&self, fcx: &FnCtxt<'_, 'tcx>) -> bool { if let Some(sig) = fcx.body_fn_sig() { !fcx.predicate_may_hold(&Obligation::new( fcx.tcx, ObligationCause::dummy(), fcx.param_env, ty::TraitRef::new( fcx.tcx, fcx.tcx.require_lang_item(hir::LangItem::Sized, None), [sig.output()], ), )) } else { false </ins> } <del> false </del> } pub fn complete<'a>(self, fcx: &FnCtxt<'a, 'tcx>) -> Ty<'tcx> {
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. --<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

Related discussion:
text: <ins> trait Trait<T> {} fn foo<T>() -> dyn Trait<T> where dyn Trait<T>: Sized, // pesky sized predicate { 42 //~^ ERROR mismatched types } fn main() {} </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. --<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/return-dyn-type-mismatch-2.rs:7:5 | LL | fn foo<T>() -> dyn Trait<T> |                ------------ expected `(dyn Trait<T> + 'static)` because of return type ... LL |     42 |     ^^ expected `dyn Trait`, found integer | = note: expected trait object `(dyn Trait<T> + 'static)` found type `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

Related discussion:
text: <ins> pub trait TestTrait { type MyType; fn func() -> Option<Self> where Self: Sized; } impl<T> dyn TestTrait<MyType = T> where Self: Sized, // pesky sized predicate { fn other_func() -> dyn TestTrait<MyType = T> { match Self::func() { None => None, //~^ ERROR mismatched types } } } fn main() {} </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. --<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/return-dyn-type-mismatch.rs:15:21 | LL |     fn other_func() -> dyn TestTrait<MyType = T> { |                        ------------------------- expected `(dyn TestTrait<MyType = T> + 'static)` because of return type LL |         match Self::func() { LL |             None => None, |                     ^^^^ expected `dyn TestTrait`, found `Option<_>` | = note: expected trait object `(dyn TestTrait<MyType = T> + 'static)` found enum `Option<_>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
Tello-edu The says use my build failed with error <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc could you provide some input here? Thanks!
The rustdoc book documents rustdoc flags. You are passing this flag to cargo. I don't remember how to configure cargo for this argument off the top of my head, but you should look in the cargo book for how.
Oh wait, apparently the rustdoc book directly documents using this with it's probably just outdated then - I'll transfer this to rust-lang/rust.
Btw it works fine after taking out the "=examples"
claim

Related discussion:
text: This feature is unstable, so you can enable it by calling Rustdoc with the unstable `rustdoc-scrape-examples` flag: ```bash <del> cargo doc -Zunstable-options -Zrustdoc-scrape-examples=examples </del> <ins> cargo doc -Zunstable-options -Zrustdoc-scrape-examples </ins> ``` To enable this feature on [docs.rs](https://docs.rs), add this to your Cargo.toml: ```toml [package.metadata.docs.rs] <del> cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples=examples"] </del> <ins> cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples"] </ins> ```
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexMap}; use rustc_errors::{Applicability, DiagnosticArgValue, DiagnosticId, IntoDiagnosticArg}; use rustc_hir::def::Namespace::{self, *}; <del> use rustc_hir::def::{self, CtorKind, DefKind, LifetimeRes, PartialRes, PerNS}; </del> <ins> use rustc_hir::def::{self, CtorKind, DefKind, LifetimeRes, NonMacroAttrKind, PartialRes, PerNS}; </ins> use rustc_hir::def_id::{DefId, LocalDefId, CRATE_DEF_ID, LOCAL_CRATE}; use rustc_hir::{BindingAnnotation, PrimTy, TraitCandidate}; use rustc_middle::middle::resolve_bound_vars::Set1;
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: } } <del> fn resolve_and_cache_rustdoc_path(&mut self, path_str: &str, ns: Namespace) -> bool { </del> <ins> fn resolve_and_cache_rustdoc_path(&mut self, path_str: &str, ns: Namespace) -> Option<Res> { </ins> // FIXME: This caching may be incorrect in case of multiple `macro_rules` // items with the same name in the same module. // Also hygiene is not considered. let mut doc_link_resolutions = std::mem::take(&mut self.r.doc_link_resolutions); <del> let res = doc_link_resolutions </del> <ins> let res = *doc_link_resolutions </ins> .entry(self.parent_scope.module.nearest_parent_mod().expect_local()) .or_default() .entry((Symbol::intern(path_str), ns))
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: return None; } res <del> }) .is_some(); </del> <ins> }); </ins> self.r.doc_link_resolutions = doc_link_resolutions; res }
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: let mut any_resolved = false; let mut need_assoc = false; for ns in [TypeNS, ValueNS, MacroNS] { <del> if self.resolve_and_cache_rustdoc_path(&path_str, ns) { any_resolved = true; </del> <ins> if let Some(res) = self.resolve_and_cache_rustdoc_path(&path_str, ns) { // Rustdoc ignores tool attribute resolutions and attempts // to resolve their prefixes for diagnostics. any_resolved = !matches!(res, Res::NonMacroAttr(NonMacroAttrKind::Tool)); </ins> } else if ns != MacroNS { need_assoc = true; }
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: Def(kind, id) => Ok(Res::Def(kind, id)), PrimTy(prim) => Ok(Res::Primitive(PrimitiveType::from_hir(prim))), // e.g. `#[derive]` <del> NonMacroAttr(..) | Err => Result::Err(()), </del> <ins> ToolMod | NonMacroAttr(..) | Err => Result::Err(()), </ins> other => bug!("unrecognized res {:?}", other), } }
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: <ins> // Regression test for <https://github.com/rust-lang/rust/issues/111189>. // This test ensures that it doesn't crash. #![deny(warnings)] /// #[rustfmt::skip] //~^ ERROR unresolved link to `rustfmt::skip` /// #[clippy::whatever] //~^ ERROR unresolved link to `clippy::whatever` pub fn foo() {} </ins>
Code change:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Related discussion:
text: <ins> error: unresolved link to `rustfmt::skip` --> $DIR/issue-111189-resolution-ice.rs:6:7 | LL | /// #[rustfmt::skip] |       ^^^^^^^^^^^^^ no item named `rustfmt` in scope | note: the lint level is defined here --> $DIR/issue-111189-resolution-ice.rs:4:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(rustdoc::broken_intra_doc_links)]` implied by `#[deny(warnings)]` error: unresolved link to `clippy::whatever` --> $DIR/issue-111189-resolution-ice.rs:8:7 | LL | /// #[clippy::whatever] |       ^^^^^^^^^^^^^^^^ no item named `clippy` in scope error: aborting due to 2 previous errors </ins>
Code change:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

Related discussion:
text: ) -> Result<std::ops::Range<BasicBlock>, &'static str> { let callee_attrs = self.tcx.codegen_fn_attrs(callsite.callee.def_id()); self.check_codegen_attributes(callsite, callee_attrs)?; <ins> let terminator = caller_body[callsite.block].terminator.as_ref().unwrap(); let TerminatorKind::Call { args, destination, .. } = &terminator.kind else { bug!() }; let destination_ty = destination.ty(&caller_body.local_decls, self.tcx).ty; for arg in args { if !arg.ty(&caller_body.local_decls, self.tcx).is_sized(self.tcx, self.param_env) { // We do not allow inlining functions with unsized params. Inlining these functions // could create unsized locals, which are unsound and being phased out. return Err("Call has unsized argument"); } } </ins> self.check_mir_is_available(caller_body, &callsite.callee)?; let callee_body = try_instance_mir(self.tcx, callsite.callee.def)?; self.check_mir_body(callsite, callee_body, callee_attrs)?;
Code change:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

Related discussion:
text: // Check call signature compatibility. // Normally, this shouldn't be required, but trait normalization failure can create a // validation ICE. <del> let terminator = caller_body[callsite.block].terminator.as_ref().unwrap(); let TerminatorKind::Call { args, destination, .. } = &terminator.kind else { bug!() }; let destination_ty = destination.ty(&caller_body.local_decls, self.tcx).ty; </del> let output_type = callee_body.return_ty(); if !util::is_subtype(self.tcx, self.param_env, output_type, destination_ty) { trace!(?output_type, ?destination_ty);
Code change:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

Related discussion:
text: <ins> - // MIR for `caller` before Inline + // MIR for `caller` after Inline fn caller(_1: Box<[i32]>) -> () { debug x => _1;                       // in scope 0 at $DIR/unsized_argument.rs:+0:11: +0:12 let mut _0: ();                      // return place in scope 0 at $DIR/unsized_argument.rs:+0:26: +0:26 let _2: ();                          // in scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 let mut _3: std::boxed::Box<[i32]>;  // in scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 let mut _4: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _5: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _6: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _7: *const [i32];            // in scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 bb0: { StorageLive(_2);                 // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 StorageLive(_3);                 // scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 _3 = move _1;                    // scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 _7 = (((_3.0: std::ptr::Unique<[i32]>).0: std::ptr::NonNull<[i32]>).0: *const [i32]); // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 _2 = callee(move (*_7)) -> [return: bb3, unwind: bb4]; // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:5: 9:11 // + literal: Const { ty: fn([i32]) {callee}, val: Value(<ZST>) } } bb1: { StorageDead(_3);                 // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 StorageDead(_2);                 // scope 0 at $DIR/unsized_argument.rs:+1:15: +1:16 _0 = const ();                   // scope 0 at $DIR/unsized_argument.rs:+0:26: +2:2 return;                          // scope 0 at $DIR/unsized_argument.rs:+2:2: +2:2 } bb2 (cleanup): { resume;                          // scope 0 at $DIR/unsized_argument.rs:+0:1: +2:2 } bb3: { _4 = alloc::alloc::box_free::<[i32], std::alloc::Global>(move (_3.0: std::ptr::Unique<[i32]>), move (_3.1: std::alloc::Global)) -> bb1; // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:14: 9:15 // + literal: Const { ty: unsafe fn(Unique<[i32]>, std::alloc::Global) {alloc::alloc::box_free::<[i32], std::alloc::Global>}, val: Value(<ZST>) } } bb4 (cleanup): { _6 = alloc::alloc::box_free::<[i32], std::alloc::Global>(move (_3.0: std::ptr::Unique<[i32]>), move (_3.1: std::alloc::Global)) -> [return: bb2, unwind terminate]; // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:14: 9:15 // + literal: Const { ty: unsafe fn(Unique<[i32]>, std::alloc::Global) {alloc::alloc::box_free::<[i32], std::alloc::Global>}, val: Value(<ZST>) } } } </ins>
Code change:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

Related discussion:
text: <ins> // needs-unwind #![feature(unsized_fn_params)] #[inline(always)] fn callee(y: [i32]) {} // EMIT_MIR unsized_argument.caller.Inline.diff fn caller(x: Box<[i32]>) { callee(*x); } fn main() { let b = Box::new([1]); caller(b); } </ins>
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: } } <del> /// Whether `check_binop` allows overloaded operators to be invoked. </del> <ins> /// Whether `check_binop` is part of an assignment or not. /// Used to know wether we allow user overloads and to print /// better messages on error. </ins> #[deriving(Eq)] <del> enum AllowOverloadedOperatorsFlag { AllowOverloadedOperators, DontAllowOverloadedOperators, </del> <ins> enum IsBinopAssignment{ SimpleBinop, BinopAssignment, </ins> } #[deriving(Clone)]
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: rhs: @ast::Expr, // Used only in the error case expected_result: Option<ty::t>, <del> allow_overloaded_operators: AllowOverloadedOperatorsFlag </del> <ins> is_binop_assignment: IsBinopAssignment </ins> ) { let tcx = fcx.ccx.tcx;