jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit e479ab26406ed8a473987e5f4a1f3be3e978e5d2 </del> <ins> Subproject commit dd94c7c5a32be2ee0adeeaf9d46f26f14925797c </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and -- nominating for prioritization.
Change:
} #[test] <del> #[allow(warnings)] // Have a symbol for the test below. It doesn’t need to be an actual variadic function, match the // ABI, or even point to an actual executable code, because the function itself is never invoked. #[no_mangle] </del> <ins> #[cfg(unix)] // printf may not be available on other platforms #[allow(deprecated)] // For SipHasher </ins> pub fn test_variadic_fnptr() { <ins> use core::ffi; </ins> use core::hash::{Hash, SipHasher}; extern "C" { <del> fn test_variadic_fnptr(_: u64, ...) -> f64; </del> <ins> // This needs to use the correct function signature even though it isn't called as some // codegen backends make it UB to declare a function with multiple conflicting signatures // (like LLVM) while others straight up return an error (like Cranelift). fn printf(_: *const ffi::c_char, ...) -> ffi::c_int; </ins> } <del> let p: unsafe extern "C" fn(u64, ...) -> f64 = test_variadic_fnptr; </del> <ins> let p: unsafe extern "C" fn(*const ffi::c_char, ...) -> ffi::c_int = printf; </ins> let q = p.clone(); assert_eq!(p, q); assert!(!(p < q));

Discussion:
This causes a crash when trying to test libcore with cgclif, as Cranelift doesn't allow incompatible definitions of the same function. While this currently works for cgllvm, according to it is likely to become forbidden with cg_llvm too.
modify labels:+A-cranelift
Change:
// the `enclosing_loops` field and let's coerce the // type of `expr_opt` into what is expected. let mut enclosing_breakables = self.enclosing_breakables.borrow_mut(); <del> let ctxt = enclosing_breakables.find_breakable(target_id); </del> <ins> let ctxt = match enclosing_breakables.opt_find_breakable(target_id) { Some(ctxt) => ctxt, None => { // Avoid ICE when `break` is inside a closure (#65383). self.tcx.sess.delay_span_bug( expr.span, "break was outside loop, but no error was emitted", ); return tcx.types.err; } }; </ins> if let Some(ref mut coerce) = ctxt.coerce { if let Some(ref e) = expr_opt { coerce.coerce(self, &cause, e, e_ty);

Discussion:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.
Change:
use super::{Custom, ErrorData, ErrorKind, SimpleMessage}; use alloc::boxed::Box; <ins> use core::marker::PhantomData; </ins> use core::mem::{align_of, size_of}; use core::ptr::NonNull;

Discussion:
<!-- 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: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- 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 -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.
Change:
return; } <del> // Display the available lint options if "-W help" or only "-W" is given. </del> let lint_flags = vec::append(matches.opt_strs("W"), matches.opt_strs("warn")); <del> let show_lint_options = lint_flags.iter().any(|x| x == &~"help") || (matches.opt_present("W") && lint_flags.is_empty()); if show_lint_options { </del> <ins> if lint_flags.iter().any(|x| x == &~"help") { </ins> describe_warnings(); return; }

Discussion:
is supposed to work like , and which can appear multiple times.
I believe this was broken in . Tagging and
The change was meant to improve usability, since there was no hint that "-W help" exists. It should be reverted then.
If passing it more than once becomes possible, the ability to pass comma-separated warnings should probably be removed. It's strange to have that for lints but not for .
How do you pass comma separated warnings?
Ah, it was removed...
Change:
<ins> #!/bin/bash set -euo pipefail IFS=$'nt' print_error() { echo "Error: `$1` is not a valid commit. To debug, run:" echo echo "    git rev-parse --verify $1" echo } full_sha() { git rev-parse  --verify  --quiet  "$1^{object}" || print_error $1 } commit_message_with_backport_note() { message=$(git log --format=%B -n 1 $1) echo $message | awk "NR==1{print; print "n(backport-of: $1)"} NR!=1" } cherry_pick_commit() { sha=$(full_sha $1) git cherry-pick $sha > /dev/null git commit  --amend  --file <(commit_message_with_backport_note $sha) } for arg ; do cherry_pick_commit $arg done </ins>

Discussion:
The 1.45.1 release is primarily being made because of the accidental omission of a rustfmt backport from the 1.45 beta branch after it landed in 1.44.1. The release team discussed this today, and we'd like to implement some automation to try and prevent this in the future at relatively low cost. The plan is to only allow landing commits in beta / stable branches if (or similar, but that seems like the right thing) indicates they've already landed in the preceding branches (beta and master for stable, just master for beta). We will also want an explicit set of commits that are just allowed. This will slightly increase the work needed during beta backports, as this list will need updating if there are any merge conflicts at least -- but since backports are rare and usually rollups, this shouldn't be much of a problem hopefully. We would be interested in seeing someone implement this functionality! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
}; } <ins> fn fold<B, F>(mut self, mut accum: B, mut f: F) -> B where F: FnMut(B, Self::Item) -> B, { if T::IS_ZST { while self.ptr.as_ptr() != self.end.cast_mut() { // SAFETY: we just checked that `self.ptr` is in bounds. let tmp = unsafe { self.ptr.read() }; // See `next` for why we subtract from `end` here. self.end = self.end.wrapping_byte_sub(1); accum = f(accum, tmp); } } else { // SAFETY: `self.end` can only be null if `T` is a ZST. while self.ptr != non_null!(self.end, T) { // SAFETY: we just checked that `self.ptr` is in bounds. let tmp = unsafe { self.ptr.read() }; // SAFETY: the maximum this can be is `self.end`. // Increment `self.ptr` first to avoid double dropping in the event of a panic. self.ptr = unsafe { self.ptr.add(1) }; accum = f(accum, tmp); } } accum } fn try_fold<B, F, R>(&mut self, mut accum: B, mut f: F) -> R where Self: Sized, F: FnMut(B, Self::Item) -> R, R: core::ops::Try<Output = B>, { if T::IS_ZST { while self.ptr.as_ptr() != self.end.cast_mut() { // SAFETY: we just checked that `self.ptr` is in bounds. let tmp = unsafe { self.ptr.read() }; // See `next` for why we subtract from `end` here. self.end = self.end.wrapping_byte_sub(1); accum = f(accum, tmp)?; } } else { // SAFETY: `self.end` can only be null if `T` is a ZST. while self.ptr != non_null!(self.end, T) { // SAFETY: we just checked that `self.ptr` is in bounds. let tmp = unsafe { self.ptr.read() }; // SAFETY: the maximum this can be is `self.end`. // Increment `self.ptr` first to avoid double dropping in the event of a panic. self.ptr = unsafe { self.ptr.add(1) }; accum = f(accum, tmp)?; } } R::from_output(accum) } </ins> unsafe fn __iterator_get_unchecked(&mut self, i: usize) -> Self::Item where Self: TrustedRandomAccessNoCoerce,

Discussion:
I tried this code: I expected to see this happen: Both and should get optimized to just return the input unchanged. Instead, this happened: unwrapcopy get's optimized as espected: unwrapclone fails to get optimized and compiles into a loop: Originally I thought that behavior was caused by the underlying type not implementing Copy but Drop seems to be the actual culprit. <!-- 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. --: </p</details
This reminds me of the do-nothing-loop from . That's not quite true, e.g. this also optimizes even though is not : So it's likely due to and the compiler fails to see that the drop can't happen.
Change:
``` "##, <ins> E0317: r##" This error occurs when an `if` expression without an `else` block is used in a context where a type other than `()` is expected, for example a `let` expression: ```compile_fail,E0317 fn main() { let x = 5; let a = if x == 5 { 1 }; } ``` An `if` expression without an `else` block has the type `()`, so this is a type error. To resolve it, add an `else` block having the same type as the `if` block. "##, </ins> E0398: r##" In Rust 1.3, the default object lifetime bounds are expected to change, as described in RFC #1156 [1]. You are getting a warning because the compiler

Discussion:
Here's my code (2.rs): On running , I get And gives Am I missing something? Shouldn't the explanation talk about ?
The error explanation was in . The code reporting contains the following note: And, from :
Change:
use std::iter::once; use std::ops::Range; <del> use rustc_errors::{Applicability, Handler}; </del> <ins> use rustc_errors::{pluralize, Applicability, Handler}; </ins> use rustc_lexer::unescape::{EscapeError, Mode}; use rustc_span::{BytePos, Span};

Discussion:
I tried to compile the following code (): For the avoidance of doubt, is . I expected the code to compile—but instead, the literal is rejected: Notably, it is accepted if unicode-escaped: :
The spade "character" in your code is not just a single U+2660, it also has a unicode variation selector U+FE0F: On my machine at least, this makes a visible difference in appearance (which github tries to eliminate by adding a U+FE0F unless I "escape" with a code block):
D'oh! Good spot, thanks Perhaps some improved diagnostics could have helped here?
We have similar diagnostics in other cases of misleading Unicode so that seems like a good idea.
Change:
assert!(self_ty.is_some()); } } else { <del> assert!(self_ty.is_none() && parent_substs.is_empty()); </del> <ins> assert!(self_ty.is_none()); </ins> } let arg_count = Self::check_generic_arg_count(

Discussion:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.
Change:
<ins> fn main() { ::foo() //~ cannot find external crate `foo` in the crate root } </ins>

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
} } <del> // Collapse a goto chain starting from `start` fn collapse_goto_chain(&mut self, start: &mut BasicBlock, changed: &mut bool) { let mut terminator = match self.basic_blocks[*start] { </del> <ins> /// This function will return `None` if /// * the block has statements /// * the block has a terminator other than `goto` /// * the block has no terminator (meaning some other part of the current optimization stole it) fn take_terminator_if_simple_goto(&mut self, bb: BasicBlock) -> Option<Terminator<'tcx>> { match self.basic_blocks[bb] { </ins> BasicBlockData { ref statements, terminator:

Discussion:
<!-- 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. --(also reproduced in beta and nightly) <!-- 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<pNo backtrace generated </p</details
This is already fixed on nightly, I just tried it locally. Can you confirm?
Installed nightly last night but to double check:
Hmm... must be apple specific. Do you have a gdb handy that you could run on that last rustc invocation to obtain a stack trace?
Having problems getting it working, not normally a debugger person (been years since I've run gdb) and not much of a Mac person (work computer). I installed for nightly and I get Then when I run, I get
hmm... not sure what our gdb capabilities on mac are. I'll try to find someone who's building rustc on macs. Thanks for the attempt!
I'm looking into producing a build locally.
backtrace:
Looks like my CI saw a stack overflow on Windows as well
lol I recently (two days ago) looked at and went "oh this could stack overflow, why is this not a loop". I'll (try to) fix this without inserting more stacker invocations
Change:
) )] #[doc(alias = "?")] <ins> #[cfg_attr(not(bootstrap), lang = "try")] </ins> pub trait Try { /// The type of this value when viewed as successful. #[unstable(feature = "try_trait", issue = "42327")]

Discussion:
<!-- 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. --The rustc compiler panics for being unable to check the type of an object. In the example, it's shown in the form of returning an Option, and being unable to take Option as a parameter type. This would be the expected compilation error for that snippet of code, but instead of that, the compiler just panics. This error only occurs on asynchronous functions and in nightly. It also only happens when not compiling with --release, only in debug. <!-- 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</details
cc (likely due to - )
I can see why that could cause it. I've also seen that could be caused due to a similar issue. If it's the same issue, this issue should be kept as it provides a smaller example to reproduce and extra information in reproducing.
oh, sorry, my bad, investigating.
Kind of strange, this ice only triggered with , won't ice. here is a mcve: ICE: no-ICE:

<!-- 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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.
Change:
<ins> //@ check-pass #![recursion_limit = "5"] #![allow(unused)] #![deny(improper_ctypes)] #[repr(C)] struct F1(*const ()); #[repr(C)] struct F2(*const ()); #[repr(C)] struct F3(*const ()); #[repr(C)] struct F4(*const ()); #[repr(C)] struct F5(*const ()); #[repr(C)] struct F6(*const ()); #[repr(C)] struct B { f1: F1, f2: F2, f3: F3, f4: F4, f5: F5, f6: F6, } extern "C" fn foo(_: B) {} fn main() {} </ins>

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
// @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;

Discussion:
<!-- 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.
Change:
/// - If the true value's magnitude is ≥ `f32::MAX` + 2<sup>(`f32::MAX_EXP` − ///   `f32::MANTISSA_DIGITS` − 1)</sup>, the result is ∞ or −∞ (preserving the ///   true value's sign). <ins> /// - If the result of a sum exactly equals zero, the outcome is +0.0 unless ///   both arguments were negative, then it is -0.0. Subtraction `a - b` is ///   regarded as a sum `a + (-b)`. </ins> /// /// For more information on floating point numbers, see [Wikipedia][wikipedia]. ///

Discussion:
The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.
Change:
return false; }; if let Some(local_sig_id) = sig_id.as_local() { <del> self.resolver.delegation_fn_sigs[&local_sig_id].has_self </del> <ins> // The value may be missing due to recursive delegation. // Error will be emmited later during HIR ty lowering. self.resolver.delegation_fn_sigs.get(&local_sig_id).map_or(false, |sig| sig.has_self) </ins> } else { match self.tcx.def_kind(sig_id) { DefKind::Fn => false,

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
cc
Change:
<ins> use crate::base::ExtCtxt; </ins> use crate::expand::{AstFragment, AstFragmentKind}; use rustc_ast as ast;

Discussion:
<!-- 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. --Context: "regression" caught by future-proofing CI from After working on reducing the code, I've identified the root cause of the ICE. For context: this patterns stem from "old" Rust code wanting to support proc-macros emitting item definitions in "statement" position for Rust: the trick is to use the to wrap an item-defs-emitting proc-macro call inside a function so that Rust doesn't interpret it as a statement, refusing the then-unstable stmt-emitting proc-macro call (). <!-- 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. --: Bonus: the ICE seems to have been introduced in between today's () and yesterday's nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I suspect this is up your alley
searched nightlies: from nightly-2021-08-01 to nightly-2021-08-10 regressed nightly: nightly-2021-08-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +A-macros
Thanks nice job