jiebi/CodeConvo huggingface dataset:
Change:
.or_insert_with(|| (ln, var, vec![id_and_sp])); }); <ins> let can_remove = matches!(&pat.kind, hir::PatKind::Struct(_, _, true)); </ins> for (_, (ln, var, hir_ids_and_spans)) in vars { if self.used_on_entry(ln, var) { let id = hir_ids_and_spans[0].0;

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
pub(crate) fn ty_args_to_args<'tcx>( cx: &mut DocContext<'tcx>, args: ty::Binder<'tcx, &'tcx [ty::GenericArg<'tcx>]>, <del> mut skip_first: bool, </del> <ins> has_self: bool, </ins> container: Option<DefId>, ) -> Vec<GenericArg> { <ins> let mut skip_first = has_self; </ins> let mut ret_val = Vec::with_capacity(args.skip_binder().len().saturating_sub(if skip_first { 1 } else { 0 }));

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. --I found out about the ICE when my crate could not have its documentation online on (). I managed to narrow it down to the code below. All of the code here builds fine (, ), but on the latest stable and nightly it fails when doing . Originally, came from a separate crate, . To my surprise, using the dependency instead of replicating the symbols to this crate results in a more informative top-level error message of the ICE. With we can instead do: The full project can also be found in . Reproduced on more than one toolchain and platform, among which: Without the dependency: with the dependency : <!-- 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 --
this went build -ice in Regression in
is , cc author:
claim
Minimized: label S-has-mcve A-cross-crate-reexports
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Keeping it open until the fix is backported to beta.
The fix has been backported to beta () and to stable (). Closing.
Change:
<ins> error[E0046]: not all trait items implemented, missing: `Ty` --> $DIR/issue-110161.rs:11:1 | LL |     type Ty; |     ------- `Ty` from trait ... LL | impl LtTrait for () { | ^^^^^^^^^^^^^^^^^^^ missing `Ty` in implementation error: aborting due to previous error For more information about this error, try `rustc --explain E0046`. </ins>

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. --<!-- 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 --
See also , but while only reproduces with rustdoc, this one only repros with rustc and not rustdoc :thinking:
searched nightlies: from nightly-2023-01-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim I'll have a go at this, no idea if I'll be able to do it.
This is an ICE on invalid code. label regression-from-stable-to-nightly Minimized: this can be fixed by replacing the assertion with and returning early to avoid processing unconstrained lifetime variables in implied bounds. It would be nice if we have a comment referring to this issue or to the ui test for why delaying a bug was necessary.
btw, you should update your cargo-bisect-rustc to make it bisect the contents of rollups as well.
It is, unfortunately the regression is old enough that perf artifacts are gone :(
It's not old, but I remember now, this was my cursed rollup that didn't get unrolled perf builds. It also was a perf regression which made it pretty annoying :D
Change:
Ok(true) } <del> fn constructor_covered_by_range(ctor: &Constructor, from: &ConstVal, to: &ConstVal, end: RangeEnd, ty: Ty) -> Result<bool, ErrorReported> { </del> <ins> fn constructor_covered_by_range<'a, 'tcx>( tcx: TyCtxt<'a, 'tcx, 'tcx>, ctor: &Constructor, from: &ConstVal, to: &ConstVal, end: RangeEnd, ty: Ty<'tcx>, ) -> Result<bool, ErrorReported> { </ins> trace!("constructor_covered_by_range {:#?}, {:#?}, {:#?}, {}", ctor, from, to, ty); <del> let cmp_from = |c_from| compare_const_vals(c_from, from, ty) </del> <ins> let cmp_from = |c_from| compare_const_vals(tcx, c_from, from, ty) </ins> .map(|res| res != Ordering::Less); <del> let cmp_to = |c_to| compare_const_vals(c_to, to, ty); </del> <ins> let cmp_to = |c_to| compare_const_vals(tcx, c_to, to, ty); </ins> macro_rules! some_or_ok { ($e:expr) => { match $e {

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
/// Shortens the deque, keeping the first `len` elements and dropping /// the rest. /// <del> /// If `len` is greater than the deque's current length, this has no /// effect. </del> <ins> /// If `len` is greater or equal to the deque's current length, this has /// no effect. </ins> /// /// # Examples ///

Discussion:
The documentation currently says But it also doesn't have an effect if the two lengths are equal, so I think it should say "greater or equal to the vector's current length". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yes, there is a trivial difference between and , but it's an internal implementation issue, I think we should update the doc since they are same from the user's view.
claim
Change:
<ins> // aux-build:meow.rs extern crate meow; use meow::Meow; fn needs_meow<T: Meow>(t: T) {} fn main() { needs_meow(1usize); //~^ ERROR the trait bound `usize: Meow` is not satisfied } struct LocalMeow; impl Meow for LocalMeow {} </ins>

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
hir::def::CtorKind::Const => unreachable!(), }; <ins> // Suggest constructor as deep into the block tree as possible. // This fixes https://github.com/rust-lang/rust/issues/101065, // and also just helps make the most minimal suggestions. let mut expr = expr; while let hir::ExprKind::Block(block, _) = &expr.kind && let Some(expr_) = &block.expr { expr = expr_ } </ins> vec![ (expr.span.shrink_to_lo(), format!("{prefix}{variant}{open}")), (expr.span.shrink_to_hi(), close.to_owned()),

Discussion:
rustc version: rustc 1.65.0-nightly ( 2022-08-25) I have a very small reproducer for a weird fix advice from rustc when the two branches of an if had a type mismatch: This will produce the following output: Applying this fix obviously doesn't help:
label +A-diagnostics +T-compiler +D-invalid-suggestion
Change:
<ins> error: incompatible link kind for `u8::MIN` --> $DIR/incompatible-primitive-disambiguator.rs:2:6 | LL | //! [static@u8::MIN] |      ^^^^^^^^^^^^^^ help: to link to the associated constant, prefix with `const@`: `const@u8::MIN` | note: the lint level is defined here --> $DIR/incompatible-primitive-disambiguator.rs:1:9 | LL | #![deny(broken_intra_doc_links)] |         ^^^^^^^^^^^^^^^^^^^^^^ = note: this link resolved to an associated constant, which is not a static error: aborting due to previous error </ins>

Discussion:
I tried this code: I expected to see this happen: Rustdoc links to Instead, this happened: Rustdoc gets confused that means a function and thinks that the link is a primitive. <!-- 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. --: Relevant code: I think the fix is just to add as a match guard. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is blocking and made unnecessarily difficult.
claim
which arm do you mean to add the match guard to?
the one for telling if the resolved item is a primitive:
It looks like is in fact for
Oh hmm - the issue is that for primitives, rustdoc generates the anchor manually: I would try storing the of the associated item in instead, so you know later whether the anchor is a manual link () or whether it was generated by rustdoc.
Adding in here and adding the match guard seems to fix things, but also feels like a hack.
I mean, all of is a hack because other parts of rustdoc break when you store the associated item instead: If you can figure out a way to get rid of it, I'd love to do that, but it will require some pretty major refactors I think.
Change:
self.s.space(); } self.cbox(indent_unit); <ins> self.ann.pre(self, AnnNode::Arm(arm)); </ins> self.ibox(0); self.print_outer_attributes(&arm.attrs); let mut first = true;

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
} ``` <del> To fix this error, you need to pass variables corresponding to C types as much as possible. For better explanations, see The Rust Book: https://doc.rust-lang.org/book/ </del> <ins> Certain Rust types must be cast before passing them to a variadic function, because of arcane ABI rules dictated by the C standard. To fix the error, cast the value to the type specified by the error message (which you may need to import from `std::os::raw`). </ins> "##, E0618: r##"

Discussion:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker
Change:
"core", "dlmalloc", "fortanix-sgx-abi", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "hermit-abi 0.3.2", "libc", "miniz_oxide",

Discussion:
I tried this code: I expected to see this happen: map = {1: "a"} Instead, error happened: Sometimes it causes Segmentation fault: <!-- 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<summaryBacktrace</summary<p</p</details
Miri reports UB with the target in question: (sorry for reflexively blaming LLVM, it didn't deserve that)
The root cause is that the stdarch SIMD intrinsics are broken on big-endian targets. For now I've disabled the use of NEON in hashbrown on big-endian ARM: We should probably disable/de-stabilize the NEON intrinsics on big-endian targets. They are currently all producing incorrect results.
All of them, or specifically for ARM? (Not sure if we have stdarch support for any other big-endian target.) Is there an issue tracking that and explaining in a bit more detail how they are broken?
This only applies to arm & aarch64 targets. Here is the issue in stdarch:
Miri doesn't support the NEON SIMD intrinsics though. So if Miri reports UB then it seems there are other problems as well?
Some are implemented using the same intrinsics as portable-simd.
It's a combination of a few things: We are missing a check for the NEON implementation. All the NEON intrinsics we happen to use in hashbrown are implemented without LLVM builtins.
Ah so I guess what happens is that Miri correctly implements the portable SIMD intrinsics, but stdarch implements the NEON intrinsics on top of them and it's doing that incorrectly? Miri and codegen/LLVM are fine?
Yes, that's my understanding.
Change:
<ins> // Copyright 2018 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. #![feature(generators)] fn main() { static || { loop { // Test that `opt` is not live across the yield, even when borrowed in a loop // See https://github.com/rust-lang/rust/issues/52792 let opt = { yield; true }; &opt; } }; } </ins>

Discussion:
cc
cc
I'm hitting this a lot at the moment-- any idea what the cause might be? I'd love to help get this resolved.
I'm sometimes able to fix it by moving conditions that out of the body of an expression.
It also seems to have regressed between and -- updating the compiler caused this to happen in more places.
Possibly related to ? cc
Trying to fix in more places and it looks like it's always related to temporaries-- if I make it and then use in the place I was using it usually solves the issue.
Smaller example: ()
cc this is blocking roll out of async/await in Fuchsia
Looked at this and pointed out that it looks like typechecking thinks that isn't live at the point (which is correct) but that MIR thinks it is live (which is incorrect). I tried searching through the diff to see if there were any related PRs, but so far the only thing I've found that touches MIR is , which seems like it shouldn't be related.
Is working on bisecting this.
I think the problem is that is borrowed by and because of this the generator transformation only uses and statements to calculate liveness. However we generate a statement for before its initialiser which contains the statement. So appears live during the statement, even though its storage isn't used for anything.
Bisection pointed to as the PR that made this worse (more code ICEs now), although the minimal test case still fails before and after. cc
minimal repro: This ICE only surfaces after
using instead of makes the ICE "go away"
Ah you need at the very least to use and initializations, not . AFAIK the type of a variable could be dead at a (lifetimes not ready yet). Arguably you could also have the time before moving out and a reinitialization also count as dead, e.g. doesn't really need to keep alive.
Change:
fn __rust_alloc_error_handler(size: usize, align: usize) -> !; } <del> /// Abort on memory allocation error or failure. </del> <ins> /// Signal a memory allocation error. </ins> /// <del> /// Callers of memory allocation APIs wishing to abort computation </del> <ins> /// Callers of memory allocation APIs wishing to cease execution </ins> /// in response to an allocation error are encouraged to call this function, <del> /// rather than directly invoking `panic!` or similar. </del> <ins> /// rather than directly invoking [`panic!`] or similar. </ins> /// <del> /// The default behavior of this function is to print a message to standard error /// and abort the process. /// It can be replaced with [`set_alloc_error_hook`] and [`take_alloc_error_hook`]. </del> <ins> /// This function is guaranteed to diverge (not return normally with a value), but depending on /// global configuration, it may either panic (resulting in unwinding or aborting as per /// configuration for all panics), or abort the process (with no unwinding). /// /// The default behavior is: /// ///  * If the binary links against `std` (typically the case), then ///   print a message to standard error and abort the process. ///   This behavior can be replaced with [`set_alloc_error_hook`] and [`take_alloc_error_hook`]. ///   Future versions of Rust may panic by default instead. /// /// * If the binary does not link against `std` (all of its crates are marked ///   [`#![no_std]`][no_std]), then call [`panic!`] with a message. ///   [The panic handler] applies as to any panic. </ins> /// /// [`set_alloc_error_hook`]: ../../std/alloc/fn.set_alloc_error_hook.html /// [`take_alloc_error_hook`]: ../../std/alloc/fn.take_alloc_error_hook.html <ins> /// [The panic handler]: https://doc.rust-lang.org/reference/runtime.html#the-panic_handler-attribute /// [no_std]: https://doc.rust-lang.org/reference/names/preludes.html#the-no_std-attribute </ins> #[stable(feature = "global_alloc", since = "1.28.0")] #[rustc_const_unstable(feature = "const_alloc_error", issue = "92523")] #[cfg(all(not(no_global_oom_handling), not(test)))]

Discussion:
's documentation says: However, is also specified to call the hook set with (unstable) which per its example is permitted to panic and thereby potentially unwind, and , a “likely” future version of might choose to panic on allocation failure instead. Therefore, the documentation should be changed to not imply that this function will always abort, which could be taken as a promise that it will never unwind. It also might be useful to expand the documentation of so that the text and not only the example code specifies that it's okay to unwind from the hook (and what happens if you don't). (See also which is broader but doesn't mention this aspect.) cc from label +A-allocators +T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
} let tail = self.tail; self.tail = wrap_index(self.tail + 1, self.cap); <del> if mem::size_of::<T>() != 0 { unsafe { Some(&mut *self.ptr.offset(tail as int)) } } else { // use a non-zero pointer Some(unsafe { mem::transmute(1u) }) </del> <ins> unsafe { Some(&mut *self.ptr.offset(tail as int)) </ins> } }

Discussion:
There's currently no method on . This might have been missed during collections reform, or was never implemented.
Change:
# specified, use this rustc binary instead as the stage0 snapshot compiler. #rustc = "/path/to/bin/rustc" <ins> # Instead of download the src/stage0.txt version of rustfmt specified, # use this rustfmt binary instead as the stage0 snapshot rustfmt. #rustfmt = "/path/to/bin/rustfmt" </ins> # Flag to specify whether any documentation is built. If false, rustdoc and # friends will still be compiled but they will not be used to generate any # documentation.

Discussion:
with the introduction of , the mandatories the use of downloaded . but all platforms doesn't have binary distribution, mainly tiers-3 platforms like OpenBSD. For rustc or cargo dependencies, it is possible to use (with and key in section) to point to alternate binaries. this way, doesn't download them and use local supplied binaries. For it is currently not possible: if is able to deal with it, will complains that isn't a valid key: What would be the right way to use a local binary in order to copte with , and not force the use of downloaded binary ? Would adding a key in section of would be accepted (I could provide a patch of it, if yes) ? or should another method used ? Cc
Yes, that was on oversight on my part. I would be happy to review a patch adding it to You should also be able to comment out the line in as a (possibly) temporary fix, this is my plan for beta and stable branches FWIW.
Change:
// Pull out the tokens that we've collected from the call to `f` above. let mut collected_tokens = match *last_token { LastToken::Collecting(ref mut v) => mem::take(v), <del> LastToken::Was(_) => panic!("our vector went away?"), </del> <ins> LastToken::Was(ref was) => { let msg = format!("our vector went away? - found Was({:?})", was); debug!("collect_tokens: {}", msg); self.sess.span_diagnostic.delay_span_bug(self.token.span, &msg); // This can happen due to a bad interaction of two unrelated recovery mechanisms // with mismatched delimiters *and* recovery lookahead on the likely typo // `pub ident(` (#62895, different but similar to the case above). return Ok((ret?, TokenStream::new(vec![]))); } </ins> }; // If we're not at EOF our current token wasn't actually consumed by

Discussion:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc
Change:
use rustc_hir as hir; use rustc_hir::def::{CtorOf, DefKind}; use rustc_hir::lang_items::LangItem; <del> use rustc_hir::{ExprKind, ItemKind, Node}; </del> <ins> use rustc_hir::{Expr, ExprKind, ItemKind, Node, Stmt, StmtKind}; </ins> use rustc_infer::infer; use rustc_middle::lint::in_external_macro; use rustc_middle::ty::{self, Binder, Ty};

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-suggestion-diagnostics
claim