jiebi/CodeConvo huggingface dataset:
Code change:
For example, from (And many more.) I think this is due to Should we just drop these from ?
cc

Related discussion:
text: ("avx512bw", Unstable(sym::avx512_target_feature)), ("avx512cd", Unstable(sym::avx512_target_feature)), ("avx512dq", Unstable(sym::avx512_target_feature)), <del> ("avx512er", Unstable(sym::avx512_target_feature)), </del> ("avx512f", Unstable(sym::avx512_target_feature)), ("avx512fp16", Unstable(sym::avx512_target_feature)), ("avx512ifma", Unstable(sym::avx512_target_feature)), <del> ("avx512pf", Unstable(sym::avx512_target_feature)), </del> ("avx512vbmi", Unstable(sym::avx512_target_feature)), ("avx512vbmi2", Unstable(sym::avx512_target_feature)), ("avx512vl", Unstable(sym::avx512_target_feature)),
Code change:
For example, from (And many more.) I think this is due to Should we just drop these from ?
cc

Related discussion:
text: println!("avx512bw: {:?}", is_x86_feature_detected!("avx512bw")); println!("avx512cd: {:?}", is_x86_feature_detected!("avx512cd")); println!("avx512dq: {:?}", is_x86_feature_detected!("avx512dq")); <del> println!("avx512er: {:?}", is_x86_feature_detected!("avx512er")); </del> println!("avx512f: {:?}", is_x86_feature_detected!("avx512f")); println!("avx512ifma: {:?}", is_x86_feature_detected!("avx512ifma")); <del> println!("avx512pf: {:?}", is_x86_feature_detected!("avx512pf")); </del> println!("avx512vbmi2: {:?}", is_x86_feature_detected!("avx512vbmi2")); println!("avx512vbmi: {:?}", is_x86_feature_detected!("avx512vbmi")); println!("avx512vl: {:?}", is_x86_feature_detected!("avx512vl"));
Code change:
For example, from (And many more.) I think this is due to Should we just drop these from ?
cc

Related discussion:
text: LL |     cfg!(target_feature = "zebra"); |          ^^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: expected values for `target_feature` are: `10e60`, `2e3`, `3e3r1`, `3e3r2`, `3e3r3`, `3e7`, `7e10`, `a`, `aclass`, `adx`, `aes`, `altivec`, `alu32`, `atomics`, `avx`, `avx2`, `avx512bf16`, `avx512bitalg`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512er`, `avx512f`, `avx512fp16`, `avx512ifma`, `avx512pf`, `avx512vbmi`, `avx512vbmi2`, `avx512vl`, `avx512vnni`, `avx512vp2intersect`, `avx512vpopcntdq`, `bf16`, `bmi1`, and `bmi2` and 188 more </del> <ins> = note: expected values for `target_feature` are: `10e60`, `2e3`, `3e3r1`, `3e3r2`, `3e3r3`, `3e7`, `7e10`, `a`, `aclass`, `adx`, `aes`, `altivec`, `alu32`, `atomics`, `avx`, `avx2`, `avx512bf16`, `avx512bitalg`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512f`, `avx512fp16`, `avx512ifma`, `avx512vbmi`, `avx512vbmi2`, `avx512vl`, `avx512vnni`, `avx512vp2intersect`, `avx512vpopcntdq`, `bf16`, `bmi1`, `bmi2`, `bti`, and `bulk-memory` and 186 more </ins> = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg.html> for more information about checking conditional configuration warning: 27 warnings emitted
Code change:
() Like and the other ABIs, should not trigger and for non-FFI-safe types. Related: , ; tracking issue . No response No response_

Related discussion:
text: } fn is_internal_abi(&self, abi: SpecAbi) -> bool { <del> matches!(abi, SpecAbi::Rust | SpecAbi::RustCall | SpecAbi::RustIntrinsic) </del> <ins> matches!( abi, SpecAbi::Rust | SpecAbi::RustCall | SpecAbi::RustCold | SpecAbi::RustIntrinsic ) </ins> } /// Find any fn-ptr types with external ABIs in `ty`.
Code change:
() Like and the other ABIs, should not trigger and for non-FFI-safe types. Related: , ; tracking issue . No response No response_

Related discussion:
text: <ins> //@ check-pass #![feature(rust_cold_cc)] // extern "rust-cold" is a "Rust" ABI so we accept `repr(Rust)` types as arg/ret without warnings. pub extern "rust-cold" fn f(_: ()) -> Result<(), ()> { Ok(()) } extern "rust-cold" { pub fn g(_: ()) -> Result<(), ()>; } fn main() {} </ins>
Code change:
When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc

Related discussion:
text: AR_loongarch64_unknown_linux_gnu=loongarch64-unknown-linux-gnu-ar  CXX_loongarch64_unknown_linux_gnu=loongarch64-unknown-linux-gnu-g++ <ins> # We re-use the Linux toolchain for bare-metal, because upstream bare-metal # target support for LoongArch is only available from GCC 14+. # # See: https://github.com/gcc-mirror/gcc/commit/976f4f9e4770 ENV CC_loongarch64_unknown_none=loongarch64-unknown-linux-gnu-gcc  AR_loongarch64_unknown_none=loongarch64-unknown-linux-gnu-ar  CXX_loongarch64_unknown_none=loongarch64-unknown-linux-gnu-g++  CFLAGS_loongarch64_unknown_none="-ffreestanding -mabi=lp64d"  CXXFLAGS_loongarch64_unknown_none="-ffreestanding -mabi=lp64d"  CC_loongarch64_unknown_none_softfloat=loongarch64-unknown-linux-gnu-gcc  AR_loongarch64_unknown_none_softfloat=loongarch64-unknown-linux-gnu-ar  CXX_loongarch64_unknown_none_softfloat=loongarch64-unknown-linux-gnu-g++  CFLAGS_loongarch64_unknown_none_softfloat="-ffreestanding -mabi=lp64s -mfpu=none"  CXXFLAGS_loongarch64_unknown_none_softfloat="-ffreestanding -mabi=lp64s -mfpu=none" </ins> ENV HOSTS=loongarch64-unknown-linux-gnu <ins> ENV TARGETS=$HOSTS ENV TARGETS=$TARGETS,loongarch64-unknown-none ENV TARGETS=$TARGETS,loongarch64-unknown-none-softfloat </ins> ENV RUST_CONFIGURE_ARGS  --enable-extended
Code change:
When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc

Related discussion:
text: --enable-profiler  --disable-docs <del> ENV SCRIPT python3 ../x.py dist --host $HOSTS --target $HOSTS </del> <ins> ENV SCRIPT python3 ../x.py dist --host $HOSTS --target $TARGETS </ins>
Code change:
When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc

Related discussion:
text: ENV TARGETS=$TARGETS,armv7-unknown-linux-musleabi ENV TARGETS=$TARGETS,i686-unknown-freebsd ENV TARGETS=$TARGETS,x86_64-unknown-none <del> ENV TARGETS=$TARGETS,loongarch64-unknown-none ENV TARGETS=$TARGETS,loongarch64-unknown-none-softfloat </del> ENV TARGETS=$TARGETS,aarch64-unknown-uefi ENV TARGETS=$TARGETS,i686-unknown-uefi ENV TARGETS=$TARGETS,x86_64-unknown-uefi
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: unsafe { self.current = unlinked_node.as_ref().next; self.list.unlink_node(unlinked_node); <del> let unlinked_node = Box::from_raw(unlinked_node.as_ptr()); </del> <ins> let unlinked_node = Box::from_raw_in(unlinked_node.as_ptr(), &self.list.alloc); </ins> Some(unlinked_node.element) } }
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: if (self.pred)(&mut node.as_mut().element) { // `unlink_node` is okay with aliasing `element` references. self.list.unlink_node(node); <del> return Some(Box::from_raw(node.as_ptr()).element); </del> <ins> return Some(Box::from_raw_in(node.as_ptr(), &self.list.alloc).element); </ins> } } }
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: assert_eq!(unsafe { DROPS }, 8); } <ins> #[test] fn test_allocator() { use core::alloc::AllocError; use core::alloc::Allocator; use core::alloc::Layout; use core::cell::Cell; struct A { has_allocated: Cell<bool>, has_deallocated: Cell<bool>, } unsafe impl Allocator for A { fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> { assert!(!self.has_allocated.get()); self.has_allocated.set(true); Global.allocate(layout) } unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) { assert!(!self.has_deallocated.get()); self.has_deallocated.set(true); unsafe { Global.deallocate(ptr, layout) } } } let alloc = &A { has_allocated: Cell::new(false), has_deallocated: Cell::new(false) }; { let mut list = LinkedList::new_in(alloc); list.push_back(5u32); list.remove(0); } assert!(alloc.has_allocated.get()); assert!(alloc.has_deallocated.get()); } </ins>
Code change:
The DEFAULTMINSTACK_SIZE is the default stack size assigned when creating a thread. This value varies across different platforms. The issue is that there isn't enough explanation as to why these values are different, and users might not realize that the stack size can vary. Recently, I was running existing Windows code on a WASI target, and I kept encountering font decoding failures. Since it worked correctly on Windows, I suspected WASI's instability and spent considerable time debugging. After several days, I discovered that the root cause was the stack size: WASI has a very small stack size of 4KB, while Windows has a much larger stack size of 2MB. Once I forcibly increased the thread's stack size, all issues were resolved. I felt quite frustrated that such a simple reason caused the problem. Although this is my personal experience, I believe that rather than setting different default stack sizes for different platforms without a compelling reason, it would be better to have a consistent stack size across all platforms in Rust. However, I acknowledge that this suggestion might not be very effective because the required memory can vary depending on the instruction set or architecture. I would like to discuss this matter further.
Different platforms have different useful minimum stack sizes. I have no idea why only 4KiB is reserved on wasi.
In my opinion, this isn't an issue of "inconsistency" this is an issue of a target having an absurdly low value, period. Please open a PR to raise it.
What are the criteria for determining that? Since I don't know, I can't tell whether the 4KB for WASI is inappropriate or not, and I also can't open a PR because I don't know the appropriate value.
...a zillion insanely low-level minutiae like how big the registers are, mostly. an article that might help: as that article explains, the smallest thread stack size of all platforms that I'm aware of, aside from the ones in our repo that only ask for 4096 bytes, is 64KiB. the current 4096 bytes boundary has caused you significant pain so it seems sensible to raise it to at least that much, then fool around and see how it works.
having done some review of our platform code, I am pretty sure 4096 bytes was just picked as the "unsupported" value and platforms that initially lacked thread support, like wasm32-wasi, just inherited that value.
I understand. The differences between the platforms are indeed huge..! Before proceeding, I would like to hear the opinion or history from Alex Crichton, the main maintainer of the wasi target. , could you please share your thoughts on this issue?
I commented a bit on but I've no recollection for the current value for wasi. I suspect it was a number of historical accidents that led to this, and stack sizes should definitely be larger than 4k by default on wasi. Thanks for the issue

Related discussion:
text: } } <del> pub const DEFAULT_MIN_STACK_SIZE: usize = 4096; </del> <ins> pub const DEFAULT_MIN_STACK_SIZE: usize = 64 * 1024; </ins> impl Thread { // unsafe: see thread::Builder::spawn_unchecked for safety requirements
Code change:
The DEFAULTMINSTACK_SIZE is the default stack size assigned when creating a thread. This value varies across different platforms. The issue is that there isn't enough explanation as to why these values are different, and users might not realize that the stack size can vary. Recently, I was running existing Windows code on a WASI target, and I kept encountering font decoding failures. Since it worked correctly on Windows, I suspected WASI's instability and spent considerable time debugging. After several days, I discovered that the root cause was the stack size: WASI has a very small stack size of 4KB, while Windows has a much larger stack size of 2MB. Once I forcibly increased the thread's stack size, all issues were resolved. I felt quite frustrated that such a simple reason caused the problem. Although this is my personal experience, I believe that rather than setting different default stack sizes for different platforms without a compelling reason, it would be better to have a consistent stack size across all platforms in Rust. However, I acknowledge that this suggestion might not be very effective because the required memory can vary depending on the instruction set or architecture. I would like to discuss this matter further.
Different platforms have different useful minimum stack sizes. I have no idea why only 4KiB is reserved on wasi.
In my opinion, this isn't an issue of "inconsistency" this is an issue of a target having an absurdly low value, period. Please open a PR to raise it.
What are the criteria for determining that? Since I don't know, I can't tell whether the 4KB for WASI is inappropriate or not, and I also can't open a PR because I don't know the appropriate value.
...a zillion insanely low-level minutiae like how big the registers are, mostly. an article that might help: as that article explains, the smallest thread stack size of all platforms that I'm aware of, aside from the ones in our repo that only ask for 4096 bytes, is 64KiB. the current 4096 bytes boundary has caused you significant pain so it seems sensible to raise it to at least that much, then fool around and see how it works.
having done some review of our platform code, I am pretty sure 4096 bytes was just picked as the "unsupported" value and platforms that initially lacked thread support, like wasm32-wasi, just inherited that value.
I understand. The differences between the platforms are indeed huge..! Before proceeding, I would like to hear the opinion or history from Alex Crichton, the main maintainer of the wasi target. , could you please share your thoughts on this issue?
I commented a bit on but I've no recollection for the current value for wasi. I suspect it was a number of historical accidents that led to this, and stack sizes should definitely be larger than 4k by default on wasi. Thanks for the issue

Related discussion:
text: pub struct Thread(!); <del> pub const DEFAULT_MIN_STACK_SIZE: usize = 4096; </del> <ins> pub const DEFAULT_MIN_STACK_SIZE: usize = 64 * 1024; </ins> impl Thread { // unsafe: see thread::Builder::spawn_unchecked for safety requirements
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D

Related discussion:
text: use std::hash::Hash; use super::{ <del> err_ub, format_interp_error, machine::AllocMap, throw_ub, AllocId, CheckInAllocMsg, </del> <ins> err_ub, format_interp_error, machine::AllocMap, throw_ub, AllocId, AllocKind, CheckInAllocMsg, </ins> GlobalAlloc, ImmTy, Immediate, InterpCx, InterpResult, MPlaceTy, Machine, MemPlaceMeta, OpTy, Pointer, Projectable, Scalar, ValueVisitor, };
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D

Related discussion:
text: Ub(PointerOutOfBounds { .. }) => DanglingPtrOutOfBounds { ptr_kind }, <del> // This cannot happen during const-eval (because interning already detects // dangling pointers), but it can happen in Miri. </del> Ub(PointerUseAfterFree(..)) => DanglingPtrUseAfterFree { ptr_kind, },
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D

Related discussion:
text: } } <del> // Mutability check. </del> <ins> // Dangling and Mutability check. let (size, _align, alloc_kind) = self.ecx.get_alloc_info(alloc_id); if alloc_kind == AllocKind::Dead { // This can happen for zero-sized references. We can't have *any* references to non-existing // allocations though, interning rejects them all as the rest of rustc isn't happy with them... // so we throw an error, even though this isn't really UB. // A potential future alternative would be to resurrect this as a zero-sized allocation // (which codegen will then compile to an aligned dummy pointer anyway). throw_validation_failure!(self.path, DanglingPtrUseAfterFree { ptr_kind }); } </ins> // If this allocation has size zero, there is no actual mutability here. <del> let (size, _align, _alloc_kind) = self.ecx.get_alloc_info(alloc_id); </del> if size != Size::ZERO { let alloc_actual_mutbl = mutability(self.ecx, alloc_id); // Mutable pointer to immutable memory is no good.
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D

Related discussion:
text: } const FOO: &() = { <del> //~^ ERROR encountered dangling pointer </del> <ins> //~^ ERROR it is undefined behavior to use this value </ins> let y = (); unsafe { Foo { y: &y }.long_live_the_unit } };
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D

Related discussion:
text: <del> error: encountered dangling pointer in final value of constant </del> <ins> error[E0080]: it is undefined behavior to use this value </ins> --> $DIR/dangling-alloc-id-ice.rs:12:1 | LL | const FOO: &() = { <del> | ^^^^^^^^^^^^^^ </del> <ins> | ^^^^^^^^^^^^^^ constructing invalid value: encountered a dangling reference (use-after-free) | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. = note: the raw bytes of the constant (size: $SIZE, align: $ALIGN) { HEX_DUMP } </ins> error: aborting due to 1 previous error <ins> For more information about this error, try `rustc --explain E0080`. </ins>