jiebi/CodeConvo huggingface dataset:
Code change:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

Related discussion:
text: <ins> // 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. trait Foo {} impl<'a> Foo for Foo+'a {} //~^ ERROR the object type `Foo + 'a` automatically implements the trait `Foo` fn main() {} </ins>
Code change:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

Related discussion:
text: <ins> // 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. // ignore-tidy-linelength use std::ops::Add; fn main() { let x = &10 as //~^ ERROR the value of the associated type `Output` (from the trait `core::ops::Add`) must be specified &Add; //~^ ERROR the type parameter `RHS` must be explicitly specified in an object type because its default value `Self` references the type `Self` } </ins>
Code change:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

Related discussion:
text: <ins> // 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. extern crate libc; fn main() { let foo: *mut libc::c_void; let cb: &mut Fn() = unsafe { &mut *(foo as *mut Fn()) //~^ ERROR use of possibly uninitialized variable: `foo` }; } </ins>
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: use self::Arch::*; #[allow(non_camel_case_types)] <ins> #[derive(Copy)] </ins> pub enum Arch { Armv7, Armv7s,
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: "-Wl,-syslibroot".to_string(), get_sdk_root(sdk_name)] } <ins> fn target_cpu(arch: Arch) -> String { match arch { X86_64 => "x86-64", _ => "generic", }.to_string() } </ins> pub fn opts(arch: Arch) -> TargetOptions { TargetOptions { <ins> cpu: target_cpu(arch), </ins> dynamic_linking: false, executables: true, // Although there is an experimental implementation of LLVM which
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: pub fn target() -> Target { let mut base = super::apple_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.eliminate_frame_pointer = false; base.pre_link_args.push("-m64".to_string());
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: pub fn target() -> Target { let mut base = super::windows_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> // On Win64 unwinding is handled by the OS, so we can link libgcc statically. base.pre_link_args.push("-static-libgcc".to_string()); base.pre_link_args.push("-m64".to_string());
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: pub fn target() -> Target { let mut base = super::dragonfly_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: pub fn target() -> Target { let mut base = super::freebsd_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {
Code change:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

Related discussion:
text: pub fn target() -> Target { let mut base = super::linux_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {
Code change:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.

Related discussion:
text: ext::log_syntax::expand_syntax_ext)); syntax_expanders.insert(intern("derive"), Decorator(box ext::deriving::expand_meta_derive)); <ins> syntax_expanders.insert(intern("deriving"), Decorator(box ext::deriving::expand_deprecated_deriving)); </ins> if ecfg.enable_quotes { // Quasi-quoting expanders
Code change:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.

Related discussion:
text: pub mod generic; <ins> pub fn expand_deprecated_deriving(cx: &mut ExtCtxt, span: Span, _: &MetaItem, _: &Item, _: Box<FnMut(P<Item>)>) { cx.span_err(span, "`deriving` has been renamed to `derive`"); } </ins> pub fn expand_meta_derive(cx: &mut ExtCtxt, _span: Span, mitem: &MetaItem,
Code change:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.

Related discussion:
text: <ins> // 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. #[deriving(Clone)] //~ ERROR `deriving` has been renamed to `derive` struct Foo; fn main() {} </ins>
Code change:
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .

Related discussion:
text: use middle::infer::InferCtxt; use middle::ty::{self, ToPredicate, HasTypeFlags, ToPolyTraitRef, TraitRef, Ty}; use middle::ty::fold::TypeFoldable; <del> use std::collections::HashMap; </del> <ins> use util::nodemap::{FnvHashMap, FnvHashSet}; </ins> use std::fmt; use syntax::codemap::Span; use syntax::attr::{AttributeMethods, AttrMetaMethods};
Code change:
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .

Related discussion:
text: (gen.name.as_str().to_string(), trait_ref.substs.types.get(param, i) .to_string()) <del> }).collect::<HashMap<String, String>>(); </del> <ins> }).collect::<FnvHashMap<String, String>>(); </ins> generic_map.insert("Self".to_string(), trait_ref.self_ty().to_string()); let parser = Parser::new(&istring);
Code change:
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .

Related discussion:
text: "the trait `{}` cannot be made into an object", tcx.item_path_str(trait_def_id)); <ins> let mut reported_violations = FnvHashSet(); </ins> for violation in violations { <ins> if !reported_violations.insert(violation.clone()) { continue; } </ins> match violation { ObjectSafetyViolation::SizedSelf => { tcx.sess.fileline_note(
Code change:
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .

Related discussion:
text: use std::rc::Rc; use syntax::ast; <del> #[derive(Debug)] </del> <ins> #[derive(Clone, Debug, PartialEq, Eq, Hash)] </ins> pub enum ObjectSafetyViolation<'tcx> { /// Self : Sized declared on the trait SizedSelf,
Code change:
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .

Related discussion:
text: } } <ins> impl<'tcx> PartialEq for Method<'tcx> { #[inline] fn eq(&self, other: &Self) -> bool { self.def_id == other.def_id } } impl<'tcx> Eq for Method<'tcx> {} impl<'tcx> Hash for Method<'tcx> { #[inline] fn hash<H: Hasher>(&self, s: &mut H) { self.def_id.hash(s) } } </ins> #[derive(Clone, Copy, Debug)] pub struct AssociatedConst<'tcx> { pub name: Name,