jiebi/CodeConvo huggingface dataset:
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: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.

Related discussion:
text: use crate::sys::c; use crate::sys::cvt; use crate::sys::handle::Handle; <ins> use core::str::utf8_char_width; </ins> // Don't cache handles but get them fresh for every read/write. This allows us to track changes to // the value over time (such as if a process calls `SetStdHandle` while it's running). See #40490. pub struct Stdin { surrogate: u16, } <del> pub struct Stdout; pub struct Stderr; </del> <ins> pub struct Stdout { incomplete_utf8: IncompleteUtf8, } pub struct Stderr { incomplete_utf8: IncompleteUtf8, } struct IncompleteUtf8 { bytes: [u8; 4], len: u8, } </ins> // Apparently Windows doesn't handle large reads on stdin or writes to stdout/stderr well (see // #13304 for details).
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: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.

Related discussion:
text: unsafe { c::GetConsoleMode(handle, &mut mode) != 0 } } <del> fn write(handle_id: c::DWORD, data: &[u8]) -> io::Result<usize> { </del> <ins> fn write( handle_id: c::DWORD, data: &[u8], incomplete_utf8: &mut IncompleteUtf8, ) -> io::Result<usize> { if data.is_empty() { return Ok(0); } </ins> let handle = get_handle(handle_id)?; if !is_console(handle) { let handle = Handle::new(handle);
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: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.

Related discussion:
text: Ok(written) } <ins> impl IncompleteUtf8 { pub const fn new() -> IncompleteUtf8 { IncompleteUtf8 { bytes: [0; 4], len: 0 } } } </ins> impl Stdout { pub const fn new() -> Stdout { <del> Stdout </del> <ins> Stdout { incomplete_utf8: IncompleteUtf8::new() } </ins> } } impl io::Write for Stdout { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> write(c::STD_OUTPUT_HANDLE, buf) </del> <ins> write(c::STD_OUTPUT_HANDLE, buf, &mut self.incomplete_utf8) </ins> } fn flush(&mut self) -> io::Result<()> {
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: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.

Related discussion:
text: impl Stderr { pub const fn new() -> Stderr { <del> Stderr </del> <ins> Stderr { incomplete_utf8: IncompleteUtf8::new() } </ins> } } impl io::Write for Stderr { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> write(c::STD_ERROR_HANDLE, buf) </del> <ins> write(c::STD_ERROR_HANDLE, buf, &mut self.incomplete_utf8) </ins> } fn flush(&mut self) -> io::Result<()> {
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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: let mut inserted = FxHashSet::default(); items.extend(doc.foreigns.iter().map(|(item, renamed)| { let item = clean_maybe_renamed_foreign_item(cx, item, *renamed); <del> if let Some(name) = item.name { </del> <ins> if let Some(name) = item.name && !item.attrs.lists(sym::doc).has_word(sym::hidden) { </ins> inserted.insert((item.type_(), name)); } item })); <del> items.extend(doc.mods.iter().map(|x| { inserted.insert((ItemType::Module, x.name)); clean_doc_module(x, cx) </del> <ins> items.extend(doc.mods.iter().filter_map(|x| { if !inserted.insert((ItemType::Module, x.name)) { return None; } let item = clean_doc_module(x, cx); if item.attrs.lists(sym::doc).has_word(sym::hidden) { // Hidden modules are stripped at a later stage. // If a hidden module has the same name as a visible one, we want // to keep both of them around. inserted.remove(&(ItemType::Module, x.name)); } Some(item) </ins> })); // Split up imports from all other items.
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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: } let v = clean_maybe_renamed_item(cx, item, *renamed); for item in &v { <del> if let Some(name) = item.name { </del> <ins> if let Some(name) = item.name && !item.attrs.lists(sym::doc).has_word(sym::hidden) { </ins> inserted.insert((item.type_(), name)); } }
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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: self.inside_public_path &= self.cx.tcx.visibility(def_id).is_public(); for &i in m.item_ids { let item = self.cx.tcx.hir().item(i); <ins> if matches!(item.kind, hir::ItemKind::Use(_, hir::UseKind::Glob)) { continue; } </ins> self.visit_item(item, None, &mut om); } <ins> for &i in m.item_ids { let item = self.cx.tcx.hir().item(i); // To match the way import precedence works, visit glob imports last. // Later passes in rustdoc will de-duplicate by name and kind, so if glob- // imported items appear last, then they'll be the ones that get discarded. if matches!(item.kind, hir::ItemKind::Use(_, hir::UseKind::Glob)) { self.visit_item(item, None, &mut om); } } </ins> self.inside_public_path = orig_inside_public_path; om }
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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: <ins> // https://github.com/rust-lang/rust/pull/83872#issuecomment-820101008 #![crate_name="foo"] mod sub4 { /// 0 pub const X: usize = 0; pub mod inner { pub use super::*; /// 1 pub const X: usize = 1; } } #[doc(inline)] pub use sub4::inner::*; // @has 'foo/index.html' // @has - '//div[@class="item-right docblock-short"]' '1' // @!has - '//div[@class="item-right docblock-short"]' '0' fn main() { assert_eq!(X, 1); } </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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: <ins> // @has 'glob_shadowing/index.html' // @count - '//div[@class="item-left module-item"]' 6 // @!has - '//div[@class="item-right docblock-short"]' 'sub1::describe' // @has - '//div[@class="item-right docblock-short"]' 'sub2::describe' // @!has - '//div[@class="item-right docblock-short"]' 'sub1::describe2' // @!has - '//div[@class="item-right docblock-short"]' 'sub1::prelude' // @has - '//div[@class="item-right docblock-short"]' 'mod::prelude' // @has - '//div[@class="item-right docblock-short"]' 'sub1::Foo (struct)' // @has - '//div[@class="item-right docblock-short"]' 'mod::Foo (function)' // @has - '//div[@class="item-right docblock-short"]' 'sub4::inner::X' // @has 'glob_shadowing/fn.describe.html' // @has - '//div[@class="docblock"]' 'sub2::describe' mod sub1 { // this should be shadowed by sub2::describe /// sub1::describe pub fn describe() -> &'static str { "sub1::describe" } // this should be shadowed by mod::prelude /// sub1::prelude pub mod prelude { } // this should *not* be shadowed, because sub1::Foo and mod::Foo are in different namespaces /// sub1::Foo (struct) pub struct Foo; // this should be shadowed, // because both sub1::describe2 and sub3::describe2 are from glob reexport /// sub1::describe2 pub fn describe2() -> &'static str { "sub1::describe2" } } mod sub2 { /// sub2::describe pub fn describe() -> &'static str { "sub2::describe" } } mod sub3 { // this should be shadowed // because both sub1::describe2 and sub3::describe2 are from glob reexport /// sub3::describe2 pub fn describe2() -> &'static str { "sub3::describe2" } } mod sub4 { // this should be shadowed by sub4::inner::X /// sub4::X pub const X: usize = 0; pub mod inner { pub use super::*; /// sub4::inner::X pub const X: usize = 1; } } /// mod::Foo (function) pub fn Foo() {} #[doc(inline)] pub use sub2::describe; #[doc(inline)] pub use sub1::*; #[doc(inline)] pub use sub3::*; #[doc(inline)] pub use sub4::inner::*; /// mod::prelude pub mod prelude {} </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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: <ins> #![crate_name = "foo"] pub mod sub { pub struct Item; pub mod prelude { pub use super::Item; } } #[doc(inline)] pub use sub::*; // @count foo/index.html '//a[@class="mod"][@title="foo::prelude mod"]' 1 // @count foo/prelude/index.html '//div[@class="item-row"]' 0 pub mod prelude {} </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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: <ins> #![crate_name = "foo"] pub mod sub { pub struct Item; pub mod prelude { pub use super::Item; } } // @count foo/index.html '//a[@class="mod"][@title="foo::prelude mod"]' 1 // @count foo/prelude/index.html '//div[@class="item-row"]' 0 pub mod prelude {} #[doc(inline)] pub use sub::*; </ins>
Code change:
From a recent Reddit discussion ( ): Gives (rustc 1.53.0-nightly 2021-03-26): That Reddit discussion shows other cases.
See also:
I am quite surprised but fix of doesn't fix this issue. <details<summaryASM </summary</details
With the last nightly I'm seeing a probable improvement in foo1b (the second):
It looks like that one of SROA passes transforms getting of tuple fields into nearly this: Edit: Removing SROA doesn't prevent this transformation, it just happens in other steps.
This leads to big overhead of tuples and structs (because tuples is structs). Benchmark Results: So, PartialEq slower from 4 to 40 times.
Hack We could change std using this weird trick but possibly shouldn't. <details<summaryHacky code</summary</detailsThe problem is that we still: 't fix situation for structs (actually, problem affects every struct which size less or equal to 8 bytes) 't fix situation with tuples like or (newtypeoveru8, u8, ...) With the last nightly I'm seeing a probable improvement in foo1b (the second): Unfortunately, and inlining would convert this function to case. I suggest you to rename the issue to something like "Small POD struct equality ineffective".
It looks like Clang incapable for making such optimizations as well.
On the LLVM side, we're basically missing this fold:
Upstream review:
Upstream fix:
I ran into an issue where using a struct of two arrays was significant slower than passing those arrays directly. My arrays were larger, but the struct also came with a large overhead. Could those issues be related?
Unfortunately this has not been fixed by the LLVM 13 upgrade. Might be an unfortunate interaction with the migration from bitwise to logical and.
Upstream fix for the logical and/or issue: , Might make sense to cherry-pick this to our fork to avoid waiting another release cycle.
For the case foo1b the MergeICmps pass would usually handle this in the backend, but it's getting blocked by additional calls.
We're now generating good code for everything but foo1b: foo1b still unnecessarily splits out one comparison. Either or should address that.
Remaining case is fixed by the LLVM upgrade in Adding a codegen test for this may be worthwhile.
Thats true for , for it's still the same.

Related discussion:
text: <ins> //@ assembly-output: emit-asm //@ compile-flags:-Copt-level=3 //@ only-x86_64 #![crate_type = "lib"] #[no_mangle] type T = u8; type T1 = (T, T, T, T, T, T, T, T); type T2 = [T; 8]; #[no_mangle] // CHECK-LABEL: foo1a // CHECK: cmp // CHECK-NEXT: set // CHECK-NEXT: ret pub fn foo1a(a: T1, b: T1) -> bool { a == b } #[no_mangle] // CHECK-LABEL: foo1b // CHECK: mov // CHECK-NEXT: cmp // CHECK-NEXT: set // CHECK-NEXT: ret pub fn foo1b(a: &T1, b: &T1) -> bool { a == b } </ins>