jiebi/CodeConvo huggingface dataset:
Code change:
As of rustc 1.33.0-nightly ( 2018-12-22) the following macro invocation fails with an ICE. Mentioning and because this may have to do with slicing introduced in . Same repro in script form:
is working on a solution in

Related discussion:
text: <ins> macro_rules! import { ( $($name:ident),* ) => { $( mod $name; pub use self::$name; //~^ ERROR the name `issue_56411_aux` is defined multiple times //~| ERROR `issue_56411_aux` is private, and cannot be re-exported )* } } import!(issue_56411_aux); fn main() { println!("Hello, world!"); } </ins>
Code change:
As of rustc 1.33.0-nightly ( 2018-12-22) the following macro invocation fails with an ICE. Mentioning and because this may have to do with slicing introduced in . Same repro in script form:
is working on a solution in

Related discussion:
text: <ins> error[E0255]: the name `issue_56411_aux` is defined multiple times --> $DIR/issue-56411.rs:5:21 | LL |             mod $name; |             ---------- previous definition of the module `issue_56411_aux` here LL |             pub use self::$name; |                     ^^^^^^^^^^^ |                     | |                     `issue_56411_aux` reimported here |                     you can use `as` to change the binding name of the import ... LL | import!(issue_56411_aux); | ------------------------- in this macro invocation | = note: `issue_56411_aux` must be defined only once in the type namespace of this module error[E0365]: `issue_56411_aux` is private, and cannot be re-exported --> $DIR/issue-56411.rs:5:21 | LL |             pub use self::$name; |                     ^^^^^^^^^^^ re-export of private `issue_56411_aux` ... LL | import!(issue_56411_aux); | ------------------------- in this macro invocation | = note: consider declaring type or module `issue_56411_aux` with `pub` error: aborting due to 2 previous errors Some errors occurred: E0255, E0365. For more information about an error, try `rustc --explain E0255`. </ins>
Code change:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed

Related discussion:
text: /// /// The following return false: /// <del> /// - private address (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) /// - the loopback address (127.0.0.0/8) /// - the link-local address (169.254.0.0/16) /// - the broadcast address (255.255.255.255/32) /// - test addresses used for documentation (192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24) /// - the unspecified address (0.0.0.0) </del> <ins> /// - private addresses (see [`is_private()`](#method.is_private)) /// - the loopback address (see [`is_loopback()`](#method.is_loopback)) /// - the link-local address (see [`is_link_local()`](#method.is_link_local)) /// - the broadcast address (see [`is_broadcast()`](#method.is_broadcast)) /// - addresses used for documentation (see [`is_documentation()`](#method.is_documentation)) /// - the unspecified address (see [`is_unspecified()`](#method.is_unspecified)), and the whole ///   0.0.0.0/8 block /// - addresses reserved for future protocols (see /// [`is_ietf_protocol_assignment()`](#method.is_ietf_protocol_assignment), except /// `192.0.0.9/32` and `192.0.0.10/32` which are globally routable /// - addresses reserved for future use (see [`is_reserved()`](#method.is_reserved) /// - addresses reserved for networking devices benchmarking (see /// [`is_benchmarking`](#method.is_benchmarking)) </ins> /// /// [ipv4-sr]: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml /// [`true`]: ../../std/primitive.bool.html
Code change:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed

Related discussion:
text: } } <del> /// Returns [`true`] if this is a unique local address (fc00::/7). </del> <ins> /// Returns [`true`] if this is a unique local address (`fc00::/7`). </ins> /// /// This property is defined in [IETF RFC 4193]. ///
Code change:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed

Related discussion:
text: /// use std::net::Ipv6Addr; /// /// fn main() { <del> ///     assert_eq!(Ipv6Addr::new(0, 0, 0, 0, 0, 0xffff, 0xc00a, 0x2ff).is_unicast_link_local(), ///                false); ///     assert_eq!(Ipv6Addr::new(0xfe8a, 0, 0, 0, 0, 0, 0, 0).is_unicast_link_local(), true); </del> <ins> ///     let ip = Ipv6Addr::new(0xfe80, 0, 0, 0, 0, 0, 0, 0); ///     assert!(ip.is_unicast_link_local()); /// ///     let ip = Ipv6Addr::new(0xfe80, 0, 0, 0, 0xffff, 0xffff, 0xffff, 0xffff); ///     assert!(ip.is_unicast_link_local()); /// ///     let ip = Ipv6Addr::new(0xfe80, 0, 0, 1, 0, 0, 0, 0); ///     assert!(ip.is_unicast_link_local()); ///     assert!(!ip.is_unicast_link_local_strict()); /// ///     let ip = Ipv6Addr::new(0xfe81, 0, 0, 0, 0, 0, 0, 0); ///     assert!(ip.is_unicast_link_local()); ///     assert!(!ip.is_unicast_link_local_strict()); </ins> /// } /// ``` <ins> /// /// # See also /// /// - [IETF RFC 4291 section 2.4] /// - [RFC 4291 errata 4406] /// /// [IETF RFC 4291 section 2.4]: https://tools.ietf.org/html/rfc4291#section-2.4 /// [`true`]: ../../std/primitive.bool.html /// [RFC 4291 errata 4406]: https://www.rfc-editor.org/errata/eid4406 /// [`is_unicast_link_local_strict()`]: ../../std/net/struct.Ipv6Addr.html#method.is_unicast_link_local_strict /// </ins> pub fn is_unicast_link_local(&self) -> bool { (self.segments()[0] & 0xffc0) == 0xfe80 } <del> /// Returns [`true`] if this is a deprecated unicast site-local address /// (fec0::/10). </del> <ins> /// Returns [`true`] if this is a deprecated unicast site-local address (fec0::/10). The /// unicast site-local address format is defined in [RFC 4291 section 2.5.7] as: /// /// ```no_rust /// |   10     | /// |  bits    |         54 bits         |         64 bits            | /// +----------+-------------------------+----------------------------+ /// |1111111011|        subnet ID        |       interface ID         | /// +----------+-------------------------+----------------------------+ /// ``` </ins> /// /// [`true`]: ../../std/primitive.bool.html <ins> /// [RFC 4291 section 2.5.7]: https://tools.ietf.org/html/rfc4291#section-2.5.7 </ins> /// /// # Examples ///
Code change:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed

Related discussion:
text: /// /// - the loopback address /// - the link-local addresses <del> /// - the (deprecated) site-local addresses </del> /// - unique local addresses /// - the unspecified address /// - the address range reserved for documentation /// <ins> /// This method returns [`true`] for site-local addresses as per [RFC 4291 section 2.5.7] /// /// ```no_rust /// The special behavior of [the site-local unicast] prefix defined in [RFC3513] must no longer /// be supported in new implementations (i.e., new implementations must treat this prefix as /// Global Unicast). /// ``` /// </ins> /// [`true`]: ../../std/primitive.bool.html <ins> /// [RFC 4291 section 2.5.7]: https://tools.ietf.org/html/rfc4291#section-2.5.7 </ins> /// /// # Examples ///
Code change:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed

Related discussion:
text: /// ``` pub fn is_unicast_global(&self) -> bool { !self.is_multicast() <del> && !self.is_loopback() && !self.is_unicast_link_local() && !self.is_unicast_site_local() && !self.is_unique_local() && !self.is_unspecified() && !self.is_documentation() </del> <ins> && !self.is_loopback() && !self.is_unicast_link_local() && !self.is_unique_local() && !self.is_unspecified() && !self.is_documentation() </ins> } /// Returns the address's multicast scope if the address is multicast.
Code change:
Minimised, reproducible example: See Backtrace
Hello I'm getting the same ICE, but without any unstable features. I don't have a minimized example, though, but it may be another data point when searching for the problem. It's this commit: The commit happens with The code is not correct, it wouldn't compile even if the compiler didn't panic. It doesn't happen on stable, but I guess it's because it bails out sooner on closures taking references:
This still produces an error on the latest nightly (not sure if it's supposed to compile or not), but no longer ICEs.

Related discussion:
text: <ins> // Regression test for issue #57611 // Ensures that we don't ICE // FIXME: This should compile, but it currently doesn't #![feature(trait_alias)] #![feature(type_alias_impl_trait)] trait Foo { type Bar: Baz<Self, Self>; fn bar(&self) -> Self::Bar; } struct X; impl Foo for X { type Bar = impl Baz<Self, Self>; //~ ERROR type mismatch in closure arguments //~^ ERROR type mismatch resolving fn bar(&self) -> Self::Bar { |x| x } } trait Baz<A, B> = Fn(&A) -> &B; fn main() {} </ins>
Code change:
Minimised, reproducible example: See Backtrace
Hello I'm getting the same ICE, but without any unstable features. I don't have a minimized example, though, but it may be another data point when searching for the problem. It's this commit: The commit happens with The code is not correct, it wouldn't compile even if the compiler didn't panic. It doesn't happen on stable, but I guess it's because it bails out sooner on closures taking references:
This still produces an error on the latest nightly (not sure if it's supposed to compile or not), but no longer ICEs.

Related discussion:
text: <ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-57611-trait-alias.rs:17:5 | LL |     type Bar = impl Baz<Self, Self>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `for<'r> fn(&'r X) -> _` ... LL |         |x| x |         ----- found signature of `fn(_) -> _` | = note: the return type of a function must have a statically known size error[E0271]: type mismatch resolving `for<'r> <[closure@$DIR/issue-57611-trait-alias.rs:21:9: 21:14] as std::ops::FnOnce<(&'r X,)>>::Output == &'r X` --> $DIR/issue-57611-trait-alias.rs:17:5 | LL |     type Bar = impl Baz<Self, Self>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter, found concrete lifetime | = note: the return type of a function must have a statically known size error: aborting due to 2 previous errors Some errors have detailed explanations: E0271, E0631. For more information about an error, try `rustc --explain E0271`. </ins>
Code change:
Minimised, reproducible example: See Backtrace
Hello I'm getting the same ICE, but without any unstable features. I don't have a minimized example, though, but it may be another data point when searching for the problem. It's this commit: The commit happens with The code is not correct, it wouldn't compile even if the compiler didn't panic. It doesn't happen on stable, but I guess it's because it bails out sooner on closures taking references:
This still produces an error on the latest nightly (not sure if it's supposed to compile or not), but no longer ICEs.

Related discussion:
text: <ins> // Regression test for issue #57807 - ensure // that we properly unify associated types within // a type alias impl trait // check-pass #![feature(type_alias_impl_trait)] trait Bar { type A; } impl Bar for () { type A = (); } trait Foo { type A; type B: Bar<A = Self::A>; fn foo() -> Self::B; } impl Foo for () { type A = (); type B = impl Bar<A = Self::A>; fn foo() -> Self::B { () } } fn main() {} </ins>
Code change:
When building a statically-linked Rust binary crate for the target, linking a crate fails with the following error: Expected result: the crate successfully compiles. Actual result: the crate fails to compile, with an error during the linking stage. Platform: Ubuntu 18.04, x8664. Output of : MUSL standard C library version: 1.1.20. C compiler: MIPS GCC version 7.3, provided by Ubuntu 18.04 (). I tried searching the open and closed issues for this project, and couldn't find any others exhibiting this same error. Forgive me if this is the wrong place to file this bug, but I'm not entirely sure how to debug this problem, so I'm starting here with Rust. The file in makes a call to on big-endian hosts (). This function gets translated into the symbol for the MIPS target, and should be present in the compiler's built-in library, but it appears it's absent here. Now, I can see that uses GCC 5.3 from the OpenWRT toolchain. I'm not entirely sure why this should give any different results from using the GCC 7.3 package provided by Ubuntu 18.04 (, which provides GCC 5.5, and the results are the same (fails to link due to undefined reference to ). Here is the full error message from trying to build the crate: An easy way to reproduce this is to create a with the following contents, and then build it with :
The necessary functions should be to the .
This does look like an interesting idea, but when trying to compile with that crate, I get lots of errors of this sort: You should be able to recreate this by adding the following line to the I mentioned in the original issue, just before the line at the end: I'm currently working on a project that I'd like to keep on the stable channel. Will this crate not work at all on the stable channel?
modify labels: +O-musl
possibly related to
Any updates with this issue? Have the same problem
Adding "-C", "link-args=-lgcc" to re-add libgcc removed by -nostdlib to rustargs fixes the problem, at least for the simple hello world. Or you could implement __bswapsi2 yourself. I'm guessing that openwrt toolchain targets mips32 as opposed of mips32r2, so it requires "libcall" for bswap. Hope it helps.
It works, thanks!

Related discussion:
text: [[package]] name = "compiler_builtins" <del> version = "0.1.32" </del> <ins> version = "0.1.35" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "7bc4ac2c824d2bfc612cba57708198547e9a26943af0632aff033e0693074d5c" </del> <ins> checksum = "e3fcd8aba10d17504c87ef12d4f62ef404c6a4703d16682a9eb5543e6cf24455" </ins> dependencies = [ "cc", "rustc-std-workspace-core",
Code change:
When building a statically-linked Rust binary crate for the target, linking a crate fails with the following error: Expected result: the crate successfully compiles. Actual result: the crate fails to compile, with an error during the linking stage. Platform: Ubuntu 18.04, x8664. Output of : MUSL standard C library version: 1.1.20. C compiler: MIPS GCC version 7.3, provided by Ubuntu 18.04 (). I tried searching the open and closed issues for this project, and couldn't find any others exhibiting this same error. Forgive me if this is the wrong place to file this bug, but I'm not entirely sure how to debug this problem, so I'm starting here with Rust. The file in makes a call to on big-endian hosts (). This function gets translated into the symbol for the MIPS target, and should be present in the compiler's built-in library, but it appears it's absent here. Now, I can see that uses GCC 5.3 from the OpenWRT toolchain. I'm not entirely sure why this should give any different results from using the GCC 7.3 package provided by Ubuntu 18.04 (, which provides GCC 5.5, and the results are the same (fails to link due to undefined reference to ). Here is the full error message from trying to build the crate: An easy way to reproduce this is to create a with the following contents, and then build it with :
The necessary functions should be to the .
This does look like an interesting idea, but when trying to compile with that crate, I get lots of errors of this sort: You should be able to recreate this by adding the following line to the I mentioned in the original issue, just before the line at the end: I'm currently working on a project that I'd like to keep on the stable channel. Will this crate not work at all on the stable channel?
modify labels: +O-musl
possibly related to
Any updates with this issue? Have the same problem
Adding "-C", "link-args=-lgcc" to re-add libgcc removed by -nostdlib to rustargs fixes the problem, at least for the simple hello world. Or you could implement __bswapsi2 yourself. I'm guessing that openwrt toolchain targets mips32 as opposed of mips32r2, so it requires "libcall" for bswap. Hope it helps.
It works, thanks!

Related discussion:
text: panic_abort = { path = "../panic_abort" } core = { path = "../core" } libc = { version = "0.2.74", default-features = false, features = ['rustc-dep-of-std'] } <del> compiler_builtins = { version = "0.1.32" } </del> <ins> compiler_builtins = { version = "0.1.35" } </ins> profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" } hashbrown = { version = "0.8.1", default-features = false, features = ['rustc-dep-of-std'] }
Code change:
Encountered this when working on test cases for an RFC: cc This seems related to other issues.
I'm confused. Either this was fixed since yesterday's nightly (it still ICEs on nightly but works locally on master), or something really odd is going on
Is that the upstream master? Otherwise maybe someone merged a PR or something..
This still ICEs on nightly.
This now compiles successfully on the latest nightly.

Related discussion:
text: <ins> // check-pass #![feature(existential_type)] existential type A: Iterator; fn def_a() -> A { 0..1 } pub fn use_a() { def_a().map(|x| x); } fn main() {} </ins>
Code change:
When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?
I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well

Related discussion:
text: } // walk type and init value <del> self.visit_ty(typ); if let Some(expr) = expr { self.visit_expr(expr); } </del> <ins> self.nest_tables(id, |v| { v.visit_ty(typ); if let Some(expr) = expr { v.visit_expr(expr); } }); </ins> } // FIXME tuple structs should generate tuple-specific data.
Code change:
When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?
I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well

Related discussion:
text: <ins> // compile-flags: -Zsave-analysis // Check that this doesn't ICE when processing associated const (field expr). pub fn f() { trait Trait {} impl Trait { const FLAG: u32 = bogus.field; //~ ERROR cannot find value `bogus` } } fn main() {} </ins>