jiebi/CodeConvo huggingface dataset:
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: return "Vec(size={})".format(self.length) def children(self): <del> saw_inaccessible = False for index in xrange(self.length): element_ptr = self.data_ptr + index if saw_inaccessible: return try: # rust-lang/rust#64343: passing deref expr to `str` allows # catching exception on garbage pointer str(element_ptr.dereference()) yield "[{}]".format(index), element_ptr.dereference() except RuntimeError: saw_inaccessible = True yield str(index), "inaccessible" </del> <ins> return _enumerate_array_elements( self.data_ptr + index for index in xrange(self.length) ) </ins> @staticmethod def display_hint():
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: return "VecDeque(size={})".format(self.size) def children(self): <del> for index in xrange(0, self.size): value = (self.data_ptr + ((self.tail + index) % self.cap)).dereference() yield "[{}]".format(index), value </del> <ins> return _enumerate_array_elements( (self.data_ptr + ((self.tail + index) % self.cap)) for index in xrange(self.size) ) </ins> @staticmethod def display_hint():
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: type synthetic add -l lldb_lookup.synthetic_lookup -x ".*" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)String$" --category Rust <del> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&str$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&[.+]$" --category Rust </del> <ins> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?str$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?[.+]$" --category Rust </ins> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(std::ffi::([a-z_]+::)+)OsString$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)Vec<.+>$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)VecDeque<.+>$" --category Rust
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: STD_STRING_REGEX = re.compile(r"^(alloc::(w+::)+)String$") <del> STD_STR_REGEX = re.compile(r"^&str$") STD_SLICE_REGEX = re.compile(r"^&[.+]$") </del> <ins> STD_STR_REGEX = re.compile(r"^&(mut )?str$") STD_SLICE_REGEX = re.compile(r"^&(mut )?[.+]$") </ins> STD_OS_STRING_REGEX = re.compile(r"^(std::ffi::(w+::)+)OsString$") STD_VEC_REGEX = re.compile(r"^(alloc::(w+::)+)Vec<.+>$") STD_VEC_DEQUE_REGEX = re.compile(r"^(alloc::(w+::)+)VecDeque<.+>$")
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: // gdb-check:$1 = Vec(size=1000000000) = {[...]...} // gdb-command: print slice <del> // gdb-check:$2 = &[u8] {data_ptr: [...], length: 1000000000} </del> <ins> // gdb-check:$2 = &[u8](size=1000000000) = {[...]...} </ins> #![allow(unused_variables)]
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: <ins> // ignore-android: FIXME(#10381) // ignore-windows // compile-flags:-g // gdb-command: run // gdb-command: print slice // gdbg-check: $1 = struct &[i32](size=3) = {0, 1, 2} // gdbr-check: $1 = &[i32](size=3) = {0, 1, 2} // gdb-command: print mut_slice // gdbg-check: $2 = struct &mut [i32](size=4) = {2, 3, 5, 7} // gdbr-check: $2 = &mut [i32](size=4) = {2, 3, 5, 7} // gdb-command: print str_slice // gdb-check: $3 = "string slice" // gdb-command: print mut_str_slice // gdb-check: $4 = "mutable string slice" // lldb-command: run // lldb-command: print slice // lldb-check: (&[i32]) $0 = size=3 { [0] = 0 [1] = 1 [2] = 2 } // lldb-command: print mut_slice // lldb-check: (&mut [i32]) $1 = size=4 { [0] = 2 [1] = 3 [2] = 5 [3] = 7 } // lldb-command: print str_slice // lldb-check: (&str) $2 = "string slice" { data_ptr = [...] length = 12 } // lldb-command: print mut_str_slice // lldb-check: (&mut str) $3 = "mutable string slice" { data_ptr = [...] length = 20 } fn b() {} fn main() { let slice: &[i32] = &[0, 1, 2]; let mut_slice: &mut [i32] = &mut [2, 3, 5, 7]; let str_slice: &str = "string slice"; let mut mut_str_slice_buffer = String::from("mutable string slice"); let mut_str_slice: &mut str = mut_str_slice_buffer.as_mut_str(); b(); // #break } </ins>
Code change:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools

Related discussion:
text: let rust_type_regexes = vec![ "^(alloc::([a-z_]+::)+)String$", <del> "^&str$", "^&[.+]$", </del> <ins> "^&(mut )?str$", "^&(mut )?[.+]$", </ins> "^(std::ffi::([a-z_]+::)+)OsString$", "^(alloc::([a-z_]+::)+)Vec<.+>$", "^(alloc::([a-z_]+::)+)VecDeque<.+>$",
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this: (at ) windows-gnu nightly: wasm target: the package for : Result: The invokes . depends on that is not present in the distribution. If I add it manually, the issue goes away. The flavor ships with that does not have this dependency. and (and likely everything between)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low +T-compiler +O-windows Edit: my assessment was wrong, this requires more prompt attention label -P-low +P-high
I have the same issue with "stable" rust 1.52.1 ( 2021-05-09) on Windows 10 with a wasm32-unknown-unknown target. Can you elaborate on how to quick-fix this by adding manually? Where can I get, and where do I put I only have from Mingw64, Mingw32, and many other SW packages. Is it the same? Btw. what hit me instantly is the move from LLVM 11 to 12. Might that be the issue?
Yes, at least enough so it works for me. Just rename any zlib binary, the library interface has been stable for a very long time, so it should just work. Or, if you are ok with using binaries received from strangers, take this: . When you have , you need to make it visible. Either place it in any location visible in environment variable, or place it next to the . For me it is located in . See if you want in-depth explanation where the Windows looks for the DLLs.
It works, thanks a lot. It was a bit confusing that I don't have rust-lld in the wasm target folder. Now I can work on my fullstack project again without worrying about OS specific issues :-)

Related discussion:
text: .define("LLVM_TARGET_ARCH", target_native.split('-').next().unwrap()) .define("LLVM_DEFAULT_TARGET_TRIPLE", target_native); <del> if target != "aarch64-apple-darwin" { </del> <ins> if target != "aarch64-apple-darwin" && !target.contains("windows") { </ins> cfg.define("LLVM_ENABLE_ZLIB", "ON"); } else { cfg.define("LLVM_ENABLE_ZLIB", "OFF");
Code change:
is not updated (line 1636) when (line 1623) panics. This lets 's implementation to retain the already dropped element. The bug was introduced in and affects stable Rust versions = 1.52. Here is the that demonstrates the double free without using unsafe Rust code. <!-- 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. --:
label regression-from-stable-to-stable
Assigning as discussed by and removing . modify labels +P-critical -I-prioritize
Interestingly there was a test for this, but it is wrong. The vec contains the index=5, even though it is the item that panics in its drop implementation. I guess the author of this test thought that returned the new value instead of the old value?
Learning about a double-free I introduced, a year later... :eyes: And honestly, I can clearly remember that when the test was first written, it caught the bug, but I just assumed it was an off-by-one error in the testing code itself, yikes

Related discussion:
text: let prev_ptr = ptr.add(gap.write.wrapping_sub(1)); if same_bucket(&mut *read_ptr, &mut *prev_ptr) { <ins> // Increase `gap.read` now since the drop may panic. gap.read += 1; </ins> /* We have found duplicate, drop it in-place */ ptr::drop_in_place(read_ptr); } else {
Code change:
is not updated (line 1636) when (line 1623) panics. This lets 's implementation to retain the already dropped element. The bug was introduced in and affects stable Rust versions = 1.52. Here is the that demonstrates the double free without using unsafe Rust code. <!-- 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. --:
label regression-from-stable-to-stable
Assigning as discussed by and removing . modify labels +P-critical -I-prioritize
Interestingly there was a test for this, but it is wrong. The vec contains the index=5, even though it is the item that panics in its drop implementation. I guess the author of this test thought that returned the new value instead of the old value?
Learning about a double-free I introduced, a year later... :eyes: And honestly, I can clearly remember that when the test was first written, it caught the bug, but I just assumed it was an off-by-one error in the testing code itself, yikes

Related discussion:
text: /* We have filled that place, so go further */ gap.write += 1; <ins> gap.read += 1; </ins> } <del> gap.read += 1; </del> } /* Technically we could let `gap` clean up with its Drop, but
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!

Related discussion:
text: <del> Subproject commit 62046bf8b4eadd4fb398d59f1eebcc140506bf85 </del> <ins> Subproject commit 4fa9363ebba236f7c29ae11180db6051d7d2ce3b </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: Compiling with , after the emsdk is activated and emcc works, to compile properly Instead, this happened: Prints this error: I've tried adding to no avail <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
runs successfully
Also is broken on ubuntu with the same error message (at least windows subsystem for linux)
rustc 1.53.0-nightly ( 2021-04-24) emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.12 () Here's some info I gathered: Rust tries to . I think Rust is assuming that this symbol comes from emscripten. emscripten has a : libc++abi.a: emscripten exceptions: this is what rustc is trying to use; libc++abi-noexcept.a: no exceptions: does not compile libc++abi-except.a: wasm exceptions: experimental; in emscripten's repo shows that was never compiled into libc++abi.a by This commit looks suspicious: Prior to emscripten SDK version 2.0.10, I think has been and never did anything. Rust probably shouldn't be calling a stubbed function. seems untested if you ask me because I don't know how it could ever have worked. I successfully compiled hello world with emscripten SDK version 2.0.9. That version still has the stub.
label I-prioritize T-compiler O-wasm
thanks for the analysis. Assigning priority as discussed in the of the Prioritization Working Group. Let's find someone who can have a look at this. label -I-prioritize +P-high +I-nominated
I recall with the LLVM 11 upgrade, the compat notes mentioned which version of Emscripten to use when compiling with the target. Once this bug is resolved, can we add a similar note for the releases that upgrade Rust to LLVM 12?
As mentioned the panic=unwind strategy is broken on wasm32-unknown-emscripten. I recommend to switch default to panic=abort. Note that also rust std lib has to be rebuilt with panic=abort to fix the undefined symbol errors. Testing on my side showed that the problem could be fixed by changing TargetOptions on line 38 to "panicstrategy: PanicStrategy::Abort," in file. Unfortunatelly I do not have experience in preparing pull request and have no capacity to get into it now.
This issue can be solved by setting the env var which will override any flags passed to emcc. See this comment - Passing these flags using the won't work, as they are not passed to the linker. I received this error in two places, one for symbol and one for , hence the flag.
Reported this on Emscripten:

Related discussion:
text: tinfo: *const TypeInfo, dest: extern "C" fn(*mut libc::c_void) -> *mut libc::c_void, ) -> !; <del> fn __gxx_personality_v0( version: c_int, actions: uw::_Unwind_Action, exception_class: uw::_Unwind_Exception_Class, exception_object: *mut uw::_Unwind_Exception, context: *mut uw::_Unwind_Context, ) -> uw::_Unwind_Reason_Code; </del> }
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!

Related discussion:
text: <del> Subproject commit 453affaaa1762a065d2857970b8333017211208c </del> <ins> Subproject commit 5dde0fe6de2941c9ef16bc1e9d91ecf20ac5ee8b </ins>
Code change:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.

Related discussion:
text: use crate::cmp; <del> use crate::iter::{ adapters::zip::try_get_unchecked, adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen, TrustedRandomAccess, }; </del> <ins> use crate::iter::{adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen}; </ins> use crate::ops::{ControlFlow, Try}; /// An iterator that only iterates over the first `n` iterations of `iter`.
Code change:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.

Related discussion:
text: self.try_fold(init, ok(fold)).unwrap() } <del> unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> <I as Iterator>::Item where Self: TrustedRandomAccess, { // SAFETY: the caller must uphold the contract for // `Iterator::__iterator_get_unchecked`. unsafe { try_get_unchecked(&mut self.iter, idx) } } </del> } #[unstable(issue = "none", feature = "inplace_iteration")]
Code change:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.

Related discussion:
text: #[unstable(feature = "trusted_len", issue = "37572")] unsafe impl<I: TrustedLen> TrustedLen for Take<I> {} <del> #[doc(hidden)] #[unstable(feature = "trusted_random_access", issue = "none")] unsafe impl<I> TrustedRandomAccess for Take<I> where I: TrustedRandomAccess, { const MAY_HAVE_SIDE_EFFECT: bool = I::MAY_HAVE_SIDE_EFFECT; } </del>