jiebi/CodeConvo huggingface dataset:
Change:
This is a minimal reproduction of something I saw when updating some of my projects to use . This manifested in other ways in larger programs, ICEing in one case: This can be reproduced by taking and changing lines 592 and 598 of to use partial type hints. cc
Maybe partial type hints need feature gating.
I knew that feature was too easy to implement... Lets see if I can find the cause.
Well, I'm not sure how to fix this. This inference error implies to me that partial type hints actually don't work at all for the case right now, and the existing tests didn't catch it because they inferred right from both sides. According to this is because the in and don't have any direct constrain to be identical. (Which would be possible with HKT though) While there is a , this link is apparently not currently considered, leading to the inference failure here. cc
Any idea why there are so many stacks in the backtrace? Does a non- build not contain enough debug info for libbacktrace to work off of?
I expect that there would be other ways of hitting these same inference bugs.
This is working on 0.12 and master: I'm sure one of PR that got merged in the last two months fixed inference from partial hints. Not sure which one though. I think this should be closed. (Unless someone got another test case that fails to infer from partial hints)
:dancer: I've been meaning to look into why this doesn't work. Happy to not have to.

Discussion:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Common {} impl<'t, T> Common for (T, &'t T) {} impl<'t, T> Common for (&'t T, T) {} fn main() {} </ins>

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::collections::HashMap; fn copy<T: Copy>(&x: &T) -> T { x } fn main() { let arr = [(1i, 1u), (2, 2), (3, 3)]; let v1: Vec<&_> = arr.iter().collect(); let v2: Vec<_> = arr.iter().map(copy).collect(); let m1: HashMap<_, _> = arr.iter().map(copy).collect(); let m2: HashMap<int, _> = arr.iter().map(copy).collect(); let m3: HashMap<_, uint> = arr.iter().map(copy).collect(); } </ins>
Change:
It appears to me that the build is broken on os x lion 10.7.2 (with xcode 4.1 (4B110)) gcc -v
also

Discussion:
local DOC="$*" if [ $HELP -eq 0 ] then <del> local UOP=$(echo $OP | tr 'a-z-' 'A-Z_') </del> <ins> local UOP=$(echo $OP | tr '[:lower:]' '[:upper:]' | tr '-' '_') </ins> local V="CFG_${UOP}" eval $V="$DEFAULT" for arg in $CFG_CONFIGURE_ARGS

CFG_PREFIX=/usr/local fi <ins> if [ -z "$CFG_HOST_TRIPLE" ] then CFG_HOST_TRIPLE="$DEFAULT_HOST_TRIPLE" fi </ins> if [ -z "$CFG_TARGET_TRIPLES" ] then CFG_TARGET_TRIPLES="${CFG_HOST_TRIPLE}"
Change:
In the past, the default tools=[...] in included Miri. The default of building Miri was removed at and The latter is called “Do not build Miri by default”, and as it changes 1211 files obviously I do not follow what exactly it does. In any case, as in rustc-1.80.1-[build] # tools = [ "cargo", "clippy", "rustdoc", "rustfmt", "rust-analyzer", "rust-analyzer-proc-macro-srv", "analysis", "src", "rust-demangler", # if profiler = true] does not include miri, my understanding is that and should produce identical result (except for rust-analyzer-proc-macro-srv). But the first does lead to installing Miri, while the second skips installing Miri. As my observation is that now Miri is built by default (is part of the implicit tools=[…]), in tools= should indclude miri. To be precise the first ./configure I ran against rustc-1.79.0- and the second against rustc-1.80.1-
That PR shipped with Rust 1.66 so I'm not sure why you are linking it when you seem to be intending to report a change from Rust 1.79 to Rust 1.80.
I am not reporting a changbe between 1.79 and 1.80. I am saying that old Rust versions built Miri by default (miri was in the implicit tools=[]), then it was removed from tools=[], and now miri is again in the implicit tools=[], but not in [...]
The latter is called "Make miri a subtree instead of a submodule", which should give you an idea of why it changes so many files. ;) Cc ; I don't know if this was a deliberate change or not or how the implicit "tools" array is even computed. Miri is a nightly-only tool so we probably do not want it to be built implicitly on stable.
For dev/nightly channels, we simply build every tool by default: If channel isn't dev/nightly, we only build tools are are marked as and (although cargo-miri is) Miri isn't one of them.
Okay so if the sample is supposed to show the default it should show both of these, presumably?
Done that in ()

Discussion:
#    "analysis", #    "src", #    "wasm-component-ld", <ins> #    "miri", "cargo-miri" # for dev/nightly channels </ins> #] # Verbosity level: 0 == not verbose, 1 == verbose, 2 == very verbose, 3 == print environment variables on each rustc invocation

CargoClippy, "src/tools/clippy", "cargo-clippy", stable=true; Clippy, "src/tools/clippy", "clippy-driver", stable=true, add_bins_to_sysroot = ["clippy-driver", "cargo-clippy"]; Miri, "src/tools/miri", "miri", stable=false, add_bins_to_sysroot = ["miri"]; <del> CargoMiri, "src/tools/miri/cargo-miri", "cargo-miri", stable=true, add_bins_to_sysroot = ["cargo-miri"]; </del> <ins> CargoMiri, "src/tools/miri/cargo-miri", "cargo-miri", stable=false, add_bins_to_sysroot = ["cargo-miri"]; </ins> Rls, "src/tools/rls", "rls", stable=true; Rustfmt, "src/tools/rustfmt", "rustfmt", stable=true, add_bins_to_sysroot = ["rustfmt", "cargo-fmt"]; );
Change:
On native Windows:
This looks sus: That's a which is an absolute Unix path. On Windows it will be interpreted relative to the root of the current directory. For example, if your current directory is then it'll be . (Also it'd be nice to use raw strings here because the is confusing in the context of paths)

Discussion:
test(parse(""), None); { <del> let build_dir = if cfg!(windows) { Some("C:tmp") } else { Some("/tmp") }; test(parse("build.build-dir = "/tmp""), build_dir); </del> <ins> let build_dir = if cfg!(windows) { "C:tmp" } else { "/tmp" }; test(parse(&format!("build.build-dir = '{build_dir}'")), Some(build_dir)); </ins> } }
Change:
Multiple targets currently use to implement conversion from a Duration to a value in microseconds. However, currently reads as so: Up. Note this which means is not a valid implementation of this spec. Note that this is not the only problem that espidf poses with respect to its std implementation: :
First found on espidf: cc
Same bug: cc
Agreed - problem is clear and I'll fix shortly - thanks for noticing! An interesting question here is whether it is allowed - in - to busy-wait for sleeping? Because this is exactly what would happen on the ESP IDF . Given that the documentation is silent in this regard, I suggest to keep the current behavior (i.e. busy-waiting for durations < 10ms) as that allows callers of to "at least do some sleep - busy-looping or not". I don't think this is a problem on the ESP IDF, . Or processes thereof.
Yes, I believe busy-waiting is a valid implementation of sleep, and especially in particular, if we were to have a hypothetical that returned if the platform didn't have an actual syscall for sleeping for that long, I would expect busy-waiting to be on the other side of the if/else almost every single time.

Discussion:
#[inline] pub fn sleep(dur: Duration) { <ins> let micros = dur.as_micros() + if dur.subsec_nanos() % 1_000 > 0 { 1 } else { 0 }; let micros = u64::try_from(micros).unwrap_or(u64::MAX); </ins> unsafe { <del> hermit_abi::usleep(dur.as_micros() as u64); </del> <ins> hermit_abi::usleep(micros); </ins> } }
Change:
Test case:
Stability is fixed now, just needs links.
Triage: no src link on methods as of today.
We have [src] for impls now. Is that enough?
Did this just land? I can’t find these links in Is it only trait impls on inherent as well? In any case it’s an improvement, but some blocks are very large and source links on individual methods would still be useful in my opinion.
yep, it was merged recently: and works for both kinds of impls. It should be visible in the nightly docs already. There appear to be some problems with linking to impls pulled from to , I planned to investigate if that's fixable later.
I've opened to fix this.

Discussion:
write!(w, "<code>")?; render_assoc_item(w, item, link.anchor(&id), ItemType::Impl)?; write!(w, "</code>")?; <del> render_stability_since_raw(w, item.stable_since(), outer_version)?; </del> <ins> if let Some(l) = (Item { cx, item }).src_href() { write!(w, "</span><span class='out-of-band'>")?; write!(w, "<div class='ghost'></div>")?; render_stability_since_raw(w, item.stable_since(), outer_version)?; write!(w, "<a class='srclink' href='{}' title='{}'>[src]</a>", l, "goto source code")?; } else { render_stability_since_raw(w, item.stable_since(), outer_version)?; } </ins> write!(w, "</span></h4>n")?; } }

font-size: 21px; } <ins> h4.method > .out-of-band { font-size: 19px; } </ins> h4 > code, h3 > code, .invisible > code { position: inherit; }
Change:
On an non-English system the run-make test fails because it searches a english "needle" but may print it in another language. Putting in my environment variable makes use it's default (English) language. We should probably do that for all the run-make tests.
... good catch. I love C locale.
In the compiler we set and before calling linker because we inspect linker output sometimes. That said, isn't the plan to migrate operations like this from third-party tools to library calls to something like ?
It is. However, my current plan is to prioritize first getting rid of and trimming down external bin tools and deps where possible (some of them are first moved to llvm bintools which are at least batched together with llvm). It's non-trivial to match readelf/readobj etc. when they have various combination of flags, and when reviewing I found out that libraries like have differences in its interpretation of symbols (i.e. they don't match cleanly 1-to-1). Getting rid of first of all means that we can run the run-make tests outside of msys2 msys lol. I'm going to do a second pass after first getting rid of , and revisit things like: External bin tools. Tests that require bootstrap cargo and then internet connection to run the test (the target sanity check tests). TL;DR: yes, eventually.

Discussion:
} env::join_paths(paths.iter()).unwrap() }); <ins> cmd.env("LC_ALL", "C"); // force english locale </ins> if is_windows() { let mut paths = vec![];

pub fn cmd<S: AsRef<OsStr>>(program: S) -> Command { let mut command = Command::new(program); set_host_rpath(&mut command); <ins> command.env("LC_ALL", "C"); // force english locale </ins> command }
Change:
I have my master branch set up to track the master branch of my fork (mainly because i don't want to accidentally pull in every git tag into my shallow clone), so doesn't updated when i run (presumably the remote was created by ? i don't remember creating it, and lots of code needs it (or another branch pointing to this repo) to work). as it turns out, uses the state of to determine if a file has been modified. so instead of it formatting every file that i modified, it formats every file anyone has modified in the last few months. at no point did anything warn me that i need to be updating a remote i didn't add. it should probably do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this could be addressed by checking the timestamp on .git/refs/remotes/upstream/master and warning if it is very old
claim
I ran into a similar issue where was building llvm from source instead of using the prebuilt ci version due to an outdated branch. Would it make sense to solve both issues in one go?
should be pretty easy, just call the same warning method for both build steps maybe it should be used for all build steps?

Discussion:
if !verify_rustfmt_version(build) { return Ok(None); } get_git_modified_files(&build.config.git_config(), Some(&build.config.src), &["rs"]) }

use std::path::PathBuf; use std::{env, fs}; <ins> use build_helper::git::warn_old_master_branch; </ins> #[cfg(not(feature = "bootstrap-self-test"))] use crate::builder::Builder; use crate::builder::Kind;

if let Some(ref s) = build.config.ccache { cmd_finder.must_have(s); } <ins> // this warning is useless in CI, // and CI probably won't have the right branches anyway. if !build_helper::ci::CiEnv::is_ci() { if let Err(e) = warn_old_master_branch(&build.config.git_config(), &build.config.src) .map_err(|e| e.to_string()) { eprintln!("unable to check if upstream branch is old: {e}"); } } </ins> }

.collect(); Ok(Some(files)) } <ins> /// Print a warning if the branch returned from `updated_master_branch` is old /// /// For certain configurations of git repository, this remote will not be /// updated when running `git pull`. /// /// This can result in formatting thousands of files instead of a dozen, /// so we should warn the user something is wrong. pub fn warn_old_master_branch( config: &GitConfig<'_>, git_dir: &Path, ) -> Result<(), Box<dyn std::error::Error>> { use std::time::Duration; const WARN_AFTER: Duration = Duration::from_secs(60 * 60 * 24 * 10); let updated_master = updated_master_branch(config, Some(git_dir))?; let branch_path = git_dir.join(".git/refs/remotes").join(&updated_master); match std::fs::metadata(branch_path) { Ok(meta) => { if meta.modified()?.elapsed()? > WARN_AFTER { eprintln!("warning: {updated_master} has not been updated in 10 days"); } else { return Ok(()); } } Err(err) => { eprintln!("warning: unable to check if {updated_master} is old due to error: {err}") } } eprintln!( "warning: {updated_master} is used to determine if files have been modifiedn warning: if it is not updated, this may cause files to be needlessly reformatted" ); Ok(()) } </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details

Discussion:
/// Returns `true` if `def_id` refers to a definition that does not have its own /// type-checking context, i.e. closure, coroutine or inline const. pub fn is_typeck_child(self, def_id: DefId) -> bool { <del> matches!(self.def_kind(def_id), DefKind::Closure | DefKind::InlineConst) </del> <ins> matches!( self.def_kind(def_id), DefKind::Closure | DefKind::InlineConst | DefKind::SyntheticCoroutineBody ) </ins> } /// Returns `true` if `def_id` refers to a trait (i.e., `trait Foo { ... }`).

<ins> //@ aux-build:block-on.rs //@ edition: 2021 //@ build-pass //@ compile-flags: -Cdebuginfo=2 #![feature(async_closure)] extern crate block_on; async fn call_once(f: impl async FnOnce()) { f().await; } pub fn main() { block_on::block_on(async { let async_closure = async move || {}; call_once(async_closure).await; }); } </ins>
Change:
Originally posted at and filing this upon request from . We're using nightly rust and as of nightly-2024-08-29 (prior to this it compiled fine) we see the following error: Function being flagged can be viewed at . We're having a bit of a hard time debugging this issue, it's not very clear what this actually means. I've tried looking at the HIR output but it didn't really help and I'm a bit lost on this one as I'm not familiar with MIR. I expected to see this happen: Compilation succeed. Instead, this happened: Compilation failed due to MIR cycle. : Backtrace contained no extra information.
this kind of looks like it should be an ICE instead? :thinking:
I'll try to put up a fix. It's due to (not that you need to understand what that PR does), not your fault.
For now, though, you'll need to either stop using closures (since you've got an bound, not ; why are you using closures over just , since those don't really buy you anything in this case?) or pin your nightly compiler version until I can minimize this and fix it.
Minimized: To reproduce: (Odd that the "optimization" also happens in debug builds.) Of note: During the minimization process, rust-analyzer froze multiple times. And a few times, also froze.
you're awesome! thanks for the minimization.
Thanks for confirming. We were having a lot of issues with lifetimes when using the async blocks which lead to us using async closures instead. Possibly we should just revisit that...
You might be interested in these two links for an explanation on how exactly async closures differ from a closure that returns an async block: https://rust-
Thanks I'll take a look at those.

Discussion:
//! Validates the MIR to ensure that invariants are upheld. use rustc_data_structures::fx::{FxHashMap, FxHashSet}; <ins> use rustc_hir as hir; </ins> use rustc_hir::LangItem; use rustc_index::bit_set::BitSet; use rustc_index::IndexVec;

// since we may be in the process of computing this MIR in the // first place. let layout = if def_id == self.caller_body.source.def_id() { <del> // FIXME: This is not right for async closures. </del> <ins> self.caller_body.coroutine_layout_raw() } else if let Some(hir::CoroutineKind::Desugared( _, hir::CoroutineSource::Closure, )) = self.tcx.coroutine_kind(def_id) && let ty::ClosureKind::FnOnce = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap() && self.caller_body.source.def_id() == self.tcx.coroutine_by_move_body_def_id(def_id) { // Same if this is the by-move body of a coroutine-closure. </ins> self.caller_body.coroutine_layout_raw() } else { self.tcx.coroutine_layout(def_id, args.as_coroutine().kind_ty())

<ins> //@ check-pass //@ edition: 2021 #![feature(async_closure)] // Make sure that we don't hit a query cycle when validating // the by-move coroutine body for an async closure. use std::future::Future; async fn test<Fut: Future>(operation: impl Fn() -> Fut) { operation().await; } pub async fn orchestrate_simple_crud() { test(async || async {}.await).await; } fn main() {} </ins>
Change:
When using I see which seems like an indicator that something is broken. I think LLVM is seeing a mismatch between and the lack of a in But of course I don't know this target, or whether this is somehow a bug in LLVM. cc
Thanks for your report, I'll submit a fix soon, the support (include libstd/libc) for NuttX is in early stage, there are still many issues at present, sorry for that
No need to apologize, just saying something because I saw something :)

Discussion:
os: "nuttx".into(), linker_flavor: LinkerFlavor::Gnu(Cc::No, Lld::Yes), linker: Some("rust-lld".into()), <del> llvm_abiname: "lp64d".into(), </del> cpu: "generic-rv64".into(), max_atomic_width: Some(64), features: "+m,+a,+c".into(),
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 --
cc
I found the bug claim

Discussion:
// we must create two defs. let coroutine_def = self.create_def(coroutine_kind.closure_id(), kw::Empty, DefKind::Closure, span); <del> self.with_parent(coroutine_def, |this| visit::walk_expr(this, body)); </del> <ins> self.with_parent(coroutine_def, |this| this.visit_expr(body)); </ins> } _ => visit::walk_fn(self, fn_kind), }

<ins> //@ edition: 2021 //@ check-pass #![feature(async_closure)] // Make sure we don't ICE if an async closure has a macro body. // This happened because we were calling walk instead of visit // in the def collector, oops! fn main() { let _ = async || println!(); } </ins>
Change:
Unfortunately I don't have a minimal reproducible example, just a reproducible example. On MacOS Ventura 13.5 on an Apple M2 processor, the following steps reproduce it: Said steps cause to exit with a SIGTRAP signal, unfortunately all the way at the end of compilation. The above SIGTRAP is a regression, it occurs with in , as well as with , but not with . I have not bisected it further. The error does not occur when using instead of . The difference between these two is the profile selected, uses the debug profile whereas uses the following profile: I've tagged this issue as an 'internal compiler error', even though it does not panic but actually SIGTRAPs. I thus don't have a Rust backtrace, but I did attach to before the sigtrap occurred and got the following backtrace: <details<summary<strongBacktrace</strong</summary<p</p</details
As this is on M2, can you please take a look?
Reduced: If this reduction is too aggressive, I'll try again tomorrow. :)
Upstream issue:
Fixed in LLVM 19 (Probably the next backport). label +llvm-fixed-upstream
Even though this is basically-already-fixed, we need to figure out if this is on the 1.82 beta (it has to be, right?)
Wait, I can just do math. Yes, it is.
I cannot reproduce this because this requires the nightly version, but the regression has included in 1.82 beta. I would expect to integrate the final 19.1.0 version of LLVM to rustc 1.82, although this contains many changes.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah, we'll backport at least the 19.1.0 release to the beta branch, possibly also a later point release if needed.
It's not super important but the regression looks to be from .
then reverting that PR is also an option, but I will of course defer to you on exactly what gets backported, just wanted to make sure this was tagged appropriately so we didn't lose track. :^)

Discussion:
<del> Subproject commit 2b259b3c201f939f2ed8d2fb0a0e9b37dd2d1321 </del> <ins> Subproject commit 4b8d29c585687084bbcf21471e04f279d1eddc0a </ins>