jiebi/CodeConvo huggingface dataset:
Change:
use crate::builder::Kind; use crate::config::{LlvmLibunwind, TargetSelection}; use crate::util::{ <del> exe, libdir, mtime, output, run, run_suppressed, t, try_run, try_run_suppressed, CiEnv, </del> <ins> check_run, exe, libdir, mtime, output, run, run_suppressed, t, try_run, try_run_suppressed, CiEnv, </ins> }; mod builder;

Discussion:
I just cloned this rust repo and attemped to build it by calling It initialized submodules, started downloading and failed repeatedly: Waiting longer causes messages above to repeat. It's not connection issue, because it always fails after ~30 seconds of downloading (Messages above repeat in ~2 minutes). I also tried changing to here: What caused download to succeed in a few (1-2) minutes. So I assume it's to blame. version:
I got x.py to test libcore once, but after I updated my local clone of rust, I started getting this repeatedly:
I am nuking my entire rust clone in case changes to the bootstrap are incompatible to previous artifacts produced by previous versions. Why does x.py need to download submodules like and if I am only trying to test ? edit: apparently, this is expected
Nope, I am still getting the DownloadFile exception after refreshing everything, including updating MSYS2 to get curl to 7.65.1, trying the MSYS2 that comes along with git, and messing with
your issue is different and there is no involved (it downloads file through PowerShell). You can see this MSYS2 patch how to make it use instead:
Thank you, it works now
original issue (from comment 0) is not resolved. reported another issue that isn't solved either, there is only workaround available.
We should probably fallback to trying curl if the powershell invocation fails. Reopening. I think a PR would work best here.
For some reason, the powershell download is working again on both my MSYS2 install and from git bash. We still want that fallback though. I couldn't PR a fix though, because I don't know how the exception handling is working in that Python script.
Actually, since I should learn Python anyway, should I PR a fix? Is it as simple as detecting an exception occurred and refactoring the if-else statement in a way that it would also run ?
That's what I would suggest -- we can make it pretty simple and if anything goes wrong with the powershell call then fallback to curl
It might also make sense to try curl before using powershell, as suggested by in label: +E-easy
Change:
<ins> fn main() {} trait StreamOnce { type Position; } impl StreamOnce for &str { type Position = usize; } fn follow(_: &str) -> <&str as StreamOnce>::Position { String::new  //~ ERROR mismatched types } </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
can be replaced by any function item, e.g. or . Lifetime of must be bounded to a parameter, therefore does not work Regression in not sure which PR exactly though but I think modify labels: regression-from-stable-to-nightly
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
can actually also be replaced with or seemingly any type other than the return type in the function signature, but strangely leaving the function body empty does not trigger the ICE.
No longer ICEs since
Change:
--> $DIR/borrowck-mut-borrow-linear-errors.rs:12:30 | LL |             _ => { addr.push(&mut x); } <del> |                              ^^^^^^ `x` was mutably borrowed here in the previous iteration of the loop </del> <ins> |                    ----------^^^^^^- |                    |         | |                    |         `x` was mutably borrowed here in the previous iteration of the loop |                    first borrow used here, in later iteration of loop </ins> error: aborting due to 3 previous errors

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: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this:
Change:
<ins> error: traits in `#[derive(...)]` don't accept arguments --> $DIR/issue-69341-malformed-derive-inert.rs:4:19 | LL |     #[derive(parse())] |                   ^^ help: remove the arguments error: `derive` may only be applied to structs, enums and unions --> $DIR/issue-69341-malformed-derive-inert.rs:8:5 | LL |     path: (), |     ^^^^^^^^ error: cannot find derive macro `parse` in this scope --> $DIR/issue-69341-malformed-derive-inert.rs:4:14 | LL |     #[derive(parse())] |              ^^^^^ error: cannot find derive macro `parse` in this scope --> $DIR/issue-69341-malformed-derive-inert.rs:4:14 | LL |     #[derive(parse())] |              ^^^^^ error: aborting due to 4 previous errors </ins>

Discussion:
` :
This crashes on stable, beta and nightly.
cc
says this regressed between releases 1.40 and 1.41.
triage: P-high to bisect and determine severity. Removing nomination. Added stable-to-stable regression label.
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-25 regressed nightly: nightly-2019-12-08 searched commits: from to regressed commit: source code: Confirmed automated tests with manual run using <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
modify labels: -E-needs-bisection
Maybe
Reduced:
Fixed by
Change:
($($arg:tt)*) => ($crate::io::_print(format_args!($($arg)*))); } <del> /// Macro for printing to the standard output, with a newline. </del> <ins> /// Macro for printing to the standard output, with a newline. On all /// platforms, the newline is the LINE FEED character (`n`/`U+000A`) alone /// (no additional CARRIAGE RETURN (`r`/`U+000D`). </ins> /// /// Use the `format!` syntax to write data to the standard output. /// See `std::fmt` for more information.

Discussion:
As I was using writeln! to fill an in-memory buffer for data that explicitly wants a specific type of newlines (LF, fortunately), and I was wondering whether writeln! would always use LF, or would use the type of newline relevant to the platform (essentially, LF on Unix, CR/LF on Windows), and couldn't find the answer in !.html. (I got my answer on IRC, it's always LF) There may be other places where such information is relevant (println! comes to mind). Cc:
Sure, want to add it? :)
I would, if I knew whether there are other places that would benefit from this information as well.
Except for and , I don't see any places... You can already add it to these docs and if another function/macro needs it, then we'll add it.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/type_of_anon_const.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </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 --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
parent_trait_ref.skip_binder().self_ty() )); let parent_predicate = parent_trait_ref.without_const().to_predicate(tcx); <del> self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ); </del> <ins> // #74711: avoid a stack overflow ensure_sufficient_stack(|| { self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ) }); </ins> } ObligationCauseCode::DerivedObligation(ref data) => { let parent_trait_ref = self.resolve_vars_if_possible(&data.parent_trait_ref); let parent_predicate = parent_trait_ref.without_const().to_predicate(tcx); <del> self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ); </del> <ins> // #74711: avoid a stack overflow ensure_sufficient_stack(|| { self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ) }); </ins> } ObligationCauseCode::CompareImplMethodObligation { .. } => { err.note(&format!(

Discussion:
I would expect to error with "overflow evaluating the requirement", or compile without issue. Instead it segfaults. () Errors:
This segfault occurs since 1.45.0, 1.44.1 emits the expected error. It'd be great if we could bisect if possible.
18 out of backtrace frames: <details<summaryDetails</summary</detailsProbably not very useful.
I believe that we still have the bors artifacts, so it should be possible to use . ping cleanup
Error: Only Rust team members can ping teams. Please let know if you're having trouble with this bot.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-07 to nightly-2020-05-08 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
It's likely related -- cc
Does fix this issue?
Hm, I don't think so, let me confirm it. -- Confirmed with the master toolchain, it doesn't fix this.
I believe we need to wrap and the similar invocations further down with
Change:
let count = (niche_variants.end().as_u32() - niche_variants.start().as_u32() + 1) as u128; <del> // FIXME(#62691) use the largest niche across all fields, // not just the first one. for (field_index, &field) in variants[i].iter().enumerate() { let niche = match &field.largest_niche { Some(niche) => niche, _ => continue, }; let (niche_start, niche_scalar) = match niche.reserve(self, count) { Some(pair) => pair, None => continue, }; </del> <ins> // Find the field with the largest niche let niche_candidate = variants[i] .iter() .enumerate() .filter_map(|(j, &field)| Some((j, field.largest_niche.as_ref()?))) .max_by_key(|(_, niche)| niche.available(dl)); if let Some((field_index, niche, (niche_start, niche_scalar))) = niche_candidate.and_then(|(field_index, niche)| { Some((field_index, niche, niche.reserve(self, count)?)) }) { </ins> let mut align = dl.aggregate_align; let st = variants .iter_enumerated()

Discussion:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(
Change:
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct = note: this struct has unspecified layout note: the type is defined here <del> --> $DIR/lint-ctypes-94223.rs:27:1 </del> <ins> --> $DIR/lint-ctypes-94223.rs:34:1 </ins> | LL | pub struct FfiUnsafe; | ^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 11 previous errors </del> <ins> error: aborting due to 12 previous errors </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. -- at <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2023-01-01 to nightly-2023-08-14 regressed nightly: nightly-2023-07-04 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
As referenced in the other issue this now also happens on stable since = 1.70. The culprint seems to be this type alias: Removing the reference in the Option works around this panic.
Here's a minimal example that reproduces the issue: Interestingly, this only happens while the function is extern "C".
WG-prioritization assigning priority (). cc: for the bisection pointing to label -I-prioritize +P-high
claim
The panic originates in the on this line: It happens because returns which it does because normalization of fails. The reason the normalization fails is because trait resolution fails for the projection due to not being sufficiently bound. If, for example, I change in 's example above to by adding a bound, the panic goes away as trait resolution succeeds now. Since the normalization failure can be legitimate as in this case, I feel this unwrap: should be removed to fix the issue. However, I'm not sure what the enclosing method should do upon receiving a from . I'd presume it should return . Please review and let me know if this analysis makes sense. cc:
Closely related PR: . It fixes an ICE due to similar causes but on a different line. In fact the very next line.
Yeah, I think making not and just bubble up the is the right behavior here.
Change:
#[test] fn test_iterate() { <del> let mut it = iterate(|x| x * 2, 1u); </del> <ins> let mut it = iterate(1u, |x| x * 2); </ins> assert_eq!(it.next(), Some(1u)); assert_eq!(it.next(), Some(2u)); assert_eq!(it.next(), Some(4u));

Discussion:
It's currently but the convention is (and it is more readable) to have the closure last, i.e. .
Change:
<ins> // run-pass #![feature(const_fn)] #![feature(const_unreachable_unchecked)] const unsafe fn foo(x: bool) -> bool { match x { true => true, false => std::hint::unreachable_unchecked(), } } const BAR: bool = unsafe { foo(true) }; fn main() { assert_eq!(BAR, true); } </ins>

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
tarball.add_file(&cargo, "bin", 0o755); tarball.add_file(etc.join("_cargo"), "share/zsh/site-functions", 0o644); <del> tarball.add_renamed_file(etc.join("cargo.bashcomp.sh"), "etc/bash_completion.d", "cargo"); </del> <ins> tarball.add_renamed_file( etc.join("cargo.bashcomp.sh"), "src/etc/bash_completion.d", "cargo", ); </ins> tarball.add_dir(etc.join("man"), "share/man/man1"); tarball.add_legal_and_readme_to("share/doc/cargo");

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, due to installing from source: with the installation commands: ./configure --prefix=/path/to/installation/using/a/non/root/user/rust-1.69.0 --enable-extended python3 build python3 install I expected to see the installation succeed. Instead, the installation failed when processing the cargo installation. Only the cargo installation uses the function, so the problem appears isolated to that single function call, due to the implementation of . <!-- 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
Seems related to
Thank you for pointing-out ! It is the same problem. Closing this as a duplicate.
It is not an issue, but this PR will fix this issue. Reopening to keep track of progress.
Does the PR fix the issue?
When is combined with , the rustc release is able to compile and install successfully (from linked at ) as shown below:
Change:
source: RegionNameSource::AnonRegionFromYieldTy(yield_span, type_name), }) } <ins> fn give_name_if_anonymous_region_appears_in_impl_signature( &self, fr: RegionVid, ) -> Option<RegionName> { let ty::ReEarlyBound(region) = *self.to_error_region(fr)? else { return None; }; if region.has_name() { return None; }; let tcx = self.infcx.tcx; let body_parent_did = tcx.opt_parent(self.mir_def_id().to_def_id())?; if tcx.parent(region.def_id) != body_parent_did || tcx.def_kind(body_parent_did) != DefKind::Impl { return None; } let mut found = false; tcx.fold_regions(tcx.type_of(body_parent_did), &mut true, |r: ty::Region<'tcx>, _| { if *r == ty::ReEarlyBound(region) { found = true; } r }); Some(RegionName { name: self.synthesize_region_name(), source: RegionNameSource::AnonRegionFromImplSignature( tcx.def_span(region.def_id), // FIXME(compiler-errors): Does this ever actually show up // anywhere other than the self type? I couldn't create an // example of a `'_` in the impl's trait being referenceable. if found { "self type" } else { "header" }, ), }) } </ins> }

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
<ins> // run-rustfix #![allow(dead_code, unused_variables)] fn foo1(bar: str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo2(_bar: str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo3(_: str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn main() {} </ins>

Discussion:
() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim