jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0499]: cannot borrow `x` as mutable more than once at a time --> $DIR/issue-65131.rs:14:22 | LL |     get_pair(&mut x, &mut x); |     -------- ------  ^^^^^^ second mutable borrow occurs here |     |        | |     |        first mutable borrow occurs here |     first borrow later used by call error: aborting due to previous error For more information about this error, try `rustc --explain E0499`. </ins>

Discussion:
This code is the protocol handler, and generated by one of the MAVLink specification. It is C/Rust mixed project, so to compile it you will need Rust , CC an any C compiler. To check how slow rustc is, , and run cargo test in the GroundControl/demo dir Exactly this project is compiled with error, cause the borrow checker complains in one place. But anyway, the problem is that compilation is unacceptably slow. Description generated API is generated sample of using generated API the test I generate variation of this project, with same functionality, in C, C++, C#.... They are the compiled in seconds ! What wrong with my Rust project? How can I speed up compilation? My PC Intel I7-7700K RAM 32G SSD Samsung 970 PRO cargo -V cargo 1.39.0-nightly ( 2019-09-25) rustc -V rustc 1.40.0-nightly ( 2019-09-30)
Please provide build instructions for that code. Running in gives: .
But I wrote and run cargo test in the GroundControl/demo dir
That gives the same error, since it just has a dependency on the crate in ...
Small bug fix in the file. Please try again. Thanks.
That didn't fix it
on my debian and windows 10 build script shown: cargo:warning=Starting search config.h in.... cargo:warning=/root/InRUST/GroundControl/demo/target/debug/build/blackbox-sys-/out cargo:warning=/root/InRUST/GroundControl/demo/target/debug/build/blackbox-sys- cargo:warning=/root/InRUST/GroundControl/demo/target/debug/build cargo:warning=/root/InRUST/GroundControl/demo/target/debug cargo:warning=/root/InRUST/GroundControl/demo/target cargo:warning=/root/InRUST/GroundControl/demo cargo:warning=<<< Find and use generated config.h in root/InRUST/GroundControl/lib/src/
made more platform specific fixes. check now please.
I've looked into this code and likely found the problem. The bright side: it compiles in under half a minute if the errors are removed. The part of the code causing this problem is a test function that tries to test everything at once and has about 8000 lines.

The function contains (as of commit ) 76 borrow checker errors and the part that takes 5 hours is generating the 3-point errors for them. The time is dominated by the for the function body.
A minimized reproduction looks like this On my laptop this code requires about 25 seconds to print the error for the 1000 statements generated above and scales with the cube of the statement count.
On the bright side, waiting 5 hours for borrowck errors is still faster than trying to debug a memory corruption in a language without borrowck. (edit: lol, why so serious, this was meant to be humorous and not a complaint about Rust…)
Thanks to for the report and helping us to work with it, and to for the quick analysis and fix!
Change:
RUST_BACKTRACE: 1 <<: *job-linux-xl <ins> - name: x86_64-gnu-llvm-12-stage1 env: RUST_BACKTRACE: 1 <<: *job-linux-xl </ins> - name: x86_64-gnu-nopt <<: *job-linux-xl

Discussion:
Similar to , we expect contributors to run this frequently, so it should be tested in CI. suggested using the defaults in but I'm a little hesitant to do that because some of them are very wrong for CI (e.g. ) and others shouldn't affect tests but make the compiler slower (e.g. ). I do agree we should enable incremental for these tests, though. Not sure which builder to add these to - adding it to mingw-check would make it significantly slower, and I don't know which of the full builders has spare capacity. do you have suggestions? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
To be clear, I was mistakenly under the impression that only stage1 tests were ran for PR CI. But I could see how that may be an issue for tests (though, is it easy to only run those in stage2?).
ah yeah no, we currently run in PR CI. I think it might make sense to only run now that you mention it though! would be a lot faster and in practice there are very few tests that only fail in stage 2. not currently, no - I think it wouldn't be impossible to add to compiletest though, it already does filtering and parses the headers, so it should be possible to combine the two. That would mean we have to build the stage 2 compiler though, so if we switch to stage 1 I think it would be ok to only run those in a full bors merge, not in PR CI.
just add another builder, we have capacity for that.
If we do get another builder, can we have incremental enabled on it (or rather, whichever dev profile enables that)? Some codegen tests haven't been passing for a short while because of the difference, and might be good to be tracking something that strongly resembles local workflows.
Error: Parsing assign command in failed: ...'bot assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
What is the correct course of action here? Adding another builder?
Yes, adding another builder is enough.

I want to investigate running --stage 1 in PR CI instead of --stage 2 long term, but that's harder and shouldn't block testing this.
This would have caught , I assume?
Yes, despite not being filed as an issue, that's exactly the kind of test failure I was referencing in (it does require that we do enable incremental, not just test at stage 1).
Change:
<ins> // check-pass fn test() -> impl Iterator<Item = impl Sized> { Box::new(0..) as Box<dyn Iterator<Item = _>> } fn main() {} </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. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- 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 --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { assert_eq!(match [0u8, ..1024] { _ => 42u, }, 42u); assert_eq!(match [0u8, ..1024] { [1, _..] => 0u, [0, _..] => 1u, _ => 2u }, 1u); } </ins>

Discussion:
Minimal test case: If 1024 doesn’t do it for you, try bumping it upwards. ought to do it. Just don’t try numbers like a million or you’ll be waiting a while before it crashes. And if you have anything like systemd-coredump start automatically, it’ll be busy for a while as well… I guess there are a few areas where [T, ..N] is not handled well for large N. (Additional keywords: sized array.)
Running it under GDB shows that it’s flipping back and forth between two functions recursively: Whatever this recursive algorithm is needs to be made non-recursive.
There is a slight difference between this minimal test case, and the original issue . If I reduce the size of the array to 10 bytes in , compilation never completes (no error is raised). If I reduce the size of the array in this test case to 10 bytes, it compiles.
could you try to narrow down the test from , in the manner that chris-morgan has done here, but preserving the behavioral difference you are observing?
I will try my best (this lunchtime), but I only have three hours experience with Rust so far. Every few lines of code written or modified requires 15 minutes of Googling the docs. (This learning curve is still much less steep than Haskell's was.)
feel free to drop by , you’ll get any help you need there quickly.
I was mistaken. I had a subsequent, chained, command on the command line which produced no output and hung. I mistook this for the compiler hanging.
okay, great, thanks for the update! (I now feel better about asking you to do the narrowing rather than attempting to do it myself.) ;)
Change:
// except according to those terms. macro_rules! test { ($wrong:t_ty ..) => () } <del> //~^ ERROR: unrecognized builtin nonterminal `t_ty` </del> <ins> //~^ ERROR: invalid fragment specifier `t_ty` </ins> fn main() {}

Discussion:
I work on Windows 8.1 64-bit, rustc version: BTW, the same ICE occurred for my but it did not print backtrace with and I don't know why.
Change:
and run it. If you decide you don't want Rust anymore, we'll be a bit sad, but that's okay. <del> Not every programming language is great for everyone. Just pass an argument to the script: </del> <ins> Not every programming language is great for everyone. Just run the uninstall script: </ins> ```bash <del> $ curl -s https://static.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall </del> <ins> $ sudo /usr/local/lib/rustlib/uninstall.sh </ins> ``` If you used the Windows installer, just re-run the `.exe` and it will give you

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut shrinker: Box<Iterator<Item=i32>> = Box::new(vec![1].into_iter()); println!("{:?}", shrinker.next()); for v in shrinker { assert!(false); } let mut shrinker: &mut Iterator<Item=i32> = &mut vec![1].into_iter(); println!("{:?}", shrinker.next()); for v in shrinker { assert!(false); } } </ins>

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
fn check_irrefutable(&self, pat: &'tcx Pat, origin: &str) { let module = self.tcx.hir.get_module_parent(pat.id); <del> MatchCheckCtxt::create_and_enter(self.tcx, module, |ref mut cx| { </del> <ins> MatchCheckCtxt::create_and_enter(self.tcx, self.param_env, module, |ref mut cx| { </ins> let mut patcx = PatternContext::new(self.tcx, self.param_env.and(self.identity_substs), self.tables);

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
/// } /// ``` #[inline] <del> #[unstable(feature = "arc_mutate_strong_count", issue = "71983")] pub unsafe fn incr_strong_count(ptr: *const T) { </del> <ins> #[stable(feature = "arc_mutate_strong_count", since = "1.51.0")] pub unsafe fn increment_strong_count(ptr: *const T) { </ins> // Retain Arc, but don't touch refcount by wrapping in ManuallyDrop let arc = unsafe { mem::ManuallyDrop::new(Arc::<T>::from_raw(ptr)) }; // Now increase refcount, but don't drop new refcount either

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- [ ] Can we improve the docs phrasing on ? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial PR in Stabilization PR in
Hello Would it make sense to also include similar methods for Rc? And possibly similar ones to both Weaks? It would be in part for the sake of completeness, but I do some manipulation like this in the arc-swap crate and if this would become the „official“ way, it would be nice to be supported on all the related types.
I think that's a great idea, and we should file follow-up issues to implement those.
Change:
<ins> // Copyright 2017 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. fn main() { let b = "hello"; println!("🦀🦀🦀🦀🦀"); let _a = b + ", World!"; //~^ ERROR E0369 } </ins>

Discussion:
This code (containing tabs) gives an error (): The error works fine on stable: But is mispositioned on rustc 1.25.0-nightly ( 2018-01-11) as well as on rustc 1.24.0-beta.2 ( 2018-01-10): cc
Interesting. Im new to code work so following you guys has been extremely helpful thanks
Using bisect-rust I could see that the issue started with , but probably the actual issue is somewhere else (e.g. in the machinery in that starts using for tabs).
Yeah, the issue also exists when emojis are involved (no tabs): Gives: The emoji manifestation of the issue is no beta regression, seems to exist on stable as well.
I've created for the emoji/unicode issue.
It seems to me that the issue only manifests itself in suggestions, and that is handled separately from the main diagnostics. Mentoring instructions:  needs to be modified to use instead of , the start being and the end being ( already accounts for unicode chars). This change should fix both this and .
Will pick this up
Change:
<ins> // compile-pass #![feature(const_fn, rustc_attrs)] #[rustc_args_required_const(0)] pub const fn a(value: u8) -> u8 { value } #[rustc_args_required_const(0)] pub fn b(_: u8) { unimplemented!() } fn main() { let _ = b(a(0)); } </ins>

Discussion:
: produces cc
Not that this fixes the issue, but and aren't necessarily guaranteed to have the same representation without or on both and .
minified: is this a victim of the backwards algorithm for promotion? Just a hunch, but it might have promoted away the call to and then end up trying to promote the , but it's not in the place where it was expected, because it now lives inside the promoted. So it ends up trying to promote an argument in a basic block that was already promoted away
thanks , I'll update the PR that triggered this - for context
As a workaround until we fix this ICE, you can introduce an intermediate explicit constant for the argument to . Or is this part of a user-exposed API?
This is part of a user-exposed API, but that workaround should allow me to at least get the const tests running.
It won't remove the definition if there's more than one use (unless this is fallout from your changes?)
There's only one use. I don't see how my changes could have caused this, but it seems possible. I'll do a bisection
Oh, I see, is and that's missing a check like:
Fix instructions: Add a which, like the variable, is used to mark blocks whose terminator has been promoted out. skip promoting all such terminators when encountering said block id in a ()
You can use a , although I'm not even sure it's necessary. A promoted call ends up as a , so you could just skip it based on that?
Change:
<ins> trait T<'x> { type V; } impl<'g> T<'g> for u32 { type V = u16; } fn main() { (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); //~^ ERROR: type mismatch in closure arguments //~| ERROR: type mismatch resolving } </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.
Change:
<ins> fn main() { let _: u32 = i32::from(0_u8); //~ ERROR mismatched types } </ins>

Discussion:
I updated a dependency and the type of a struct field changed from an to a . I am assigning a value to this struct field. Before, I was calling to convert the to an . With the upgrade this is unnecessary since the field and the value are both . The rust compiler suggests this fix: But it should really suggest removing the and using the directly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am using Rust 1.37.0.
cc
Similarly, this code should suggest replacing with .
For the case where we have and an was expected, what should be the correct behavior? I believe simply suggesting is appropriate, if funny looking, because the could_ be coming from outside a macro, and the error be inside of one. Thoughts?
that sounds good to me
claim
Which of these options makes more sense? Check if the new (suggested) conversion is infallible always (doesn't make sense in the 1st case?) only in the 2nd case (if the new conversion is fallible, I presume we fall back to other suggestions and should be suggested, which makes a bit of sense, since it highlights the possible panic?) never (if is detected, always suggest to replace with ) Seems like the user already opted in for panicking if the conversion fails, so conversion was fallible and will stay so:The conversion is infallible but will become fallible if the suggestion is applied:
release-assignment
sorry, didn't see your claim before I pushed my PR :-|
Change:
https://doc.rust-lang.org/book/ch13-01-closures.html", ); } <del> diag.emit(); ty::Binder::dummy(fn_sig) </del> <ins> let guar = diag.emit(); if should_recover { ty::Binder::dummy(fn_sig) } else { ty::Binder::dummy(tcx.mk_fn_sig( fn_sig.inputs().iter().copied(), tcx.ty_error(guar), fn_sig.c_variadic, fn_sig.unsafety, fn_sig.abi, )) } </ins> } None => icx.astconv().ty_of_fn( hir_id,

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
That second function can be named anything, for the record. e.g.