jiebi/CodeConvo huggingface dataset:
Code change:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

Related discussion:
text: <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. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2u32.pow(1024); } </ins>
Code change:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

Related discussion:
text: <del> // Copyright 2015 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. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2i32.pow(1024); } </del>
Code change:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

Related discussion:
text: // each trait in the system to its implementations. <del> use metadata::csearch::{each_impl, get_impl_trait}; </del> <ins> use metadata::csearch::{each_impl, get_impl_trait, each_implementation_for_trait}; </ins> use metadata::csearch; use middle::ty::get; use middle::ty::{ImplContainer, lookup_item_type, subst};
Code change:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

Related discussion:
text: pub fn check_implementation_coherence_of(&self, trait_def_id: DefId) { // Unify pairs of polytypes. <del> self.iter_impls_of_trait(trait_def_id, |a| { </del> <ins> self.iter_impls_of_trait_local(trait_def_id, |a| { </ins> let implementation_a = a; let polytype_a = self.get_self_type_for_implementation(implementation_a);
Code change:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

Related discussion:
text: if self.polytypes_unify(polytype_a.clone(), polytype_b) { let session = self.crate_context.tcx.sess; session.span_err( <del> self.span_of_impl(implementation_b), </del> <ins> self.span_of_impl(implementation_a), </ins> format!("conflicting implementations for trait `{}`", ty::item_path_str(self.crate_context.tcx, trait_def_id))); <del> session.span_note(self.span_of_impl(implementation_a), "note conflicting implementation here"); </del> <ins> if implementation_b.did.crate == LOCAL_CRATE { session.span_note(self.span_of_impl(implementation_b), "note conflicting implementation here"); } else { let crate_store = self.crate_context.tcx.sess.cstore; let cdata = crate_store.get_crate_data(implementation_b.did.crate); session.note( "conflicting implementation in crate `" + cdata.name + "`"); } </ins> } } })
Code change:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

Related discussion:
text: } pub fn iter_impls_of_trait(&self, trait_def_id: DefId, f: |@Impl|) { <ins> self.iter_impls_of_trait_local(trait_def_id, |x| f(x)); if trait_def_id.crate == LOCAL_CRATE { return; } let crate_store = self.crate_context.tcx.sess.cstore; csearch::each_implementation_for_trait(crate_store, trait_def_id, |impl_def_id| { let implementation = @csearch::get_impl(self.crate_context.tcx, impl_def_id); let _ = lookup_item_type(self.crate_context.tcx, implementation.did); f(implementation); }); } pub fn iter_impls_of_trait_local(&self, trait_def_id: DefId, f: |@Impl|) { </ins> let trait_impls = self.crate_context.tcx.trait_impls.borrow(); match trait_impls.get().find(&trait_def_id) { Some(impls) => {
Code change:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

Related discussion:
text: <ins> // Copyright 2012 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. pub trait Foo { } impl Foo for int { } </ins>
Code change:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

Related discussion:
text: <ins> // Copyright 2014 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. // Regression test for #3512 - conflicting trait impls in different crates should give a // 'conflicting implementations' error message. // aux-build:trait_impl_conflict.rs extern mod trait_impl_conflict; use trait_impl_conflict::Foo; impl<A> Foo for A { //~^ ERROR conflicting implementations for trait `trait_impl_conflict::Foo` //~^^ ERROR cannot provide an extension implementation where both trait and type are not defined in this crate } fn main() { } </ins>
Code change:
From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

Related discussion:
text: let &(ref first_arm_pats, _) = &arms[0]; let first_pat = &first_arm_pats[0]; let span = first_pat.span; <del> span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern"); </del> <ins> struct_span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern") .span_label(span, &format!("irrefutable pattern")) .emit(); </ins> }, hir::MatchSource::ForLoopDesugar => {
Code change:
From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

Related discussion:
text: tcx.sess.add_lint(lint::builtin::MATCH_OF_UNIT_VARIANT_VIA_PAREN_DOTDOT, pat.id, pat.span, msg); } else { <del> span_err!(tcx.sess, pat.span, E0164, "{}", msg); </del> <ins> struct_span_err!(tcx.sess, pat.span, E0164, "{}", msg) .span_label(pat.span, &format!("not a tuple variant or struct")).emit(); </ins> on_error(); } };
Code change:
From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

Related discussion:
text: .emit(); } Err(CopyImplementationError::HasDestructor) => { <del> span_err!(tcx.sess, span, E0184, </del> <ins> struct_span_err!(tcx.sess, span, E0184, </ins> "the trait `Copy` may not be implemented for this type;  <del> the type has a destructor"); </del> <ins> the type has a destructor") .span_label(span, &format!("Copy not allowed on types with destructors")) .emit(); </ins> } } });
Code change:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

Related discussion:
text: return Error(span, "missing fragment specifier".to_string()); } } <del> TokenTree::MetaVarDecl(..) => { </del> <ins> TokenTree::MetaVarDecl(_, _, id) => { </ins> // Built-in nonterminals never start with these tokens, // so we can eliminate them from consideration. <del> match *token { token::CloseDelim(_) => {}, _ => bb_eis.push(ei), </del> <ins> if may_begin_with(&*id.name.as_str(), token) { bb_eis.push(ei); </ins> } } seq @ TokenTree::Delimited(..) | seq @ TokenTree::Token(_, DocComment(..)) => {
Code change:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

Related discussion:
text: // except according to those terms. fn main() { <del> panic!(@); //~ ERROR expected expression, found `@` </del> <ins> panic!(@); //~ ERROR no rules expected the token `@` </ins> }
Code change:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

Related discussion:
text: // except according to those terms. pub fn main() { <del> vec![,]; //~ ERROR expected expression, found `,` </del> <ins> vec![,]; //~ ERROR no rules expected the token `,` </ins> }
Code change:
Can you provide more assistance in debugging as well? For example what was at line 896 of What configuration did you provide? etc.
Relevant line is a part of At that point anything pertaining i686 in my were Replacing with does still result in the same error. For now, I just specified for 32 bit version of LLVM I have, which works.
Ah ok, thanks for the info! Right now this should be a better error (of course) but the cause is how rustbuild treats the and arrays in the configuration. No C++ compilers are found for the array, so you can't request any host-related targets (e.g. LLVM) when a triple is only mentioned in the array. You can fix this by moving the target to the array.

Related discussion:
text: /// Returns the path to the C++ compiler for the target specified, may panic /// if no C++ compiler was configured for the target. fn cxx(&self, target: &str) -> &Path { <del> self.cxx[target].path() </del> <ins> match self.cxx.get(target) { Some(p) => p.path(), None => panic!("nntarget `{}` is not configured as a host, only as a targetnn", target), } </ins> } /// Returns flags to pass to the compiler to generate code for `target`.
Code change:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

Related discussion:
text: "codegen-units"); suite("check-incremental", "src/test/incremental", "incremental", "incremental"); <del> suite("check-ui", "src/test/ui", "ui", "ui"); </del> } if build.config.build.contains("msvc") {
Code change:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

Related discussion:
text: }); }; <ins> suite("check-ui", "src/test/ui", "ui", "ui"); </ins> suite("check-rpass-full", "src/test/run-pass-fulldeps", "run-pass", "run-pass-fulldeps"); suite("check-rfail-full", "src/test/run-fail-fulldeps",
Code change:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

Related discussion:
text: assert!(plan.iter().any(|s| s.name.contains("-ui"))); assert!(plan.iter().any(|s| s.name.contains("cfail"))); <del> assert!(plan.iter().any(|s| s.name.contains("cfail"))); </del> assert!(plan.iter().any(|s| s.name.contains("cfail-full"))); assert!(plan.iter().any(|s| s.name.contains("codegen-units"))); assert!(plan.iter().any(|s| s.name.contains("debuginfo")));
Code change:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

Related discussion:
text: assert!(plan.iter().all(|s| s.host == "A")); assert!(plan.iter().all(|s| s.target == "C")); <del> assert!(plan.iter().any(|s| s.name.contains("-ui"))); assert!(plan.iter().any(|s| s.name.contains("cfail"))); </del> <ins> assert!(!plan.iter().any(|s| s.name.contains("-ui"))); </ins> assert!(plan.iter().any(|s| s.name.contains("cfail"))); assert!(!plan.iter().any(|s| s.name.contains("cfail-full"))); assert!(plan.iter().any(|s| s.name.contains("codegen-units")));
Code change:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

Related discussion:
text: <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. // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro, proc_macro_lib)] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Foo)] pub fn derive_foo(input: TokenStream) -> TokenStream { input } #[proc_macro_derive(Bar)] pub fn derive_bar(input: TokenStream) -> TokenStream { panic!("lolnope"); } </ins>