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. --Hello! :wave: I tried this code on Windows: I expected to see this happen: Success for an available address like and blocking forever (or until TCP timeout) for just like on Linux. Instead, this happened: the call never succeeds, not even for on Windows. Related: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! My best guess from quickly glancing at the code is that the problem is here: This is using to convert seconds into an (aka ). Which means that it can become a negative timeout. If I'm right then the fix here would be to limit the timeout to or less.
claim
thanks for your work on this and pushing it over the finish line! :+1: :pray:

Related discussion:
text: } #[test] <ins> #[cfg_attr(target_env = "sgx", ignore)] // FIXME: https://github.com/fortanix/rust-sgx/issues/31 fn connect_timeout_error() { let socket_addr = next_test_ip4(); let result = TcpStream::connect_timeout(&socket_addr, Duration::MAX); assert!(!matches!(result, Err(e) if e.kind() == ErrorKind::TimedOut)); let _listener = TcpListener::bind(&socket_addr).unwrap(); assert!(TcpStream::connect_timeout(&socket_addr, Duration::MAX).is_ok()); } #[test] </ins> fn listen_localhost() { let socket_addr = next_test_ip4(); let listener = t!(TcpListener::bind(&socket_addr));
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. --Hello! :wave: I tried this code on Windows: I expected to see this happen: Success for an available address like and blocking forever (or until TCP timeout) for just like on Linux. Instead, this happened: the call never succeeds, not even for on Windows. Related: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! My best guess from quickly glancing at the code is that the problem is here: This is using to convert seconds into an (aka ). Which means that it can become a negative timeout. If I'm right then the fix here would be to limit the timeout to or less.
claim
thanks for your work on this and pushing it over the finish line! :+1: :pray:

Related discussion:
text: } let mut timeout = c::timeval { <del> tv_sec: timeout.as_secs() as c_long, </del> <ins> tv_sec: cmp::min(timeout.as_secs(), c_long::MAX as u64) as c_long, </ins> tv_usec: (timeout.subsec_nanos() / 1000) as c_long, };
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

Related discussion:
text: } let mut new_abis = Vec::new(); <del> loop { </del> <ins> while !p.eat(&token::CloseDelim(Delimiter::Parenthesis)) { </ins> match p.parse_str_lit() { Ok(str_lit) => { new_abis.push((str_lit.symbol_unescaped, str_lit.span)); } Err(opt_lit) => { <del> // If the non-string literal is a closing paren then it's the end of the list and is fine if p.eat(&token::CloseDelim(Delimiter::Parenthesis)) { break; } </del> let span = opt_lit.map_or(p.token.span, |lit| lit.span); let mut err = p.sess.span_diagnostic.struct_span_err(span, "expected string literal");
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

Related discussion:
text: <ins> // only-x86_64 #![feature(asm_const)] use std::arch::asm; fn main() { let mut foo = 0; let mut bar = 0; unsafe { asm!("", a = in("eax") foo); //~^ ERROR explicit register arguments cannot have names asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{1}", in("eax") foo, const bar); //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments //~^^ ERROR attempt to use a non-constant value in a constant } } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

Related discussion:
text: <ins> error: explicit register arguments cannot have names --> $DIR/x86_64_parse_error.rs:11:18 | LL |         asm!("", a = in("eax") foo); |                  ^^^^^^^^^^^^^^^^^ error: positional arguments cannot follow named arguments or explicit register arguments --> $DIR/x86_64_parse_error.rs:17:36 | LL |         asm!("{1}", in("eax") foo, const bar); |                     -------------  ^^^^^^^^^ positional argument |                     | |                     explicit register argument error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:13:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:15:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:17:42 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{1}", in("eax") foo, const bar); |                                          ^^^ non-constant value error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0435`. </ins>
Code change:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

Related discussion:
text: // They can denote both statically and dynamically-sized byte arrays. let mut pat_ty = ty; if let hir::ExprKind::Lit(Spanned { node: ast::LitKind::ByteStr(..), .. }) = lt.kind { <del> if let ty::Ref(_, inner_ty, _) = *self.structurally_resolved_type(span, expected).kind() && self.structurally_resolved_type(span, inner_ty).is_slice() </del> <ins> let expected = self.structurally_resolved_type(span, expected); if let ty::Ref(_, inner_ty, _) = expected.kind() && matches!(inner_ty.kind(), ty::Slice(_)) </ins> { let tcx = self.tcx; trace!(?lt.hir_id.local_id, "polymorphic byte string lit");
Code change:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

Related discussion:
text: <ins> // check-pass fn load<L>() -> Option<L> { todo!() } fn main() { while let Some(tag) = load() { match &tag { b"NAME" => {} b"DATA" => {} _ => {} } } } </ins>
Code change:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

Related discussion:
text: // compile-flags: -Ztrait-solver=next <del> // check-pass </del> <ins> // known-bug: rust-lang/trait-system-refactor-initiative#38 </ins> fn test(s: &[u8]) { match &s[0..3] {
Code change:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

Related discussion:
text: <ins> error[E0271]: type mismatch resolving `[u8; 3] <: <Range<usize> as SliceIndex<[u8]>>::Output` --> $DIR/slice-match-byte-lit.rs:6:9 | LL |     match &s[0..3] { |           -------- this expression has type `&<std::ops::Range<usize> as SliceIndex<[u8]>>::Output` LL |         b"uwu" => {} |         ^^^^^^ types differ error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

Related discussion:
text: map.insert("toggle-all-docs".into(), 1); map.insert("all-types".into(), 1); map.insert("default-settings".into(), 1); <del> map.insert("rustdoc-vars".into(), 1); </del> map.insert("sidebar-vars".into(), 1); map.insert("copy-path".into(), 1); map.insert("TOC".into(), 1);
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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

Related discussion:
text: // Local js definitions: /* global addClass, getCurrentValue, onEachLazy, removeClass, browserSupportsHistoryApi */ <del> /* global updateLocalStorage */ </del> <ins> /* global updateLocalStorage, getVar */ </ins> "use strict"; (function() { <del> const rootPath = document.getElementById("rustdoc-vars").attributes["data-root-path"].value; </del> <ins> const rootPath = getVar("root-path"); </ins> const NAME_OFFSET = 0; const DIRS_OFFSET = 1;
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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

Related discussion:
text: // Get a value from the rustdoc-vars div, which is used to convey data from // Rust to the JS. If there is no such element, return null. const getVar = (function getVar(name) { <del> const el = document.getElementById("rustdoc-vars"); </del> <ins> const el = document.querySelector("head > meta[name='rustdoc-vars']"); </ins> return el ? el.attributes["data-" + name].value : null; });
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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

Related discussion:
text: {% endfor %} ></script> {# #} {% endif %} <del> <div id="rustdoc-vars" {#+ #} </del> <ins> <meta name="rustdoc-vars" {#+ #} </ins> data-root-path="{{page.root_path|safe}}" {#+ #} data-static-root-path="{{static_root_path|safe}}" {#+ #} data-current-crate="{{layout.krate}}" {#+ #}
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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

Related discussion:
text: data-theme-dark-css="{{files.theme_dark_css}}" {#+ #} data-theme-ayu-css="{{files.theme_ayu_css}}" {#+ #} > {# #} <del> </div> {# #} </del> <script src="{{static_root_path|safe}}{{files.storage_js}}"></script> {# #} {% if page.css_class.contains("crate") %} <script defer src="{{page.root_path|safe}}crates{{page.resource_suffix}}.js"></script> {# #}
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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

Related discussion:
text: // @has test.css // @has foo/struct.Foo.html <del> // @has - '//*[@id="rustdoc-vars"]/@data-themes' 'test' </del> <ins> // @has - '//*[@name="rustdoc-vars"]/@data-themes' 'test' </ins> pub struct Foo;
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- 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<summary<strongBacktrace</strong</summary<p</p</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

Related discussion:
text: <del> // check-pass trait A { type Assoc; } impl A for () { // FIXME: it would be nice for this to at least cause a warning. type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() {} </del>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- 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<summary<strongBacktrace</strong</summary<p</p</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

Related discussion:
text: <del> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` trait A { type Assoc: ?Sized; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { let x: Foo<()>; } </del>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- 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<summary<strongBacktrace</strong</summary<p</p</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

Related discussion:
text: <del> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-2.rs:11:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </del>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- 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<summary<strongBacktrace</strong</summary<p</p</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

Related discussion:
text: <ins> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` trait A { type Assoc: ?Sized; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { let x: Foo<()>; } </ins>