jiebi/CodeConvo huggingface dataset:
Change:
} fn set_bcb_counter(&mut self, bcb: BasicCoverageBlock, counter_kind: BcbCounter) -> BcbCounter { <del> assert!( // If the BCB has an edge counter (to be injected into a new `BasicBlock`), it can also // have an expression (to be injected into an existing `BasicBlock` represented by this // `BasicCoverageBlock`). counter_kind.is_expression() || !self.bcb_has_incoming_edge_counters.contains(bcb), "attempt to add a `Counter` to a BCB target with existing incoming edge counters" ); </del> if let Some(replaced) = self.bcb_counters[bcb].replace(counter_kind) { bug!( "attempt to set a BasicCoverageBlock coverage counter more than once; 

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' 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: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
<ins> #![crate_name = "foo"] pub mod sub { pub struct Item; pub mod prelude { pub use super::Item; } } #[doc(inline)] pub use sub::*; // @count foo/index.html '//a[@class="mod"][@title="foo::prelude mod"]' 1 // @count foo/prelude/index.html '//div[@class="item-row"]' 0 pub mod prelude {} </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 glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
&& sess.opts.debuginfo != DebugInfo::None && !preserve_objects_for_their_debuginfo(sess) { <del> if let Err(e) = Command::new("dsymutil").arg(out_filename).output() { sess.fatal(&format!("failed to run dsymutil: {}", e)) </del> <ins> let prog = Command::new("dsymutil").arg(out_filename).output(); match prog { Ok(prog) => { if !prog.status.success() { let mut output = prog.stderr.clone(); output.extend_from_slice(&prog.stdout); sess.struct_warn(&format!( "processing debug info with `dsymutil` failed: {}", prog.status )) .note(&escape_string(&output)) .emit(); } } Err(e) => sess.fatal(&format!("unable to run `dsymutil`: {}", e)), </ins> } } }

Discussion:
On macOS rustc runs dsymutil to generate debug info files. This invocation incorrectly ignores dsymutil's output and exit status. rustc thus succeeds even if dsymutil fails or crashes. Example: in , dsymutil crashed and left behind a corrupt .dSYM file. rustc nevertheless succeeded, thereby confusing the user after the debugger ignored that bad debug info. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc ignoring :
claim
Change:
<ins> //@ revisions: edition2015 edition2021 </ins> pub mod foo { pub mod bar { pub fn do_the_thing() -> usize {

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:
Note that this table can be expanded over time, this isn't the exhaustive set of tier 3 platforms that will ever be! <del> ## Installing on Linux or Mac </del> <ins> ## Installing Rust </ins> <del> If we're on Linux or a Mac, all we need to do is open a terminal and type this: </del> <ins> All you need to do on Unix systems like Linux and macOS is open a terminal and type this: </ins> ```bash <del> $ curl -sSf https://static.rust-lang.org/rustup.sh | sh </del> <ins> $ curl https://sh.rustup.rs -sSf | sh </ins> ``` <del> This will download a script, and start the installation. If it all goes well, you’ll see this appear: </del> <ins> It will download a script, and start the installation. If everything goes well, you’ll see this appear: </ins> ```text <del> Rust is ready to roll. </del> <ins> Rust is installed now. Great! </ins> ``` <del> From here, press `y` for ‘yes’, and then follow the rest of the prompts. </del> <ins> Installing on Windows is nearly as easy: download and run [rustup-init.exe]. It will start the installation in a console and present the above message on success. </ins> <del> ## Installing on Windows </del> <ins> For other installation options and information, visit the [install] page of the Rust website. </ins> <del> If you're on Windows, please download the appropriate [installer][install-page]. [install-page]: https://www.rust-lang.org/install.html </del> <ins> [rustup-init.exe]: https://win.rustup.rs [install]: https://www.rust-lang.org/install.html </ins> ## Uninstalling <del> Uninstalling Rust is as easy as installing it. On Linux or Mac, run the uninstall script: </del> <ins> Uninstalling Rust is as easy as installing it: </ins> ```bash <del> $ sudo /usr/local/lib/rustlib/uninstall.sh </del> <ins> $ rustup self uninstall </ins> ``` <del> If we used the Windows installer, we can re-run the `.msi` and it will give us an uninstall option. </del> ## Troubleshooting If we've got Rust installed, we can open up a shell, and type this:

Discussion:
Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
Change:
arg.descr(), kind, ); <ins> let kind_ord = match kind { "lifetime" => ParamKindOrd::Lifetime, "type" => ParamKindOrd::Type, "constant" => ParamKindOrd::Const, // It's more concise to match on the string representation, though it means // the match is non-exhaustive. _ => bug!("invalid generic parameter kind {}", kind), }; let arg_ord = match arg { GenericArg::Lifetime(_) => ParamKindOrd::Lifetime, GenericArg::Type(_) => ParamKindOrd::Type, GenericArg::Const(_) => ParamKindOrd::Const, }; </ins> // This note will be true as long as generic parameters are strictly ordered by their kind. <del> err.note(&format!("{} arguments must be provided before {} arguments", kind, arg.descr())); </del> <ins> let (first, last) = if kind_ord < arg_ord { (kind, arg.descr()) } else { (arg.descr(), kind) }; err.note(&format!("{} arguments must be provided before {} arguments", first, last)); </ins> err.emit(); }

Discussion:
suggests type parameters should come before lifetime parameters, which is incorrect. The message is emitted here: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I want to try working on this. claim
I've been trying to fix this, but even reversing the arguments to the format didn't seem to do anything. Am I missing something? I also to the error note for testing: And here's the error diff: EDIT: I modified the expected stderr for the test so that it matches how it should look after this is fixed by the way.
I've looked into it a bit more, and it looks like this isn't as simple as I thought at first. I thought it might work if I just reversed the arguments to , but that messes up other things. I think I'll need to rethink this.
Note that I cherry-picked the examples that were incorrect. The diagnostic is correct in other cases. You'll need to investigate a little to work out how best to fix this; one simple solution would be to sort the two with , though I'm not sure if that's the cleanest approach.
Okay, thanks for the info! I'll look into sorting and see if that works :)
I think I've figured out a basic solution. Let me know if there are things I can improve!
Change:
<ins> // run-pass // compile-flags: -Z mir-opt-level=2 -C opt-level=0 -C debuginfo=2 #[inline(never)] pub fn foo(bar: usize) -> usize { std::convert::identity(bar) } fn main() { foo(0); } </ins>

Discussion:
modify labels: +A-mir +C-bug +requires-nightly
cc
I wonder if this is caused by MIR inlining or by other passes like copy propagation. The conflict with would seem to suggest inlining (of a method call). Anyway, we can improve this for now by treating anything not in the outermost as not an argument user variable (even when backed by an argument MIR local).
Minimal repro, with ():
Change:
/// # Examples /// /// ``` <del> /// #![feature(btree_retain)] </del> /// use std::collections::BTreeSet; /// /// let xs = [1, 2, 3, 4, 5, 6];

Discussion:
This is a tracking issue for and (part of rust-lang/rfcs). The feature gate for the issue is . [x] Implement the RFC [x] FCP [ ] Adjust documentation [ ] Stabilization PR Is the performance of the current implementation (based on ) good enough to be useful? Concern raised in . Initial implementation:
We discussed this in today's meeting. We'd like to see a comment documenting the performance characteristics of this (as well as a corresponding update to ), and suggesting that this might not be what you want if you're removing a substantial number of elements. Beyond that documentation, though, we'd be happy to see this stable. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
// of the metadata file, because that would end up making our indices // not special. It is essentially impossible for that to happen, // but let's make sure <del> assert!(pos != interpret::ALLOC_DISCRIMINANT && pos != interpret::FN_DISCRIMINANT); </del> <ins> assert!(pos >= interpret::SHORTHAND_START); </ins> entry.insert(pos); None },

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
<del> The loop took around 7s </del> <ins> The loop took around 12s </ins>

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
<ins> // run-rustfix struct Foo; impl std::ops::Mul for &Foo { type Output = Foo; fn mul(self, _rhs: Self) -> Self::Output { unimplemented!() } } fn main() { let ref_mut_foo: &mut Foo = &mut Foo; let ref_foo: &Foo = &Foo; let owned_foo: Foo = Foo; let _ = ref_foo * ref_foo; let _ = ref_foo * ref_mut_foo; let _ = &*ref_mut_foo * ref_foo; //~^ ERROR cannot multiply let _ = &*ref_mut_foo * &*ref_mut_foo; //~^ ERROR cannot multiply let _ = &*ref_mut_foo * &owned_foo; //~^ ERROR cannot multiply } </ins>

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!
Change:
LL |     bar!(Level::Error, ); |                       ^ missing tokens in macro arguments <del> error: aborting due to 6 previous errors </del> <ins> error: no rules expected the token `,` --> $DIR/missing-comma.rs:32:38 | LL | macro_rules! check { | ------------------ when calling this macro ... LL |     check!(<str as Debug>::fmt, "fmt",); |                                      ^ no rules expected this token in macro call error: aborting due to 7 previous errors </ins>

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
scapegoat: ty::t) { let esz = machine::llsize_of_alloc(ccx, llet); match esz.checked_mul(size) { <del> Some(n) if n < ccx.max_obj_size() => {} </del> <ins> Some(n) if n < ccx.obj_size_bound() => {} </ins> _ => { ccx.report_overbig_object(scapegoat) } } }

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.
Change:
{ let span = self.tcx.def_span(def_id); diag.span_note(span, "this closure does not fulfill the lifetime requirements"); <ins> self.suggest_for_all_lifetime_closure(span, self.tcx.hir().get_by_def_id(def_id), &exp_found, diag); </ins> } // It reads better to have the error origin as the final

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim
Change:
except ImportError: lzma = None <del> if sys.platform == 'win32': </del> <ins> def platform_is_win32(): return sys.platform == 'win32' if platform_is_win32(): </ins> EXE_SUFFIX = ".exe" else: EXE_SUFFIX = ""

Discussion:
I tried this: I expected to see this happen: Bootstrap rebuilds the compiler. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --is
In particular, this happens when rust-analyzer is running in the background and you have this config set: We currently recommend that config in https://rustc-dev-
This would be fixed by having a "public" and "private" sysroot: https://rust-
This happens because Windows doesn't allow deleting a running executable/DLL. The way forward would be to special-case it as it is already the case with the file and ignore failures, or to make a double sysroot as you proposed.
You can usually rename a running executable so it may be possible to simulate a delete by moving it within the same filesystem. However, having a public and a private sysroot seems like a more generally useful solution.
I'm happy with both solutions. I think special casing proc-macro-server in the short term seems fine, but if we do that, we should open another issue for the public and private sysroot.
Change:
<ins> error: at least one trait must be specified --> $DIR/issue-78720.rs:1:16 | LL | fn server() -> impl { |                ^^^^ error[E0412]: cannot find type `F` in this scope --> $DIR/issue-78720.rs:13:12 | LL |     _func: F, |            ^ | ::: $SRC_DIR/core/src/ops/function.rs:LL:COL | LL | pub trait Fn<Args>: FnMut<Args> { | ------------------------------- similarly named trait `Fn` defined here | help: a trait with a similar name exists | LL |     _func: Fn, |            ^^ help: you might be missing a type parameter | LL | struct Map2<Segment2, F> { |                     ^^^ error[E0308]: mismatched types --> $DIR/issue-78720.rs:7:36 | LL |     fn map2<F>(self, F) -> Map2<F> {} |                                    ^^ expected struct `Map2`, found `()` | = note: expected struct `Map2<F>` found unit type `()` error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/issue-78720.rs:7:16 | LL |     fn map2<F>(self, F) -> Map2<F> {} |                ^^^^ doesn't have a size known at compile-time | = help: unsized fn params are gated as an unstable feature help: consider further restricting `Self` | LL |     fn map2<F>(self, F) -> Map2<F> where Self: Sized {} |                                    ^^^^^^^^^^^^^^^^^ help: function arguments must have a statically known size, borrowed types always have a known size | LL |     fn map2<F>(&self, F) -> Map2<F> {} |                ^ error: aborting due to 4 previous errors Some errors have detailed explanations: E0277, E0308, E0412. For more information about an error, try `rustc --explain E0277`. </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
does this still panic after ? That only merged a couple days ago so you'll need to update your version of nightly.
Hmm I checked and it does, and it also panics before. So probably unrelated? cc just in case
Note that this works fine on .
Sorry, I accidentally closed the issue. Yes, you are right. It still crashes on the latest nightly version. I have a cron job to update my rust version everyday.
I think we ended up (incorrectly) removing a check in We shouldn't be calling upvarsty if is . This is a separate issue than that was fixed in
claim