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 ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!

Related discussion:
text: } .docblock li { <del> margin-bottom: .8em; </del> <ins> margin-bottom: .4em; </ins> } <del> .docblock li p { margin-bottom: .1em; </del> <ins> .docblock li p:not(:last-child) { /* This margin is voluntarily smaller than `.docblock li` to keep the visual list element items separated while also having a visual separation (although smaller) for paragraphs. */ margin-bottom: .3em; </ins> } /* "where ..." clauses with block display are also smaller */
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 ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!

Related discussion:
text: <ins> // This test ensures that the documentation list markers are correctly placed. // It also serves as a regression test for <https://github.com/rust-lang/rust/issues/130622>. go-to: "file://" + |DOC_PATH| + "/test_docs/long_list/index.html" show-text: true // 0.3em assert-css: (".docblock li p:not(last-child)", {"margin-bottom": "4.8px"}) assert-css: (".docblock li p + p:last-child", {"margin-bottom": "0px"}) // 0.4em assert-css: (".docblock li", {"margin-bottom": "6.4px"}) </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 ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!

Related discussion:
text: /// subt_vec_num(x: &[f64], y: f64) pub fn subt_vec_num() {} } <ins> pub mod long_list { //! bla //! //! * Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque et libero ut leo //!   interdum laoreet vitae a mi. Aliquam erat volutpat. Suspendisse volutpat non quam non //!   commodo. //! //!   Praesent enim neque, imperdiet sed nisl at, lobortis egestas augue. Sed vitae tristique //!   augue. Phasellus vel pretium lectus. //! * Praesent enim neque, imperdiet sed nisl at, lobortis egestas augue. Sed vitae tristique //!   augue. Phasellus vel pretium lectus. //! * Praesent enim neque, imperdiet sed nisl at, lobortis egestas augue. Sed vitae tristique //!   augue. Phasellus vel pretium lectus. //! //! Another list: //! //! * [`TryFromBytes`](#a) indicates that a type may safely be converted from certain byte //!   sequence (conditional on runtime checks) //! * [`FromZeros`](#a) indicates that a sequence of zero bytes represents a valid instance of //!   a type //! * [`FromBytes`](#a) indicates that a type may safely be converted from an arbitrary byte //!   sequence } </ins>
Code change:
When I do , it says: Strangely, when I do , it uses the correct name: No idea how it is even possible for this tool to have two different names inside bootstrap...
I think this is just because cargo-miri's tool check step is generated through a macro this macro generates the check message via there's a in there too. The build step has a different name because that macro explicitly asks for a display name
If I make the macro use a display name,
Ah, I didn't realize those two steps were defined entirely independently.
Anyway, should make this more consistent.

Related discussion:
text: } macro_rules! tool_check_step { <del> ($name:ident, $path:literal, $($alias:literal, )* $source_type:path $(, $default:literal )?) => { </del> <ins> ( $name:ident, $display_name:literal, $path:literal, $($alias:literal, )* $source_type:path $(, $default:literal )? ) => { </ins> #[derive(Debug, Clone, PartialEq, Eq, Hash)] pub struct $name { pub target: TargetSelection,
Code change:
When I do , it says: Strangely, when I do , it uses the correct name: No idea how it is even possible for this tool to have two different names inside bootstrap...
I think this is just because cargo-miri's tool check step is generated through a macro this macro generates the check message via there's a in there too. The build step has a different name because that macro explicitly asks for a display name
If I make the macro use a display name,
Ah, I didn't realize those two steps were defined entirely independently.
Anyway, should make this more consistent.

Related discussion:
text: cargo.arg("--all-targets"); } <del> let _guard = builder.msg_check(&concat!(stringify!($name), " artifacts").to_lowercase(), target); </del> <ins> let _guard = builder.msg_check(&format!("{} artifacts", $display_name), target); </ins> run_cargo( builder, cargo,
Code change:
When I do , it says: Strangely, when I do , it uses the correct name: No idea how it is even possible for this tool to have two different names inside bootstrap...
I think this is just because cargo-miri's tool check step is generated through a macro this macro generates the check message via there's a in there too. The build step has a different name because that macro explicitly asks for a display name
If I make the macro use a display name,
Ah, I didn't realize those two steps were defined entirely independently.
Anyway, should make this more consistent.

Related discussion:
text: }; } <del> tool_check_step!(Rustdoc, "src/tools/rustdoc", "src/librustdoc", SourceType::InTree); </del> <ins> tool_check_step!(Rustdoc, "rustdoc", "src/tools/rustdoc", "src/librustdoc", SourceType::InTree); </ins> // Clippy, miri and Rustfmt are hybrids. They are external tools, but use a git subtree instead // of a submodule. Since the SourceType only drives the deny-warnings // behavior, treat it as in-tree so that any new warnings in clippy will be // rejected. <del> tool_check_step!(Clippy, "src/tools/clippy", SourceType::InTree); tool_check_step!(Miri, "src/tools/miri", SourceType::InTree); tool_check_step!(CargoMiri, "src/tools/miri/cargo-miri", SourceType::InTree); tool_check_step!(Rls, "src/tools/rls", SourceType::InTree); tool_check_step!(Rustfmt, "src/tools/rustfmt", SourceType::InTree); tool_check_step!(MiroptTestTools, "src/tools/miropt-test-tools", SourceType::InTree); tool_check_step!(TestFloatParse, "src/etc/test-float-parse", SourceType::InTree); tool_check_step!(Bootstrap, "src/bootstrap", SourceType::InTree, false); </del> <ins> tool_check_step!(Clippy, "clippy", "src/tools/clippy", SourceType::InTree); tool_check_step!(Miri, "miri", "src/tools/miri", SourceType::InTree); tool_check_step!(CargoMiri, "cargo-miri", "src/tools/miri/cargo-miri", SourceType::InTree); tool_check_step!(Rls, "rls", "src/tools/rls", SourceType::InTree); tool_check_step!(Rustfmt, "rustfmt", "src/tools/rustfmt", SourceType::InTree); tool_check_step!( MiroptTestTools, "miropt-test-tools", "src/tools/miropt-test-tools", SourceType::InTree ); tool_check_step!( TestFloatParse, "test-float-parse", "src/etc/test-float-parse", SourceType::InTree ); tool_check_step!(Bootstrap, "bootstrap", "src/bootstrap", SourceType::InTree, false); </ins> /// Cargo's output path for the standard library in a given stage, compiled /// by a particular compiler for the specified target.
Code change:
The input for doc searches isn't sanitized, allowing for arbitrary HTML input.
Is this problematic? Afaik everything is done client-side.
Yes. For example, if rustdoc documentation is served on a site that uses a cookie for authentication, an attacker could perform XHRs on the victim's behalf by injecting a tag. It's not particularly problematic on the site, though.
But the search is done with client-side javascript on a client-side resources index; how can you secure that?
I'm not sure what you mean by the search being unsecurable because the index is searched on the client. The problem is that the Javascript responsible for rendering the search query does not properly escape it, so an attacker can insert arbitrary HTML and therefore execute arbitrary Javascript in another user's browser merely by tricking the user into following a link. This is easily fixed by escaping and here: If you're not convinced of the danger, see for an example. If I were more nefarious, and I knew of a site that served rustdoc HTML documentation on the same domain as another site that uses cookie authentication, I could impersonate a user of this site just by convincing them to follow a link I've sent them.
I see thanks for the explanations, opened up a PR for it.
I think this is the part that makes me go from "meh" to "OH!." There's not a lot of damage on rust-, but we shouldn't open up others to these issues.

Related discussion:
text: }); } <ins> function escape(content) { return $('<h1/>').text(content).html(); } </ins> function showResults(results) { var output, shown, query = getQuery(); currentResults = query.id; <del> output = '<h1>Results for ' + query.query + (query.type ? ' (type: ' + query.type + ')' : '') + '</h1>'; </del> <ins> output = '<h1>Results for ' + escape(query.query) + (query.type ? ' (type: ' + escape(query.type) + ')' : '') + '</h1>'; </ins> output += '<table class="search-results">'; if (results.length > 0) {
Code change:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:

Related discussion:
text: TcpWatcher { home: home, handle: handle, <del> stream: StreamWatcher::new(handle), </del> <ins> stream: StreamWatcher::new(handle, true), </ins> refcount: Refcount::new(), read_access: AccessTimeout::new(), write_access: AccessTimeout::new(),
Code change:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:

Related discussion:
text: fn clone(&self) -> Box<rtio::RtioTcpStream + Send> { box TcpWatcher { handle: self.handle, <del> stream: StreamWatcher::new(self.handle), </del> <ins> stream: StreamWatcher::new(self.handle, false), </ins> home: self.home.clone(), refcount: self.refcount.clone(), read_access: self.read_access.clone(),
Code change:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:

Related discussion:
text: handle }; PipeWatcher { <del> stream: StreamWatcher::new(handle), </del> <ins> stream: StreamWatcher::new(handle, true), </ins> home: home, defused: false, refcount: Refcount::new(),
Code change:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:

Related discussion:
text: fn clone(&self) -> Box<rtio::RtioPipe + Send> { box PipeWatcher { <del> stream: StreamWatcher::new(self.stream.handle), </del> <ins> stream: StreamWatcher::new(self.stream.handle, false), </ins> defused: false, home: self.home.clone(), refcount: self.refcount.clone(),
Code change:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:

Related discussion:
text: // will be manipulated on each of the methods called on this watcher. // Wrappers should ensure to always reset the field to an appropriate value // if they rely on the field to perform an action. <del> pub fn new(stream: *mut uvll::uv_stream_t) -> StreamWatcher { unsafe { uvll::set_data_for_uv_handle(stream, 0 as *mut int) } </del> <ins> pub fn new(stream: *mut uvll::uv_stream_t, init: bool) -> StreamWatcher { if init { unsafe { uvll::set_data_for_uv_handle(stream, 0 as *mut int) } } </ins> StreamWatcher { handle: stream, last_write_req: None,