jiebi/CodeConvo huggingface dataset:
Code change:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to

Related discussion:
text: debug!("late_bound_in_ty = {:?}", late_bound_in_ty); for br in late_bound_in_ty.difference(&late_bound_in_trait_ref) { let br_name = match *br { <del> ty::BrNamed(_, name) => name, _ => { span_bug!( binding.span, "anonymous bound region {:?} in binding but not trait ref", br ); } </del> <ins> ty::BrNamed(_, name) => format!("lifetime `{}`", name), _ => "an anonymous lifetime".to_string(), </ins> }; // FIXME: point at the type params that don't have appropriate lifetimes: // struct S1<F: for<'a> Fn(&i32, &i32) -> &'a i32>(F); //                         ----  ----     ^^^^^^^ <del> struct_span_err!( </del> <ins> let mut err = struct_span_err!( </ins> tcx.sess, binding.span, E0582, <del> "binding for associated type `{}` references lifetime `{}`,  </del> <ins> "binding for associated type `{}` references {},  </ins> which does not appear in the trait input types", binding.item_name, br_name <del> ) .emit(); </del> <ins> ); if let ty::BrAnon(_) = *br { // The only way for an anonymous lifetime to wind up // in the return type but **also** be unconstrained is // if it only appears in "associated types" in the // input. See #62200 for an example. In this case, // though we can easily give a hint that ought to be // relevant. err.note("lifetimes appearing in an associated type are not considered constrained"); } err.emit(); </ins> } } }
Code change:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to

Related discussion:
text: <ins> struct S {} trait T<'a> { type A; } impl T<'_> for S { type A = u32; } fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} //~^ ERROR binding for associated type `Output` references an anonymous lifetime //~^^ NOTE lifetimes appearing in an associated type are not considered constrained fn main() {} </ins>
Code change:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to

Related discussion:
text: <ins> error[E0582]: binding for associated type `Output` references an anonymous lifetime, which does not appear in the trait input types --> $DIR/issue-62200.rs:11:39 | LL | fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} |                                       ^^^^^^^^^^^^^^^ | = note: lifetimes appearing in an associated type are not considered constrained error: aborting due to previous error For more information about this error, try `rustc --explain E0582`. </ins>
Code change:
I have the following code: Attempting to use this function, such as in the following manner: causes the compiler to crash with the following backtrace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this was fixed at some point. The following minimal example ICEs on nightly-2019-06-26, but doesn't on nightly-2020-03-11!
I'll look into adding a test for this tomorrow! :)
assign

Related discussion:
text: <ins> // build-pass #![allow(incomplete_features)] #![feature(const_generics)] pub struct Vector<T, const N: usize>([T; N]); pub type TruncatedVector<T, const N: usize> = Vector<T, { N - 1 }>; impl<T, const N: usize> Vector<T, { N }> { /// Drop the last component and return the vector with one fewer dimension. pub fn trunc(self) -> (TruncatedVector<T, { N }>, T) { unimplemented!() } } fn vec4<T>(a: T, b: T, c: T, d: T) -> Vector<T, 4> { Vector([a, b, c, d]) } fn main() { let (_xyz, _w): (TruncatedVector<u32, 4>, u32) = vec4(0u32, 1, 2, 3).trunc(); } </ins>
Code change:
Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.

Related discussion:
text: <ins> enum A { Value(()) } fn main() { let a = A::Value(()); a == A::Value; //~^ ERROR binary operation `==` cannot be applied to type `A` } </ins>
Code change:
Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.

Related discussion:
text: <ins> error[E0369]: binary operation `==` cannot be applied to type `A` --> $DIR/issue-62375.rs:7:7 | LL |     a == A::Value; |     - ^^ -------- fn(()) -> A {A::Value} |     | |     A | = note: an implementation of `std::cmp::PartialEq` might be missing for `A` error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. </ins>
Code change:
(and by extension ) have as the mask type, but the lists as the mask type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hey I (I think we all) very much appreciate the work you are doing by looking at the docs and finding unsound things. What about opening a PR and fixing them immediatly (some of them could be done by using the github editor)? It's a very great opportunity to make Rust a better programming langauge. If you feel like it, please open a PR and reference this issue with one of the github provides.
I am well aware of how GitHub works :D unfortunately for us all, I only have so much programming time. I've been busy at work safe wrapping all these intrinsics for my own lib, which is why I'm filing bugs on them as they come up. However, in my experience, filing even a single PR to this repo is rather involved and so I've mostly given up on doing it. As to this particular issue, it's a change to a stable API, so at minimum a full crater run would have to be performed of course. The input mask value has to be a const, so you get a lot of literals of course and those can usually infer to the new type fine, but you also get a lot of const declarations too, which would break. I suspect that at least some people will get their code broken. Given that the intrinsic only uses the 8 lowest bits, it would be entirely reasonable for T-libs to say they don't care about the i32/u32 difference compared to code breaks and just document the (very minor) difference. or they could go for absolute exactness and declare the breaks to be the fair product of a bug fix. up to them
I believe this was changed recently because Intel's definition is wrong/inconsistent. See
ah lovely. of course the guide is wrong :P well, then consider this a minor documentation issue. the function should simply explain that it doesn't match the spec and why and such.
I could take this! claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
claim
I have submitted in order to fix this. I believe we could resolve this issue once that PR is merged by updating the submodule.

Related discussion:
text: <del> Subproject commit 311d56cd91609c1c1c0370cbd2ece8e3048653a5 </del> <ins> Subproject commit d6822f9c433bd70f786b157f17beaf64ee28d83a </ins>
Code change:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

Related discussion:
text: let mut align = if pack.is_some() { dl.i8_align } else { dl.aggregate_align }; <del> let mut sized = true; let mut offsets = vec![Size::ZERO; fields.len()]; </del> let mut inverse_memory_index: Vec<u32> = (0..fields.len() as u32).collect(); let mut optimize = !repr.inhibit_struct_field_reordering_opt();
Code change:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

Related discussion:
text: // At the bottom of this function, we invert `inverse_memory_index` to // produce `memory_index` (see `invert_mapping`). <ins> let mut sized = true; let mut offsets = vec![Size::ZERO; fields.len()]; </ins> let mut offset = Size::ZERO; let mut largest_niche = None; let mut largest_niche_available = 0;
Code change:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

Related discussion:
text: let count = (niche_variants.end().as_u32() - niche_variants.start().as_u32() + 1) as u128; <del> // FIXME(#62691) use the largest niche across all fields, // not just the first one. for (field_index, &field) in variants[i].iter().enumerate() { let niche = match &field.largest_niche { Some(niche) => niche, _ => continue, }; let (niche_start, niche_scalar) = match niche.reserve(self, count) { Some(pair) => pair, None => continue, }; </del> <ins> // Find the field with the largest niche let niche_candidate = variants[i] .iter() .enumerate() .filter_map(|(j, &field)| Some((j, field.largest_niche.as_ref()?))) .max_by_key(|(_, niche)| niche.available(dl)); if let Some((field_index, niche, (niche_start, niche_scalar))) = niche_candidate.and_then(|(field_index, niche)| { Some((field_index, niche, niche.reserve(self, count)?)) }) { </ins> let mut align = dl.aggregate_align; let st = variants .iter_enumerated()
Code change:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

Related discussion:
text: C, } <ins> enum Option2<A, B> { Some(A, B), None } </ins> pub fn main() { assert_eq!(size_of::<u8>(), 1 as usize); assert_eq!(size_of::<u32>(), 4 as usize);
Code change:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(

Related discussion:
text: assert_eq!(size_of::<Option<Option<(bool, &())>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option<(&(), bool)>>>(), size_of::<(bool, &())>()); <ins> assert_eq!(size_of::<Option<Option2<bool, &()>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option2<&(), bool>>>(), size_of::<(bool, &())>()); </ins> }
Code change:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

Related discussion:
text: linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+strict-align,+v6,+vfp2".to_string(), </del> <ins> features: "+strict-align,+v6,+vfp2,-d32".to_string(), </ins> abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "u{1}__gnu_mcount_nc".to_string(), .. base
Code change:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

Related discussion:
text: // Most of these settings are copied from the arm_unknown_linux_gnueabihf // target. <del> base.features = "+strict-align,+v6,+vfp2".to_string(); </del> <ins> base.features = "+strict-align,+v6,+vfp2,-d32".to_string(); </ins> base.max_atomic_width = Some(64); Ok(Target { // It's important we use "gnueabihf" and not "musleabihf" here. LLVM