jiebi/CodeConvo huggingface dataset:
Change:
This seems to have started recently; going back to before fixes the problem.
Cc any idea what might be happening here? Not everyone sees this behavior, strangely.
Looks like , and probably needs the same fix. Something is lying about the exit status of rustc.
Cc who seems to be (or has been) getting similar errors
hm, but this code seems to forward the exist status correctly
One possible issue is that anyhow does not seem to propagate (set via the TARGET env var) to . (This would likely also make it fail in Miri cross-interpretation.) The bootstrap binary to determine whether to use the bootstrap sysroot or the sysroot matching the target build.
IOW, is missing.
Not sure what's going on in this case sadly :/ I had this issue because of a bug in rustc-perf but I haven't seen it show up outside of that context.
I can confirm that the issue is fixed by applying
I am pretty sure this was caused by after that PR, the build probe of anyhow fails to build with latest libstd. It still works with the bootstrap compiler's libstd though, which is why anyhow thinks it can use the backtrace feature, but actually can't. (EDIT: and now I see has already linked to that PR. oops) eyre has exactly the same problem:

Discussion:
[[package]] name = "anyhow" <del> version = "1.0.51" </del> <ins> version = "1.0.60" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "8b26702f315f53b6071259e15dd9d64528213b44d61de1ec926eca7715d62203" </del> <ins> checksum = "c794e162a5eff65c72ef524dfe393eb923c354e350bb78b9c7383df13f3bc142" </ins> [[package]] name = "array_tool"
Change:
In its help, rustdoc says I can use " -vec" to search by type signature. But when I actually run exactly that search query, rustdoc Cc
Hmm, I think it uses the syntax instead (though we've discussed switching to , which I prefer). I'll open a PR. cc
Yeah works. This looks like a fairly recent regression, .
It could be that the old query parser just ignored the . A new one was implemented recently that's strict about syntax.

Discussion:
<code>enum</code>, <code>trait</code>, <code>type</code>, <code>macro</code>,  and <code>const</code>.", "Search functions by type signature (e.g., <code>vec -&gt; usize</code> or  <del> <code>* -&gt; vec</code>)", </del> <ins> <code>-&gt; vec</code>)", </ins> "Search multiple things at once by splitting your query with comma (e.g.,  <code>str,u8</code> or <code>String,struct:Vec,test</code>)", "You can look for items with an exact name by putting double quotes around
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 --
claim
On a side note this is valid and compiles:
Yeah, this is very likely due to expr either not being recorded correctly when type-checking , or those not being used correctly when building MIR for . I will look into this later.
Minimized this a tiny bit: Still working on it though. Unrelated to try-blocks.

Discussion:
// This place is not really used because this destination place // should never be used to take values at the end of the failure // block. <del> let dummy_place = Place { local: RETURN_PLACE, projection: ty::List::empty() }; </del> <ins> let dummy_place = self.temp(self.tcx.types.never, else_block.span); </ins> let failure_block; unpack!( failure_block = self.ast_block(

<ins> // edition:2021 // check-pass #![feature(try_blocks)] #![feature(let_else)] fn main() { let _: Result<i32, i32> = try { let Some(x) = Some(0) else { Err(1)? }; x }; } </ins>
Change:
running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls

Discussion:
} // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

<ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </ins>
Change:
I ran and got this panic, although the rustfmt output had already been printed: Notably after running , the panic stops (and doesn't panic either). But reintroducing something where rustfmt will suggest changes brings the panic in back. See previous discussion at . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from only exits the process when run from the main thread.
The fix is to use instead.
claim
So, to be clear, the fix is to replace the detail::exit with process::exit right?
no - within detailexit, change resumeunwind to process::exit

Discussion:
/// If code is not 0 (successful exit status), exit status is 101 (rust's default error code.) /// If the test is running and code is an error code, it will cause a panic. fn detail_exit(code: i32) -> ! { <del> // Successful exit if code == 0 { std::process::exit(0); } if cfg!(test) { </del> <ins> // if in test and code is an error code, panic with staus code provided if cfg!(test) && code != 0 { </ins> panic!("status code: {}", code); } else { <del> std::panic::resume_unwind(Box::new(code)); </del> <ins> //otherwise,exit with provided status code std::process::exit(code); </ins> } }
Change:
When downloading a tarball ( from ) and building it with file with , the build fails early with: I have this behaviour in beta since 2022-08-09, and with nightly since 2022-06-25. My file is: rustc and cargo binaries are 1.62.1-stable. The build is done on OpenBSD (but as it is failing at first cargo invocation, I think it is OS agnostic).
Which directory are you invoking from? Is it the source directory or somewhere else? I think the necessary for vendoring to work may be missed if you invoke it from another directory than the source directory. cc
is invoked from outside the source directory. I will check that
ok, I confirm that invoking from inside the source directory solves the problem. now I need to use and to keep my original behavior to build outside the source directory, but it isn't a big deal. it might be something to mention in changelog file. I think it is common in downstream dsitribution to use a different build and source directories. thanks for the help
I think we should support building outside the source directory again.
fixed a bunch of these issues - can you try with a tarball from the latest nightly and see if it's fixed there?
That PR only changes the rust code of rustbuild, not the python code. This issue is while compiling rustbuild. The problem is that is not in the current working directory when compiling rustbuild and as such ignored.
I confirm that the latest nightly doesn't build outside the directory. also, please note that currently the problem is in both beta and nightly channels.
Ah, I see. That seems possible to fix, we can run the command from the source root. The working directory of the build itself shouldn't affect any of the runtime configuration.

Discussion:
elif color == "never": args.append("--color=never") <del> run(args, env=env, verbose=self.verbose) </del> <ins> # Run this from the source directory so cargo finds .cargo/config run(args, env=env, verbose=self.verbose, cwd=self.rust_root) </ins> def build_triple(self): """Build triple as in LLVM

) -> Cargo { let mut cargo = Command::new(&self.initial_cargo); let out_dir = self.stage_out(compiler, mode); <ins> // Run cargo from the source root so it can find .cargo/config. // This matters when using vendoring and the working directory is outside the repository. cargo.current_dir(&self.src); </ins> // Codegen backends are not yet tracked by -Zbinary-dep-depinfo, // so we need to explicitly clear out if they've been updated.
Change:
Link to : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
It was probably regressed by , cc
label F-let-else

Discussion:
if let Some(els) = els { self.nbsp(); self.word_space("else"); <ins> // containing cbox, will be closed by print-block at `}` self.cbox(0); // head-box, will be closed by print-block after `{` self.ibox(0); </ins> self.print_block(els); }

<ins> // compile-flags: -Zunpretty=hir // check-pass #![feature(let_else)] fn foo(x: Option<u32>) { let Some(_) = x else { panic!() }; } fn main() {} </ins>

<ins> // compile-flags: -Zunpretty=hir // check-pass #![feature(let_else)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; fn foo(x: Option<u32>) { let Some(_) = x else { { ::std::rt::begin_panic("explicit panic") } }; } fn main() { } </ins>
Change:
As of current nightly rustc 1.65.0-nightly ( 2022-08-10): : Mentioning erstwhile tracking issue Mentioning in connection with .
"encountered unmarked API" &mdash; maybe it's that there is no #[stable] attribute on the enum variants, like there is in other stable enums? I'd have expected that to be caught during the libstd build, so we should fix whatever was supposed to catch it, not just add the attributes.
Indeed, I didn't realize that enum variants also needed stable attributes.

Discussion:
pub enum BacktraceStatus { /// Capturing a backtrace is not supported, likely because it's not /// implemented for the current platform. <ins> #[stable(feature = "backtrace", since = "1.65.0")] </ins> Unsupported, /// Capturing a backtrace has been disabled through either the /// `RUST_LIB_BACKTRACE` or `RUST_BACKTRACE` environment variables. <ins> #[stable(feature = "backtrace", since = "1.65.0")] </ins> Disabled, /// A backtrace has been captured and the `Backtrace` should print /// reasonable information when rendered. <ins> #[stable(feature = "backtrace", since = "1.65.0")] </ins> Captured, }
Change:
As of current nightly rustc 1.65.0-nightly ( 2022-08-10): : Mentioning erstwhile tracking issue Mentioning in connection with .
"encountered unmarked API" &mdash; maybe it's that there is no #[stable] attribute on the enum variants, like there is in other stable enums? I'd have expected that to be caught during the libstd build, so we should fix whatever was supposed to catch it, not just add the attributes.
Indeed, I didn't realize that enum variants also needed stable attributes.

Discussion:
AnnotationKind::Required, InheritDeprecation::Yes, InheritConstStability::No, <del> InheritStability::No, </del> <ins> InheritStability::Yes, </ins> |_| {}, ); }

fn visit_variant(&mut self, var: &'tcx Variant<'tcx>) { self.check_missing_stability(self.tcx.hir().local_def_id(var.id), var.span); <ins> if let Some(ctor_hir_id) = var.data.ctor_hir_id() { self.check_missing_stability(self.tcx.hir().local_def_id(ctor_hir_id), var.span); } </ins> intravisit::walk_variant(self, var); }

<ins> #![crate_type = "lib"] #![feature(staged_api)] #![stable(feature = "none", since = "1.0")] #[stable(feature = "none", since = "1.0")] pub enum Foo { A, } </ins>

<ins> // aux-build:ctor-stability.rs // check-pass extern crate ctor_stability; fn main() { let _ = ctor_stability::Foo::A; } </ins>
Change:
Example: . This was fixed by adding stability attributes (), but the general problem remains that was able to land. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Found the bug. PR incoming. claim

Discussion:
AnnotationKind::Required, InheritDeprecation::Yes, InheritConstStability::No, <del> InheritStability::No, </del> <ins> InheritStability::Yes, </ins> |_| {}, ); }

fn visit_variant(&mut self, var: &'tcx Variant<'tcx>) { self.check_missing_stability(self.tcx.hir().local_def_id(var.id), var.span); <ins> if let Some(ctor_hir_id) = var.data.ctor_hir_id() { self.check_missing_stability(self.tcx.hir().local_def_id(ctor_hir_id), var.span); } </ins> intravisit::walk_variant(self, var); }

<ins> #![crate_type = "lib"] #![feature(staged_api)] #![stable(feature = "none", since = "1.0")] #[stable(feature = "none", since = "1.0")] pub enum Foo { A, } </ins>

<ins> // aux-build:ctor-stability.rs // check-pass extern crate ctor_stability; fn main() { let _ = ctor_stability::Foo::A; } </ins>
Change:
I tried this code with (, ; minimized and modified from 's ): I expected to see this happen: Successful compilation Instead, this happened: Compiler hangup <!-- 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. --: <details<summaryBacktrace</summary<pCaptured by a command in GDB:  </p</details
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Discussion:
use rustc_middle::ty::subst::Subst; use rustc_middle::ty::{self, ConstKind, Instance, InstanceDef, ParamEnv, Ty, TyCtxt}; use rustc_session::config::OptLevel; <ins> use rustc_span::def_id::DefId; </ins> use rustc_span::{hygiene::ExpnKind, ExpnData, LocalExpnId, Span}; use rustc_target::spec::abi::Abi;

param_env: ParamEnv<'tcx>, /// Caller codegen attributes. codegen_fn_attrs: &'tcx CodegenFnAttrs, <del> /// Stack of inlined Instances. history: Vec<ty::Instance<'tcx>>, </del> <ins> /// Stack of inlined instances. /// We only check the `DefId` and not the substs because we want to /// avoid inlining cases of polymorphic recursion. /// The number of `DefId`s is finite, so checking history is enough /// to ensure that we do not loop endlessly while inlining. history: Vec<DefId>, </ins> /// Indicates that the caller body has been modified. changed: bool, }

Ok(new_blocks) => { debug!("inlined {}", callsite.callee); self.changed = true; <del> self.history.push(callsite.callee); </del> <ins> self.history.push(callsite.callee.def_id()); </ins> self.process_blocks(caller_body, new_blocks); self.history.pop(); }

return None; } <del> if self.history.contains(&callee) { </del> <ins> if self.history.contains(&callee.def_id()) { </ins> return None; }

<ins> // Make sure that the MIR inliner does not loop indefinitely on polymorphic recursion. // compile-flags: --crate-type lib // Randomize `def_path_hash` by defining them under a module with different names macro_rules! emit { ($($m:ident)*) => {$( pub mod $m { pub trait Tr { type Next: Tr; } pub fn hoge<const N: usize, T: Tr>() { inner::<N, T>(); } #[inline(always)] fn inner<const N: usize, T: Tr>() { inner::<N, T::Next>(); inner::<N, T::Next>(); } } )*}; } // Increase the chance of triggering the bug emit!(m00 m01 m02 m03 m04 m05 m06 m07 m08 m09 m10 m11 m12 m13 m14 m15 m16 m17 m18 m19); </ins>
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. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?

Discussion:
- [Extend `ptr::null` and `null_mut` to all thin (including extern) types.][94954] - [`impl Read and Write for VecDeque<u8>`.][95632] - [STD support for the Nintendo 3DS.][95897] <ins> - [Use rounding in float to Duration conversion methods.][96051] </ins> - [Make write/print macros eagerly drop temporaries.][96455] - [Implement internal traits that enable `[OsStr]::join`.][96881] - [Implement `Hash` for `core::alloc::Layout`.][97034]

- [`#[link]` attributes are now checked more strictly,][96885] which may introduce errors for invalid attribute arguments that were previously ignored. <ins> - [Rounding is now used when converting a float to a `Duration`.][96051] The converted duration can differ slightly from what it was. </ins> Internal Changes ----------------

[95818]: https://github.com/rust-lang/rust/pull/95818/ [95897]: https://github.com/rust-lang/rust/pull/95897/ [95953]: https://github.com/rust-lang/rust/pull/95953/ <ins> [96051]: https://github.com/rust-lang/rust/pull/96051/ </ins> [96296]: https://github.com/rust-lang/rust/pull/96296/ [96455]: https://github.com/rust-lang/rust/pull/96455/ [96737]: https://github.com/rust-lang/rust/pull/96737/
Change:
Unfortunately I don't have a minimal reproduction for this () is the state of the repo at the time where it happened. <!-- 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 FWIW appears to work fine, but only causes the ICE
I can reproduce getting an ICE with
I’ve started some reduction work: (edit: there’s a full MCVE below; this fork will be deleted eventually) Interestingly, this reduced example’s ICE looks slightly different, I just noticed: <details<summary…click to show full output…</summary</details
Minimized: label -E-needs-mcve +S-bug-has-mcve <details<summaryfull reproduction instructions (e.g. if someone wants to add this to glacier), and backtrace</summaryin Then do Backtrace </details

Discussion:
<ins> // revisions: rpass1 rpass2 pub fn foo() { bar(); baz::<()>(); } fn bar() where <() as Table>::AllColumns:, { } fn baz<W>() where W: AsQuery, <W as AsQuery>::Query:, { } trait AsQuery { type Query; } trait UnimplementedTrait {} impl<T> AsQuery for T where T: UnimplementedTrait, { type Query = (); } struct Wrapper<Expr>(Expr); impl<Ret> AsQuery for Wrapper<Ret> { type Query = (); } impl AsQuery for () where Wrapper<<() as Table>::AllColumns>: AsQuery, { type Query = (); } trait Table { type AllColumns; } #[cfg(rpass1)] impl Table for () { type AllColumns = Checksum1; } #[cfg(rpass1)] struct Checksum1; #[cfg(rpass2)] impl Table for () { type AllColumns = Checksum2; } #[cfg(rpass2)] struct Checksum2; fn main() {} </ins>
Change:
Found via and extract into the root dir and run with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly
modify labels: +E-needs-mcve
Same ICE can also be reproduced with which crater also found
The tzdb ice is the same issue, it also used on enum fields: Could you rename the issue? modify labels: -E-needs-mcve
Thanks for the MCVE! I'm planning to work on it tomorrow if no one did until then.

Discussion:
Tuple(fields) => Variant::Tuple( fields .into_iter() <del> .map(|f| { if let clean::StructFieldItem(ty) = *f.kind { ty.into_tcx(tcx) } else { unreachable!() } </del> <ins> .filter_map(|f| match *f.kind { clean::StructFieldItem(ty) => Some(ty.into_tcx(tcx)), clean::StrippedItem(_) => None, _ => unreachable!(), </ins> }) .collect(), ),

<ins> // Regression test for <https://github.com/rust-lang/rust/issues/100529>. #![no_core] #![feature(no_core)] // @has enum_variant_hidden.json "$.index[*][?(@.name=='ParseError')]" // @has - "$.index[*][?(@.name=='UnexpectedEndTag')]" // @is - "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_kind" '"tuple"' // @is - "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_inner" [] pub enum ParseError { UnexpectedEndTag(#[doc(hidden)] u32), } </ins>
Change:
On , with a provided component: errors with: I'll try and see if I can reproduce it with to test suggestion:
Couldn't reproduce it with an , tried with also Does it have to be cross compiled from a different host?
Not sure what is necessary to reproduce it. In any case if you open a PR with the likely fix, I can run a try build on CI which you can then locally install to see if it fixes the issue.

Discussion:
fn main() { let args = env::args_os().skip(1).collect::<Vec<_>>(); <ins> let arg = |name| args.windows(2).find(|args| args[0] == name).and_then(|args| args[1].to_str()); </ins> // Detect whether or not we're a build script depending on whether --target // is passed (a bit janky...) <del> let target = args.windows(2).find(|w| &*w[0] == "--target").and_then(|w| w[1].to_str()); </del> <ins> let target = arg("--target"); </ins> let version = args.iter().find(|w| &**w == "-vV"); let verbose = match env::var("RUSTC_VERBOSE") {

cmd.args(&args).env(dylib_path_var(), env::join_paths(&dylib_path).unwrap()); // Get the name of the crate we're compiling, if any. <del> let crate_name = args.windows(2).find(|args| args[0] == "--crate-name").and_then(|args| args[1].to_str()); </del> <ins> let crate_name = arg("--crate-name"); </ins> if let Some(crate_name) = crate_name { if let Some(target) = env::var_os("RUSTC_TIME") {

{ cmd.arg("-C").arg("panic=abort"); } <ins> // `-Ztls-model=initial-exec` must not be applied to proc-macros, see // issue https://github.com/rust-lang/rust/issues/100530 if env::var("RUSTC_TLS_MODEL_INITIAL_EXEC").is_ok() && arg("--crate-type") != Some("proc-macro") && !matches!(crate_name, Some("proc_macro2" | "quote" | "syn" | "synstructure")) { cmd.arg("-Ztls-model=initial-exec"); } </ins> } else { // FIXME(rust-lang/cargo#5754) we shouldn't be using special env vars // here, but rather Cargo should know what flags to pass rustc itself.

// so we can't use it by default in general, but we can use it for tools // and our own internal libraries. if !mode.must_support_dlopen() && !target.triple.starts_with("powerpc-") { <del> rustflags.arg("-Ztls-model=initial-exec"); </del> <ins> cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); </ins> } if self.config.incremental {