jiebi/CodeConvo huggingface dataset:
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 code: I expected to see this happen: The code should compile. Instead, this happened: This compiler error is thrown: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: (also works on stable 1.54). Starting from , I get the error shown above. <!-- Provide the version you are using that has the regression. --: current nightly Also broken on 1.55 beta 7: Both installed via rustup. <!-- Did the compiler crash? If so, please provide a backtrace. --n/a <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --This seems similar to , which was fixed in / (which AFAIU should be included in ), but it still does not work.
Bisected to cc
the root cause is: if one place captured by more than 2 locations, the will be overrided by the last one in : In this case, is captured by at line 7 and at line 8, the captureinfo supercedes the previous .
Thank you for this!

Discussion:
}; capture_info.capture_kind = capture_kind; <ins> let capture_info = if let Some(existing) = processed.get(&place) { determine_capture_info(*existing, capture_info) } else { capture_info }; </ins> processed.insert(place, capture_info); }

<ins> // edition:2021 // run-pass fn solve<F>(validate: F) -> Option<u64> where F: Fn(&mut [i8; 1]), { let mut position: [i8; 1] = [1]; Some(0).map(|_| { validate(&mut position); let [_x] = position; 0 }) } fn main() { solve(|_| ()); } </ins>
Change:
My guess is that the yellow inline code style is incorrectly being applied to code blocks too. ! !
cc since you're knowledgeable about rustdoc's CSS
I'll send a fix shortly.
looks to be the likely cause. searched nightlies: from nightly-2021-07-01 to nightly-2021-08-25 regressed nightly: nightly-2021-08-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details

Discussion:
.code-header { color: #e6e1cf; } <del> pre > code { </del> <ins> .docblock pre > code, pre > code { </ins> color: #e6e1cf; } span code {

<del> // The ayu theme has a different color for the "<code>" tags in the doc blocks. We need to // check that the rule isn't applied on other "<code>" elements. goto: file://|DOC_PATH|/test_docs/enum.AnEnum.html // We need to show the text, otherwise the colors aren't "computed" by the web browser. show-text: true // We set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload to get the text appearing and the theme applied. reload: assert-css: (".docblock code", {"color": "rgb(255, 180, 84)"}, ALL) // It includes variants and the "titles" as well (for example: "impl RefUnwindSafe for AnEnum"). assert-css: ("div:not(.docblock) > code", {"color": "rgb(197, 197, 197)"}, ALL) </del>

<ins> // The ayu theme has a different color for the "<code>" tags in the doc blocks. We need to // check that the rule isn't applied on other "<code>" elements. // // While we're at it, we also check it for the other themes. goto: file://|DOC_PATH|/test_docs/fn.foo.html // If the text isn't displayed, the browser doesn't compute color style correctly... show-text: true // Set the theme to dark. local-storage: {"rustdoc-theme": "dark", "rustdoc-preferred-dark-theme": "dark", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: (".docblock pre > code", {"color": "rgb(221, 221, 221)"}, ALL) assert-css: (".docblock > p > code", {"color": "rgb(221, 221, 221)"}, ALL) // Set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: (".docblock pre > code", {"color": "rgb(230, 225, 207)"}, ALL) assert-css: (".docblock > p > code", {"color": "rgb(255, 180, 84)"}, ALL) // Set the theme to light. local-storage: {"rustdoc-theme": "light", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: (".docblock pre > code", {"color": "rgb(0, 0, 0)"}, ALL) assert-css: (".docblock > p > code", {"color": "rgb(0, 0, 0)"}, ALL) </ins>

/// ```ignore (it's a test) /// Let's say I'm just some text will ya? /// ``` <ins> /// /// An inlined `code`! </ins> pub fn foo() {} /// Just a normal struct.
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 code: I expected to see this happen: is hidden from the documentation. Instead, this happened: is shown in the documentation and has its own page. Private declarative macros are also shown. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: rustc 1.56.0-nightly ( 2021-08-14) <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged +A-macros +A-visibility +T-rustdoc --
modify labels +requires-nightly
Thanks for filing this issue! This regression was almost certainly introduced in . I'm looking into it.
Assigning priority as in the prioritization working group. label: +P-high -I-prioritize
Thanks

Discussion:
| clean::UnionItem(..) | clean::AssocConstItem(..) | clean::TraitAliasItem(..) <ins> | clean::MacroItem(..) </ins> | clean::ForeignTypeItem => { if i.def_id.is_local() { if !self.access_levels.is_exported(i.def_id.expect_def_id()) {

clean::ImplItem(..) => {} <del> // tymethods/macros have no control over privacy clean::MacroItem(..) | clean::TyMethodItem(..) => {} </del> <ins> // tymethods have no control over privacy clean::TyMethodItem(..) => {} </ins> // Proc-macros are always public clean::ProcMacroItem(..) => {}

<ins> // Checks that private macros aren't documented by default. They // should be still be documented in `--document-private-items` mode, // but that's tested in `macro-document-private.rs`. // // // This is a regression text for issue #88453. #![feature(decl_macro)] // @!has macro_private_not_documented/index.html 'a_macro' // @!has macro_private_not_documented/macro.a_macro.html macro_rules! a_macro { () => () } // @!has macro_private_not_documented/index.html 'another_macro' // @!has macro_private_not_documented/macro.another_macro.html macro another_macro { () => () } </ins>
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!

Discussion:
dependencies = [ "cargo_metadata 0.12.0", "clippy_lints", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.6.0", </ins> "derive-new", "filetime", "quote",

] [[package]] <ins> name = "compiletest_rs" version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "64698e5e2435db061a85e6320af12c30c5fd88eb84b35d2c1e03ce4f143255ca" dependencies = [ "diff", "filetime", "getopts", "lazy_static", "libc", "log", "miow", "regex", "rustfix 0.5.1", "serde", "serde_derive", "serde_json", "tempfile", "tester", "winapi", ] [[package]] </ins> name = "core" version = "0.0.0" dependencies = [

version = "0.1.0" dependencies = [ "colored", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.7.0", </ins> "env_logger 0.8.1", "getrandom 0.2.0", "hex 0.4.2",

<del> Subproject commit 09cadcbb62a3529801d0463d9878db3f0b5060c7 </del> <ins> Subproject commit 7a2f1cadcd5120c44eda3596053de767cd8173a2 </ins>
Change:
The following macro generates a function with 4096 entries in the tuple. () It’s explicitly a stack overflow on stable and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety. label I-crash, T-compiler
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Digged a bit, this is indeed a stack overflow. Since rustc uses stacker, if we moved to a segemented stack instead of the native stack, std didn't know this is a stack overflow and so it appears as segfault instead. The root cause is that uses recursion.

Discussion:
use rustc_data_structures::captures::Captures; use rustc_arena::TypedArena; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_hir::def_id::DefId; use rustc_hir::HirId; use rustc_middle::ty::{self, Ty, TyCtxt};

// We try each or-pattern branch in turn. let mut matrix = matrix.clone(); for v in v.expand_or_pat() { <del> let usefulness = is_useful(cx, &matrix, &v, witness_preference, hir_id, is_under_guard, false); </del> <ins> let usefulness = ensure_sufficient_stack(|| { is_useful(cx, &matrix, &v, witness_preference, hir_id, is_under_guard, false) }); </ins> ret.extend(usefulness); // If pattern has a guard don't add it to the matrix. if !is_under_guard {

// We cache the result of `Fields::wildcards` because it is used a lot. let spec_matrix = start_matrix.specialize_constructor(pcx, &ctor); let v = v.pop_head_constructor(cx, &ctor); <del> let usefulness = is_useful(cx, &spec_matrix, &v, witness_preference, hir_id, is_under_guard, false); </del> <ins> let usefulness = ensure_sufficient_stack(|| { is_useful(cx, &spec_matrix, &v, witness_preference, hir_id, is_under_guard, false) }); </ins> let usefulness = usefulness.apply_constructor(pcx, start_matrix, &ctor); // When all the conditions are met we have a match with a `non_exhaustive` enum

<ins> // check-pass: this used to be a stack overflow because of recursion in `usefulness.rs` macro_rules! long_tuple_arg { ([$($t:tt)*]#$($h:tt)*) => { long_tuple_arg!{[$($t)*$($t)*]$($h)*} }; ([$([$t:tt $y:tt])*]) => { pub fn _f(($($t,)*): ($($y,)*)) {} } } long_tuple_arg!{[[_ u8]]########## ###} fn main() {} </ins>
Change:
Interestingly, the dark theme works fine. Screenshot of Ayu: ! cc
Sending a fix in the next few hours.

Discussion:
.env("RUSTDOC", builder.rustdoc(self.compiler)) .env("RUSTC", builder.rustc(self.compiler)) .current_dir(path); <ins> // FIXME: implement a `// compile-flags` command or similar //        instead of hard-coding this test if entry.file_name() == "link_to_definition" { cargo.env("RUSTDOCFLAGS", "-Zunstable-options --generate-link-to-definition"); } </ins> builder.run(&mut cargo); } }

color: #c5c5c5; } body.source .example-wrap pre.rust a { <del> background: #c5c5c5; </del> <ins> background: #333; </ins> } .docblock:not(.type-decl) a:not(.srclink):not(.test-arrow),

<ins> // We check the background color on the jump to definition links in the source code page. goto: file://|DOC_PATH|/src/link_to_definition/lib.rs.html // Set the theme to dark. local-storage: {"rustdoc-theme": "dark", "rustdoc-preferred-dark-theme": "dark", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: ("body.source .example-wrap pre.rust a", {"background-color": "rgb(51, 51, 51)"}, ALL) // Set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: ("body.source .example-wrap pre.rust a", {"background-color": "rgb(51, 51, 51)"}, ALL) // Set the theme to light. local-storage: {"rustdoc-theme": "light", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: ("body.source .example-wrap pre.rust a", {"background-color": "rgb(238, 238, 238)"}, ALL) </ins>

<ins> # This file is automatically @generated by Cargo. # It is not intended for manual editing. version = 3 [[package]] name = "link_to_definition" version = "0.1.0" </ins>

<ins> [package] name = "link_to_definition" version = "0.1.0" edition = "2018" [lib] path = "lib.rs" </ins>

<ins> pub struct Bar { pub a: String, pub b: u32, } pub fn foo(_b: &Bar) {} </ins>
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. --Looks a bit like <!-- 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 --
Used as feature and got this: Regressed somewhere between ... <details<summaryBefore</summary</details<details<summaryAfter</summary</details
claim

Discussion:
get_slice_bytes(&tcx, a_val) == get_slice_bytes(&tcx, b_val) } <ins> (ConstValue::ByRef { alloc: alloc_a, .. }, ConstValue::ByRef { alloc: alloc_b, .. }) if a.ty.is_ref() || b.ty.is_ref() => { if a.ty.is_ref() && b.ty.is_ref() { alloc_a == alloc_b } else { false } } </ins> (ConstValue::ByRef { .. }, ConstValue::ByRef { .. }) => { let a_destructured = tcx.destructure_const(relation.param_env().and(a)); let b_destructured = tcx.destructure_const(relation.param_env().and(b));

<ins> // check-pass #![feature(fn_traits)] #![feature(adt_const_params)] //~^ WARNING the feature `adt_const_params` is incomplete #[derive(PartialEq, Eq)] struct CompileTimeSettings{ hooks: &'static[fn()], } struct Foo<const T: CompileTimeSettings>; impl<const T: CompileTimeSettings> Foo<T> { fn call_hooks(){ } } fn main(){ const SETTINGS: CompileTimeSettings = CompileTimeSettings{ hooks: &[], }; Foo::<SETTINGS>::call_hooks(); } </ins>

<ins> warning: the feature `adt_const_params` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/refs_check_const_eq-issue-88384.rs:4:12 | LL | #![feature(adt_const_params)] |            ^^^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information warning: 1 warning emitted </ins>

<ins> // check-pass #![allow(incomplete_features)] #![feature(adt_const_params)] struct FooConst<const ARRAY: &'static [&'static str]> {} const FOO_ARR: &[&'static str; 2] = &["Hello", "Friend"]; fn main() { let _ = FooConst::<FOO_ARR> {}; } </ins>
Change:
The documentation for the / function reads and gives this example (and the analogous example for ): Since lengths are always positive, it's unclear what this function does for negative values. My expectation is that it gives the hypotenuse of the right triangle whose leg lengths are the absolute values of and , but I had to look up to be sure, which reads <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This looks relatively simple, and I'd like to contribute. Could I take this issue?
claim

Discussion:
unsafe { cmath::cbrtf(self) } } <del> /// Calculates the length of the hypotenuse of a right-angle triangle given /// legs of length `x` and `y`. </del> <ins> /// Compute the distance between the origin and a point (`x`, `y`) on the /// Euclidean plane. Equivalently, compute the length of the hypotenuse of a /// right-angle triangle with other sides having length `x.abs()` and /// `y.abs()`. </ins> /// /// # Examples ///

unsafe { cmath::cbrt(self) } } <del> /// Calculates the length of the hypotenuse of a right-angle triangle given /// legs of length `x` and `y`. </del> <ins> /// Compute the distance between the origin and a point (`x`, `y`) on the /// Euclidean plane. Equivalently, compute the length of the hypotenuse of a /// right-angle triangle with other sides having length `x.abs()` and /// `y.abs()`. </ins> /// /// # Examples ///
Change:
Found by 1.56 crater -- https://crater- cc
Fixed by . Sorry for taking over, but since I started looking into it already.
Still needs a backport
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
fixed by

Discussion:
impl<'tcx> MirPass<'tcx> for RemoveZsts { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { <ins> // Avoid query cycles (generators require optimized MIR for layout). if tcx.type_of(body.source.def_id()).is_generator() { return; } </ins> let param_env = tcx.param_env(body.source.def_id()); let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut(); for block in basic_blocks.iter_mut() {

<ins> // Regression test for #88972. Used to cause a query cycle: //   optimized mir -> remove zsts -> layout of a generator -> optimized mir. // // edition:2018 // compile-flags: --crate-type=lib // build-pass pub async fn listen() -> Result<(), std::io::Error> { let f = do_async(); std::mem::forget(f); Ok(()) } pub async fn do_async() { listen().await.unwrap() } </ins>
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. --: Also tested on the playground: . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels: +A-const-generics +F-genericconstexprs +requires-nightly

Discussion:
// Getting this wrong can lead to ICE and unsoundness, so we assert it here. for arg in substs.iter() { let allowed_flags = ty::TypeFlags::MAY_NEED_DEFAULT_CONST_SUBSTS <del> | ty::TypeFlags::STILL_FURTHER_SPECIALIZABLE; </del> <ins> | ty::TypeFlags::STILL_FURTHER_SPECIALIZABLE | ty::TypeFlags::HAS_ERROR; </ins> assert!(!arg.has_type_flags(!allowed_flags)); } substs

<ins> #![allow(incomplete_features)] #![feature(generic_const_exprs)] struct ConstAssert<const COND: bool>; trait True {} impl True for ConstAssert<true> {} struct Range<T: PartialOrd, const MIN: T, const MAX: T>(T) //~^ ERROR the type of const parameters must not depend on other generic parameters //~| ERROR the type of const parameters must not depend on other generic parameters where ConstAssert<{ MIN <= MAX }>: True; fn main() {} </ins>

<ins> error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/issue-88997.rs:8:40 | LL | struct Range<T: PartialOrd, const MIN: T, const MAX: T>(T) |                                        ^ the type must not depend on the parameter `T` error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/issue-88997.rs:8:54 | LL | struct Range<T: PartialOrd, const MIN: T, const MAX: T>(T) |                                                      ^ the type must not depend on the parameter `T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0770`. </ins>

<ins> #![feature(generic_const_exprs)] #![allow(incomplete_features)] pub struct Foo<T, const H: T>(T) //~^ ERROR the type of const parameters must not depend on other generic parameters where [(); 1]:; fn main() {} </ins>

<ins> error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/issue-90364.rs:4:28 | LL | pub struct Foo<T, const H: T>(T) |                            ^ the type must not depend on the parameter `T` error: aborting due to previous error For more information about this error, try `rustc --explain E0770`. </ins>
Change:
I'm trying to build the compiler for the first time, following the instructions at https://rustc-dev- One of: documentation at https://rustc-dev- explaining how to install , or documentation at https://rustc-dev- saying to set in the section of , or to be installed automatically by , or to be set automatically by default by ; and a solution for the error.
Here's the backtrace:
Adding an section with to in the root does not appear to make any difference:
The next thing I tried was to uninstall and install , which resulted in this error instead:
You can set if you don't want to play with llvm.
I do want to potentially play with (especially, instrument) llvm. Removing the section, doing and running again fixed it. ( gave me a hint that this might be useful thing to try, since was under the directory.) I also installed the Debian package; I don't know whether that was necessary/relevant.
Yes, this is what fixed it - I don't know what the cargo package you installed is, but the Debian package is the one rustbuild expects. Hmm, I would rather have bootstrap tell you that directly when it gives an error that ninja isn't found, that seems more helpful (and easier to keep up to date). Are you interested in making a PR for that? :)
The error checking for this lives in
Yes I can make a PR for that.
describes how to install ninja packages on a variety of platforms, so I'll have the error message link to that.
One thing I'm confused about is that adding to was not sufficient to fix the problem originally. I would have expected that to work regardless of whether ninja was installed.
I tried reproducing it. Without ninja installed there's a proper warning message. Editing then makes things build with gnu make . Imo the main thing that could use improvement is to autodetect whether ninja is available or not and set that flag automatically. Unless we want to encourage the use of ninja by default for fast builds.
Yes, it's intentionally semi-required to encourage it's use, as it gives a much better experience (though these days most people are not building LLVM, I hope).

Discussion:
{ eprintln!( " <del> Couldn't find required command: ninja You should install ninja, or set `ninja=false` in config.toml in the `[llvm]` section. </del> <ins> Couldn't find required command: ninja (or ninja-build) You should install ninja as described at <https://github.com/ninja-build/ninja/wiki/Pre-built-Ninja-packages>, or set `ninja = false` in the `[llvm]` section of `config.toml`. Alternatively, set `download-ci-llvm = true` in that `[llvm]` section to download LLVM rather than building it. </ins> " ); std::process::exit(1);