jiebi/CodeConvo huggingface dataset:
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

Related discussion:
text: <ins> // Copyright 2017 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 a = |r: f64| if r != 0.0(r != 0.0) { 1.0 } else { 0.0 }; //~^ ERROR expected function, found `{float}` } </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

Related discussion:
text: <ins> // Copyright 2017 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. // #45662 #![feature(repr_align)] #![feature(attr_literals)] #[repr(align(16))] pub struct A { y: i64, } pub extern "C" fn foo(x: A) {} fn main() {} </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

Related discussion:
text: <ins> // Copyright 2017 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. #![feature(conservative_impl_trait)] use std::iter::once; struct Foo { x: i32, } impl Foo { fn inside(&self) -> impl Iterator<Item = &i32> { once(&self.x) } } fn main() { println!("hi"); } </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

Related discussion:
text: <ins> // Copyright 2017 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. #![feature(unsize, coerce_unsized)] #[repr(packed)] struct UnalignedPtr<'a, T: ?Sized> where T: 'a, { data: &'a T, } fn main() { impl<'a, T, U> std::ops::CoerceUnsized<UnalignedPtr<'a, U>> for UnalignedPtr<'a, T> where T: std::marker::Unsize<U> + ?Sized, U: ?Sized, { } let arr = [1, 2, 3]; let arr_unaligned: UnalignedPtr<[i32; 3]> = UnalignedPtr { data: &arr }; let arr_unaligned: UnalignedPtr<[i32]> = arr_unaligned; } </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

Related discussion:
text: <ins> // Copyright 2017 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. // #42164 #![feature(decl_macro)] #![allow(dead_code)] pub macro m($inner_str:expr) { #[doc = $inner_str] struct S; } macro_rules! define_f { ($name:expr) => { #[export_name = $name] fn f() {} } } fn main() { define_f!(concat!("exported_", "f")); m!(stringify!(foo)); } </ins>
Code change:
Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> use rustc_serialize::{Encodable, Decodable, Encoder, Decoder}; </del> use rustc_data_structures::stable_hasher; use std::mem; use std::slice; <del> #[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Clone, Copy)] </del> <ins> #[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Clone, Copy, RustcEncodable, RustcDecodable)] </ins> pub struct Fingerprint(u64, u64); impl Fingerprint {
Code change:
Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:

Related discussion:
text: } } <del> impl Encodable for Fingerprint { #[inline] fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { s.emit_u64(self.0.to_le())?; s.emit_u64(self.1.to_le()) } } impl Decodable for Fingerprint { #[inline] fn decode<D: Decoder>(d: &mut D) -> Result<Fingerprint, D::Error> { let _0 = u64::from_le(d.read_u64()?); let _1 = u64::from_le(d.read_u64()?); Ok(Fingerprint(_0, _1)) } } </del> impl ::std::fmt::Display for Fingerprint { fn fmt(&self, formatter: &mut ::std::fmt::Formatter) -> Result<(), ::std::fmt::Error> { write!(formatter, "{:x}-{:x}", self.0, self.1)
Code change:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!

Related discussion:
text: let ast::Path { ref segments, span } = *path; let path: Vec<_> = segments.iter().map(|seg| respan(seg.span, seg.identifier)).collect(); let invocation = self.invocations[&scope]; <del> self.current_module = invocation.module.get(); </del> <ins> let module = invocation.module.get(); self.current_module = if module.is_trait() { module.parent.unwrap() } else { module }; </ins> if path.len() > 1 { if !self.use_extern_macros && self.gated_errors.insert(span) {
Code change:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!

Related discussion:
text: <ins> // Copyright 2017 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. // aux-build:attr-on-trait.rs #![feature(proc_macro)] extern crate attr_on_trait; trait Foo { #[attr_on_trait::foo] fn foo() {} } impl Foo for i32 { fn foo(&self) {} } fn main() { 3i32.foo(); } </ins>
Code change:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!

Related discussion:
text: <ins> // Copyright 2017 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 #![feature(proc_macro)] #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn foo(attr: TokenStream, item: TokenStream) -> TokenStream { drop(attr); assert_eq!(item.to_string(), "fn foo() { }"); "fn foo(&self);".parse().unwrap() } </ins>
Code change:
Tracking issue for the lib feature for the column info API in the panic location hook mechanism, in PR .

Related discussion:
text: /// /// panic!("Normal panic"); /// ``` <del> #[unstable(feature = "panic_col", reason = "recently added", issue = "42939")] </del> <ins> #[stable(feature = "panic_col", since = "1.25")] </ins> pub fn column(&self) -> u32 { self.col }
Code change:
Test case: With rustc 1.20.0-nightly ( 2017-07-06), output when compiling with : correctly stops the dead code / unused type alias warning from being shown, but the trait bounds not enforced warning is shown anyway. Per and , this might be on purpose. I think this is the wrong decision. The point of is to allow Cargo to inhibit warnings in external dependencies. When building Servo it is not useful to spam the console with many warnings, future-proofing or not, about code that Servo has not direct control over. CC
Nominating for discussion. Not sure if compiler team or lang team is best, though, so tagging both...
From the lang team's point of view: definitely a bug.
Couple of bugs here: First off, we should not be ignoring the bounds in types. And sometimes they are needed. I'd like to fix this by not ignoring them, but I worry about the backcompat issues. Unknown risk there. Second, if we must warn, we should be emitting a regular lint that can be silenced. Plausibly, we should just remove the warning (eliminating the immediate problem), and prioritize trying to do a proper fix here.
Somewhat related to not ignoring bounds (but in the other direction): .
After some discussion in compiler team, decided to move this to a "future compatibility" lint, one that we will hopefully make more precise over time. Right now the check is not very good. At least this means you won't have to see it. We need some mentoring instructions though!
Some tips here:
triage: P-medium
I've hit this recently. It seems like it is possible to write code that requires exactly this bound. So it is quite bad that we cannot suppress this warning. Example code:
Agreed, this is poor. There just hasn't been a lot of energy to try and improve the situation.
Fixed in , probably by We should add a regression test for this particular case before we close this issue however, since I don't think the test in the PR detects a regression for the problem described in this issue. The problem in this issue is output on stderr, not that compilation fails ( exit code is 0 both with and without the fix in the PR). label E-needs-test

Related discussion:
text: <ins> // Regression test for https://github.com/rust-lang/rust/issues/43134 // check-pass // compile-flags: --cap-lints allow type Foo<T: Clone> = Option<T>; fn main() {} </ins>
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <ins> // Copyright 2018 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. // only-x86_64 #![allow(dead_code, non_upper_case_globals)] #![feature(asm)] #[repr(C)] pub struct D32x4(f32,f32,f32,f32); impl D32x4 { fn add(&self, vec: Self) -> Self { unsafe { let ret: Self; asm!(" movaps $1, %xmm1 movaps $2, %xmm2 addps %xmm1, %xmm2 movaps $xmm1, $0 " : "=r"(ret) : "1"(self), "2"(vec) : "xmm1", "xmm2" ); ret } } } fn main() { } </ins>
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <ins> // Copyright 2018 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. const C: *const u8 = &0; fn foo(x: *const u8) { match x { C => {} _ => {} } } const D: *const [u8; 4] = b"abcd"; fn main() { match D { D => {} _ => {} } } </ins>
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <ins> // Copyright 2018 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<'a> { type Bar; fn foo(&'a self) -> Self::Bar; } impl<'a, 'b, T: 'a> Foo<'a> for &'b T { type Bar = &'a T; fn foo(&'a self) -> &'a T { self } } pub fn uncallable<T, F>(x: T, f: F) where T: for<'a> Foo<'a>, F: for<'a> Fn(<T as Foo<'a>>::Bar) { f(x.foo()); } pub fn catalyst(x: &i32) { broken(x, |_| {}) } pub fn broken<F: Fn(&i32)>(x: &i32, f: F) { uncallable(x, |y| f(y)); } fn main() { } </ins>