jiebi/CodeConvo huggingface dataset:
Change:
); return if r == 0 { <del> debug_assert!(update_panic_count(0) == 0); </del> Ok(ManuallyDrop::into_inner(data.r)) } else { update_panic_count(-1); <del> debug_assert!(update_panic_count(0) == 0); </del> Err(mem::transmute(raw::TraitObject { data: any_data as *mut _, vtable: any_vtable as *mut _,

Discussion:
In particular panics because of failing assert in For example:
Cc I think that assert doesn't make much sense if I'm interpreting correctly, though I'm surprised it hasn't been hit before...
The current implementation seems to incorrectly assume that unwinding is not in progress when entering . Not caught before, since std is usually used without debug assertions (it definitely happens in actually existing code, what is unusual is that I am using and hence hitting the assertion). There is a similar although a separate question if following should abort or not:
Yes, the second code snippet should definitely abort - we abort on the second live panic, independent of whether it's going to be caught.
Change:
"indexmap", "jobserver", "libc", <del> "measureme 10.0.0", </del> <ins> "measureme", </ins> "memmap2", "parking_lot 0.11.2", "rustc-hash",

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!
Probably a missing join (these tests are a bit random, now that we have preemption).
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. use middle::ty; <del> use syntax::ast::*; use syntax::visit; </del> <ins> use syntax::ast; use syntax::codemap::Span; </ins> use syntax::visit::Visitor; <ins> use syntax::visit; </ins> <del> #[deriving(Clone)] pub struct Context { in_loop: bool, can_ret: bool </del> <ins> #[deriving(Clone, Eq)] enum Context { Normal, Loop, Closure </ins> } struct CheckLoopVisitor { tcx: ty::ctxt, } <del> pub fn check_crate(tcx: ty::ctxt, crate: &Crate) { visit::walk_crate(&mut CheckLoopVisitor { tcx: tcx }, crate, Context { in_loop: false, can_ret: true }); </del> <ins> pub fn check_crate(tcx: ty::ctxt, crate: &ast::Crate) { visit::walk_crate(&mut CheckLoopVisitor { tcx: tcx }, crate, Normal) </ins> } impl Visitor<Context> for CheckLoopVisitor { <del> fn visit_item(&mut self, i:@item, _cx:Context) { visit::walk_item(self, i, Context { in_loop: false, can_ret: true }); </del> <ins> fn visit_item(&mut self, i: @ast::item, _cx: Context) { visit::walk_item(self, i, Normal); </ins> } <del> fn visit_expr(&mut self, e:@Expr, cx:Context) { match e.node { ExprWhile(e, ref b) => { </del> <ins> fn visit_expr(&mut self, e: @ast::Expr, cx:Context) { match e.node { ast::ExprWhile(e, ref b) => { </ins> self.visit_expr(e, cx); <del> self.visit_block(b, Context { in_loop: true,.. cx }); } ExprLoop(ref b, _) => { self.visit_block(b, Context { in_loop: true,.. cx }); } ExprFnBlock(_, ref b) | ExprProc(_, ref b) => { self.visit_block(b, Context { in_loop: false, can_ret: false }); } ExprBreak(_) => { if !cx.in_loop { self.tcx.sess.span_err(e.span, "`break` outside of loop"); } } ExprAgain(_) => { if !cx.in_loop { self.tcx.sess.span_err(e.span, "`loop` outside of loop"); } } ExprRet(oe) => { if !cx.can_ret { self.tcx.sess.span_err(e.span, "`return` in block function"); </del> <ins> self.visit_block(b, Loop); } ast::ExprLoop(ref b, _) => { self.visit_block(b, Loop); } ast::ExprFnBlock(_, ref b) | ast::ExprProc(_, ref b) => { self.visit_block(b, Closure); } ast::ExprBreak(_) => self.require_loop("break", cx, e.span), ast::ExprAgain(_) => self.require_loop("continue", cx, e.span), ast::ExprRet(oe) => { if cx == Closure { self.tcx.sess.span_err(e.span, "`return` in a closure"); </ins> } visit::walk_expr_opt(self, oe, cx); <del> } _ => visit::walk_expr(self, e, cx) </del> } <ins> _ => visit::walk_expr(self, e, cx) } } } impl CheckLoopVisitor { fn require_loop(&self, name: &str, cx: Context, span: Span) { match cx { Loop => {} Closure => { self.tcx.sess.span_err(span, format!("`{}` inside of a closure", name)); } Normal => { self.tcx.sess.span_err(span, format!("`{}` outside of loop", name)); } } </ins> } }

Discussion:
As per comment before
I don't think this is backwards incompatible.
just a bug, removing milestone/nomination.
Change:
<del> // 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. // error-pattern:internal error: entered unreachable code fn main() { unreachable!() } </del>

Discussion:
In we had the submitter change a to an as follows: We felt that better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to , which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib). However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code. Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to . It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since still includes a filename and line number in its output. However, given the precedent of optional messages set by , I don't think it would be a stretch to imagine that could also have an optional message. Usage for the typical case would be the same: could optionally look like this:
I'll have a go at implementing this.
Change:
use rustc_lint; use rustc::session::{self, config}; <ins> use rustc::hir::def::Namespace::TypeNS; </ins> use rustc::hir::def_id::{DefId, DefIndex, CrateNum, LOCAL_CRATE}; use rustc::hir::HirId; use rustc::middle::cstore::CrateStore;

Discussion:
/cc
So the explosion is that somehow the crate index in the is broken, or at least not entirely right. Interestingly if you add to the then it no longer ICEs (but has the same ) Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both and prevent the iCE)
Maybe it's linked to ? If so, it's not in rustdoc but below.
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the instance. Since was made optional, and crate names are automatically part of the global scope, people stopped necessarily telling the compiler about the crates in their code. If a comment references a path in this manner, but the code itself doesn't, then the resolver frozen into the doesn't have that crate's metadata loaded into it. When we then ask the resolver to resolve a new path (e.g. ) it goes ahead and loads the crate into a different instance of the than will be used when we then try and use the later. It feels like the moment a is d it should also be locked so that it can never be modified again. It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, , I feel this is probably either a bug in how is handling the resolver, or else a change in how the resolver behaves which either needs fixing, or changing in to cope.
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: and instead try and find a resolver as part of the closure here: Of course, it looks like a has an immutable copy of the resolver's outputs, and no access to the resolver itself, urgh, and we have no easy way to inject changes into the context at this point.
I wonder why that type can be cloned in the first place...

I found an ICE when trying to document the [spirit-log][1] crate on the latest . Skimming through the backtrace, it looks like accessed an invalid index while traversing links within . Steps to reproduce: [1]:
Taking a look.
Actually, it's failing outside of rustdoc so I prefer to let someone else handle it. cc
I think this might be a bug (or at least mismatch between how uses the resolver infrastructure and how it's meant to work). See my comment here:
Change:
if self.impling_types.is_none() { let mut impls = NodeSet(); cx.tcx.for_each_impl(debug, |d| { <del> if let Some(ty_def) = cx.tcx.type_of(d).ty_to_def_id() { if let Some(node_id) = cx.tcx.hir.as_local_node_id(ty_def) { </del> <ins> if let Some(ty_def) = cx.tcx.type_of(d).ty_adt_def() { if let Some(node_id) = cx.tcx.hir.as_local_node_id(ty_def.did) { </ins> impls.insert(node_id); } }

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
<ins> // Copyright 2016 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. static mut DROP: bool = false; struct ConnWrap(Conn); impl ::std::ops::Deref for ConnWrap { type Target=Conn; fn deref(&self) -> &Conn { &self.0 } } struct Conn; impl Drop for  Conn { fn drop(&mut self) { unsafe { DROP = true; } } } fn inner() { let conn = &*match Some(ConnWrap(Conn)) { Some(val) => val, None => return, }; return; } fn main() { inner(); unsafe { assert_eq!(DROP, true); } } </ins>

Discussion:
This was discovered in database connection pooling where connections were not returned to the pool properly, and reported under Unfortunately I do not have example code small enough to share at this point. I narrowed down the rust-nightly version that introduced the bug to nightly-2016-08-03-x86_64-unknown-linux-gnu
when compiled with RUSTFLAGS="-Zorbit=off" the issue does not appear, so yes it is the MIR as suspected.
The compiler not running drop glue is not considered unsafe behaviour (i.e. it is allowed to happen), but it is still weird this happens. cc could be your drop elaboration not catching this () case? Something that we could run without having postgresql installed would be ideal test case, even if it depended on other crates for now.
Minimal reproduction:
More minimal: Removing either of early s in the function makes the issue go away. Seems like a scoping issue.
regression-from-stable-to-nightly (for a two more days at least).
Yeah I jumped the gun on the tag, but the beta is building right now.
I saw your commit -- I feel like the extent should be unique for the cleanup scope. That is, we should push a given extent only once -- but perhaps I am wrong about this? It'd be good to add an assertion (or warning) for when we push cleanup scopes with the same extent more than once so we can see what it happens.
Ah, but reading IRC chatter I see that the problem is that the extent of the "outermost scope" changed and thus the helper is out of date? That seems pretty plausible.
As pointed out on the IRC the commit linked above is a shot in the dark and is not a fix.
Change:
<ins> //@ revisions: edition2015 edition2021 mod config; //~ ERROR file not found for module fn main() { match &args.cmd { //~ ERROR cannot find value `args` in this scope crate::config => {} //~ ERROR expected unit struct, unit variant or constant, found module `crate::config` } println!(args.ctx.compiler.display()); //~^ ERROR format argument must be a string literal } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [resolverforlowering_raw] getting the resolver for lowering --
I suspect this could be cc
what's the command line to reproduce it? I build nightly version and cannot reproduce it by only compiling the code. also I checked playground:
Ok, got it, we can not use 2021 edition in the command line.
Change:
use crate::collect::ItemCtxt; use rustc_hir as hir; use rustc_hir::intravisit::{self, Visitor}; <del> use rustc_hir::HirId; </del> <ins> use rustc_hir::{ForeignItem, ForeignItemKind, HirId}; </ins> use rustc_infer::infer::TyCtxtInferExt; use rustc_infer::traits::TraitEngine; use rustc_infer::traits::{ObligationCause, WellFormedLoc};

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. --: Also reproduces on 1.58.0 and 1.59.0. <!-- 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
Change:
<del> // Copyright 2012-2013 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. // Check that non constant exprs fail for vector repeat syntax fn main() { fn bar(n: usize) { let _x = [0; n]; //~^ ERROR attempt to use a non-constant value in a constant [E0435] //~| NOTE non-constant used with constant } } </del>

Discussion:
rustc 1.0.0 - 1.11.0: rustc 1.12.0 - 1.15.0: rustc 1.16.0 - present: Can we have the first one back please?
To clarify, the problem is in the note:
Note introduced in , using the exact wording from . Rust 1.12 fully transitioned to MIR, which made the repeat count no longer special, thus losing the special error message. I think the note should be reworded to "non-constant used as constant".
The error message today speaks the truth and does so quite well. Closing.
The span label is still pretty nonsensical.
Okay, I'll reopen. Can you provide the exact wording you'd expect? (I personally don't really see any point for a span label, but ... ).
Either remove the label or just "non-constant value" seems to make more sense to me. It's the "with constant" that is weird IMO.
I'll PR.
I just came here after googling and want to say that the first error message is a lot easier to understand!
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. type Func = fn(usize, usize) -> usize; fn foo(a: usize, b: usize) -> usize { a + b } fn bar(a: usize, b: usize) -> usize { a * b } fn test(x: usize) -> Func { if x % 2 == 0 { foo } else { bar } } const FOO: Func = foo; const BAR: Func = bar; fn main() { match test(std::env::consts::ARCH.len()) { FOO => println!("foo"), BAR => println!("bar"), _ => unreachable!(), } } </ins>

Discussion:
Hi all Following code produces always the same output in console and emits ... in compilation. Tested in Rust playground in nightly. Any comments?
In your code, , in match patterns are treated as variable names. Try pattern guards: Note that the return value of ranges from to , because accepts an argument of type . You will rarely see and , because most of the case the control flow will fall into the placeholder arm and print . Pattern matching is different from comparing with . You can implement your custom logic of by implementing [][partial-eq], but it lacks ability of destructuring structs, enums, and tuples. On the other hand, pattern matching can match against literals or destructure values, but you can't define your own pattern matching logic. They just have different purposes. in your code () implements to compare function pointers. However, functions are not literals, so they can't be matched directly. [partial-eq]:
Yes with guards it works, but I suspect it changes the semantics of match (less optimizations I guess). Is it possible to make "minus" and "plus" constants instead? I mean it's just pointers under the hood, right? And yes "rng" is just to give an idea.
You can normally use constants, but these currently fail: I guess noone thought that functions would be used in patterns:
That's much getter, imho. Thanks for hint. Functions as values? Never heard of heresy like that :)
Reduced the testcase.
The test cases here no longer ICE on beta or nightly.
Needs a regression test
Change:
#![doc = include_str!("doc.md")] use std::cell::{OnceCell, RefCell}; <del> use std::iter; </del> use std::ops::Range; <ins> use std::{iter, ptr}; </ins> use libc::c_uint; use rustc_codegen_ssa::debuginfo::type_names;

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. --I tried this code: Setting a breakpoint on in rust-gdb results in gdb stopping before 's stack slot is initialized, and gdb dereferences it to print wrong values based on : Note the incorrect different values of as I step past initialization. The breakpoint should trigger just after that , not before it. The other functions in that program indeed do it correctly. Oddly, it seems like the operator is necessary for my repro, though maybe that has something to do with the hidden var. (Note that vs is necessary to actually avoid accidental correct values of due to stack reuse, so the other functions can't print wrong as written. But I'm just looking at where the breakpoint hits in disassembly.) Here's relevant llvm-dwarfdump from this binary, with a pointing at at the () rather than the : This looks pretty related to and Like , the repro hits on 1.71 but not 1.70. I'm filing separately because, unlike it, disabling SingleUseConsts doesn't seem to fix the breakpoint. I'm not 100% sure I'm disabling it right - you can see my command above. <!-- 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
I'm not familiar with github's notification rules, so pinging
Thanks for the tag, I wouldn't have seen this otherwise. From , we can see that the "prologue end" marker that tells the debugger where to stop is indeed placed on the mov I suspect this is due to the desugaring of the ? operator since the column number provided is 29.
label +A-debuginfo
Sure enough, ConstDebugInfo is in there.
I guess you probably saw, but does suggest that the bisect is somehow misleading.
Yes, getting the values wrong at function entry is especially bad because it messes up conditional breakpoints.
Disabling the pass doesn't do anything here because the is created by when it removes . Otherwise this is identical to .

The easiest way to fix this would be for DILocation to carry a "this is not a statement" flag that overrides LLVM's usual line based inference of statement markers. I'll run it by the LLVM folks and see what they say.
Actually, in this particular case, because the const is a ZST I think we can do better today without LLVM changes.
Thanks for reporting this. The linked PR will fix this particular degenerate case.
Change:
<del> //@ known-bug: rust-lang/rust#126389 mod a { pub mod b { pub mod c {} } } use a::*; use b::c; use c as b; fn c() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
return Err(0); } <ins> let color = config::parse_color(matches); let config::JsonConfig { json_rendered, json_unused_externs, .. } = config::parse_json(matches); let error_format = config::parse_error_format(matches, color, json_rendered); let codegen_options = CodegenOptions::build(matches, error_format); let debugging_opts = DebuggingOptions::build(matches, error_format); let diag = new_handler(error_format, None, &debugging_opts); // check for deprecated options check_deprecated_options(matches, &diag); </ins> if matches.opt_strs("passes") == ["list"] { println!("Available passes for running rustdoc:"); for pass in passes::PASSES {

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. --I tried this command: I expected to see this happen: rustdoc shows a warning, the way it does for any other value you pass to : Instead, this happened: Rustdoc gives no warning and lists all passes. <!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Move this check earlier to before is processed:
claim