jiebi/CodeConvo huggingface dataset:
Code change:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: LL |     let _: S::C; |            ^^^^ help: use fully-qualified syntax: `<S as Trait>::C` <del> error: associated type `A` is private </del> <ins> error[E0624]: associated type `A` is private </ins> --> $DIR/item-privacy.rs:119:12 | <ins> LL |         type A = u8; |         ------ associated type defined here ... </ins> LL |     let _: T::A; |            ^^^^ private associated type
Code change:
I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: /// /// assert_eq!(n.leading_zeros(), 0); /// ``` <ins> #[doc = concat!("[`ilog2`]: ", stringify!($SelfT), "::ilog2")] </ins> #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_stable(feature = "const_int_methods", since = "1.32.0")] #[must_use = "this returns the result of the operation,
Code change:
I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: /// Returns the number of leading zeros in the binary representation of `self`. /// <ins> /// Depending on what you're doing with the value, you might also be interested in the /// [`ilog2`] function which returns a consistent number, even if the type widens. /// </ins> /// # Examples /// /// Basic usage:
Code change:
I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: /// /// assert_eq!(n.leading_zeros(), 2); /// ``` <ins> #[doc = concat!("[`ilog2`]: ", stringify!($SelfT), "::ilog2")] </ins> #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_stable(feature = "const_math", since = "1.32.0")] #[must_use = "this returns the result of the operation,
Code change:
I tried this code: I expected to see this happen: Successful compilation (because this would succeed for the target ) Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is It should probably be applied to riscv32 too
Doesn't seem like anyone else has picked this up yet, if it's as simple a fix as it seems I would be happy to make the PR.
claim
The mismatch still occurs if extra features are specified by (e.g., ).
Sorry about the delayed response. I just tested it, but I'm not seeing the error. Could you test again as well? I was running the following command: Here is the version I'm on:
Hm, I actually encountered the issue in a more complicated setup () with bare-metal targets and assumed from the symptom that it was caused by a similar underlying problem. I'll look into it again and open a separate issue after getting a better idea.

Related discussion:
text: }; e_flags } <del> Architecture::Riscv64 if sess.target.options.features.contains("+d") => { // copied from `riscv64-linux-gnu-gcc foo.c -c`, note though // that the `+d` target feature represents whether the double // float abi is enabled. let e_flags = elf::EF_RISCV_RVC | elf::EF_RISCV_FLOAT_ABI_DOUBLE; </del> <ins> Architecture::Riscv32 | Architecture::Riscv64 => { // Source: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/079772828bd10933d34121117a222b4cc0ee2200/riscv-elf.adoc let mut e_flags: u32 = 0x0; let features = &sess.target.options.features; // Check if compressed is enabled if features.contains("+c") { e_flags |= elf::EF_RISCV_RVC; } // Select the appropriate floating-point ABI if features.contains("+d") { e_flags |= elf::EF_RISCV_FLOAT_ABI_DOUBLE; } else if features.contains("+f") { e_flags |= elf::EF_RISCV_FLOAT_ABI_SINGLE; } else { e_flags |= elf::EF_RISCV_FLOAT_ABI_SOFT; } </ins> e_flags } _ => 0,
Code change:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

Related discussion:
text: // In the algorithm above, we can change // cast(relative_tag) + niche_variants.start() // into <del> // cast(tag) + (niche_variants.start() - niche_start) </del> <ins> // cast(tag + (niche_variants.start() - niche_start)) </ins> // if either the casted type is no larger than the original // type, or if the niche values are contiguous (in either the // signed or unsigned sense). <del> let can_incr_after_cast = cast_smaller || niches_ule || niches_sle; </del> <ins> let can_incr = cast_smaller || niches_ule || niches_sle; </ins> let data_for_boundary_niche = || -> Option<(IntPredicate, u128)> { <del> if !can_incr_after_cast { </del> <ins> if !can_incr { </ins> None } else if niche_start == low_unsigned { Some((IntPredicate::IntULE, niche_end))
Code change:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

Related discussion:
text: // The algorithm is now this: // is_niche = tag <= niche_end // discr = if is_niche { <del> //     cast(tag) + (niche_variants.start() - niche_start) </del> <ins> //     cast(tag + (niche_variants.start() - niche_start)) </ins> // } else { //     untagged_variant // } // (the first line may instead be tag >= niche_start, // and may be a signed or unsigned comparison) <ins> // The arithmetic must be done before the cast, so we can // have the correct wrapping behavior. See issue #104519 for // the consequences of getting this wrong. </ins> let is_niche = bx.icmp(predicate, tag, bx.cx().const_uint_big(tag_llty, constant)); <ins> let delta = (niche_variants.start().as_u32() as u128).wrapping_sub(niche_start); let incr_tag = if delta == 0 { tag } else { bx.add(tag, bx.cx().const_uint_big(tag_llty, delta)) }; </ins> let cast_tag = if cast_smaller { <del> bx.intcast(tag, cast_to, false) </del> <ins> bx.intcast(incr_tag, cast_to, false) </ins> } else if niches_ule { <del> bx.zext(tag, cast_to) </del> <ins> bx.zext(incr_tag, cast_to) </ins> } else { <del> bx.sext(tag, cast_to) </del> <ins> bx.sext(incr_tag, cast_to) </ins> }; <del> let delta = (niche_variants.start().as_u32() as u128).wrapping_sub(niche_start); (is_niche, cast_tag, delta) </del> <ins> (is_niche, cast_tag, 0) </ins> } else { // The special cases don't apply, so we'll have to go with // the general algorithm.
Code change:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

Related discussion:
text: // CHECK: define i8 @match1{{.*}} // CHECK-NEXT: start: <del> // CHECK-NEXT: %1 = icmp ugt i8 %0, 1 // CHECK-NEXT: %2 = zext i8 %0 to i64 // CHECK-NEXT: %3 = add nsw i64 %2, -1 // CHECK-NEXT: %_2 = select i1 %1, i64 %3, i64 0 // CHECK-NEXT: switch i64 %_2, label {{.*}} [ </del> <ins> // CHECK-NEXT: %1 = {{.*}}call i8 @llvm.usub.sat.i8(i8 %0, i8 1) // CHECK-NEXT: switch i8 %1, label {{.*}} [ </ins> #[no_mangle] pub fn match1(e: Enum1) -> u8 { use Enum1::*;
Code change:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

Related discussion:
text: <ins> // run-pass #![allow(dead_code)] enum OpenResult { Ok(()), Err(()), TransportErr(TransportErr), } #[repr(i32)] enum TransportErr { UnknownMethod = -2, } #[inline(never)] fn some_match(result: OpenResult) -> u8 { match result { OpenResult::Ok(()) => 0, _ => 1, } } fn main() { let result = OpenResult::Ok(()); assert_eq!(some_match(result), 0); let result = OpenResult::Ok(()); match result { OpenResult::Ok(()) => (), _ => unreachable!("message a"), } match result { OpenResult::Ok(()) => (), _ => unreachable!("message b"), } } </ins>
Code change:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

Related discussion:
text: /// assert_eq!(vec![1, 2, 3], *shared); /// ``` #[inline] <del> fn from(v: Vec<T>) -> Rc<[T]> { match Rc::try_from_vec_in_place(v) { Ok(rc) => rc, Err(mut v) => { unsafe { let rc = Rc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc } } </del> <ins> fn from(mut v: Vec<T>) -> Rc<[T]> { unsafe { let rc = Rc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc </ins> } } }
Code change:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

Related discussion:
text: /// assert_eq!(&[1, 2, 3], &shared[..]); /// ``` #[inline] <del> fn from(v: Vec<T>) -> Arc<[T]> { match Arc::try_from_vec_in_place(v) { Ok(rc) => rc, Err(mut v) => { unsafe { let rc = Arc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc } } </del> <ins> fn from(mut v: Vec<T>) -> Arc<[T]> { unsafe { let rc = Arc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc </ins> } } }
Code change:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

Related discussion:
text: // `val` dropped here while still borrowed // borrow might be used here, when `val` is dropped and runs the `Drop` code for type `std::sync::Weak` } <del> #[test] fn arc_from_vec_opt() { let mut v = Vec::with_capacity(64); v.push(0usize); let addr = v.as_ptr().cast::<u8>(); let arc: Arc<[_]> = v.into(); unsafe { assert_eq!( arc.as_ptr().cast::<u8>().offset_from(addr), (std::mem::size_of::<usize>() * 2) as isize, "Vector allocation not reused" ); } } </del>
Code change:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

Related discussion:
text: // `val` dropped here while still borrowed // borrow might be used here, when `val` is dropped and runs the `Drop` code for type `std::rc::Weak` } <del> #[test] fn rc_from_vec_opt() { let mut v = Vec::with_capacity(64); v.push(0usize); let addr = v.as_ptr().cast::<u8>(); let rc: Rc<[_]> = v.into(); unsafe { assert_eq!( rc.as_ptr().cast::<u8>().offset_from(addr), (std::mem::size_of::<usize>() * 2) as isize, "Vector allocation not reused" ); } } </del>
Code change:
Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

Related discussion:
text: } ty::FnPtr(sig) => (sig, None), _ => { <ins> for arg in arg_exprs { self.check_expr(arg); } </ins> if let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) = &callee_expr.kind && let [segment] = path.segments && let Some(mut diag) = self