jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // Copyright 2015 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. use std::env; use std::fs::{self, TempDir}; fn main() { let td = TempDir::new("create-dir-all-bare").unwrap(); env::set_current_dir(td.path()).unwrap(); fs::create_dir_all("create-dir-all-bare").unwrap(); } </ins>

Related discussion:
text: The following panics: The following works: Apologies in advance if this is intended behavior.
I have found that it also works when using:
This will be fixed by
Code change:
")?; for implementor in foreign { <del> // need to get from a clean::Impl to a clean::Item so i can use render_impl if let Some(t_did) = implementor.impl_.for_.def_id() { if let Some(impl_item) = cache.impls.get(&t_did).and_then(|i| i.iter() .find(|i| i.impl_item.def_id == implementor.def_id)) { let i = &impl_item.impl_item; let impl_ = Impl { impl_item: i.clone() }; let assoc_link = AssocItemLink::GotoSource( i.def_id, &implementor.impl_.provided_trait_methods ); render_impl(w, cx, &impl_, assoc_link, RenderMode::Normal, i.stable_since(), false)?; } </del> <ins> if let Some(i) = implementor2item(&cache, implementor) { let impl_ = Impl { impl_item: i.clone() }; let assoc_link = AssocItemLink::GotoSource( i.def_id, &implementor.impl_.provided_trait_methods ); render_impl(w, cx, &impl_, assoc_link, RenderMode::Normal, i.stable_since(), false)?; </ins> } } }

Related discussion:
text: It should work a bit like IDE's feature that finds everything that implements a given interface.
This should be a fairly small change (the most annoying part has already been done) so i'll open this up as a mentored issue. The bit that writes out the "Implementors" section is in . This is where the known implementors for a given trait are pulled out of the global context and listed out onto the rendered page. The bit that's responsible for creating links is , implemented on a local type. This kind of Item is easily made from the kind of Item that's otherwise worked on in , but there's a catch: The entries in the Implementors list aren't s. They're s, which are only a subset of the things you get on an Item. This is the "most annoying part" i mentioned earlier. Fortunately, i ran into this when creating the "Implementations on Foreign Types" section, so if you scroll up a little in , you can see so i could render the full impl block for them. The task for anyone who wants to take this on is to pull that up a little so that it's used for all the implementors, not just the foreign ones. With a in hand, combine it with the Context to create a and call to generate the link. ( This also helpfully includes the extra HTML bits that will flush the link to the right edge, which is really the final step.) And... that's it! The link should probably go between the and the where clause underneath it, so that it's aligned with the impl line and not the where clause. You may need to also close/open the that's wrapping the whole line to make sure the link itself isn't monospace. If you have any questions, let me know! Either comment here, or hop onto IRC in , or the impl period Gitter under .
Code change:
<ins> error[E0070]: invalid left-hand side of assignment --> $DIR/issue-93486.rs:3:36 | LL |         vec![].last_mut().unwrap() = 3_u8; |         -------------------------- ^ |         | |         cannot assign to this expression error: aborting due to previous error For more information about this error, try `rustc --explain E0070`. </ins>

Related discussion:
text: I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim
Code change:
<ins> //@ edition:2024 //@ compile-flags: -Zunstable-options #![feature(gen_blocks)] const gen fn a() {} //~^ ERROR functions cannot be both `const` and `gen` const async gen fn b() {} //~^ ERROR functions cannot be both `const` and `async gen` fn main() {} </ins>

Related discussion:
text: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly
Code change:
<ins> error[E0567]: auto traits cannot have generic parameters --> $DIR/issue-117789.rs:3:17 | LL | auto trait Trait<P> {} |            -----^^^ help: remove the parameters |            | |            auto trait cannot have generic parameters error[E0658]: auto traits are experimental and possibly buggy --> $DIR/issue-117789.rs:3:1 | LL | auto trait Trait<P> {} | ^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable error: aborting due to 2 previous errors Some errors have detailed explanations: E0567, E0658. For more information about an error, try `rustc --explain E0567`. </ins>

Related discussion:
text: <!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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
Regression in nightly-2022-02-02 found 9 bors merge commits in the specified range commit[0] 2022-01-31: Auto merge of - spastorino:fix-perf-overlap-mode2, r=nikomatsakis commit[1] 2022-01-31: Auto merge of - tmiasko:is-self-recursive, r=ecstatic-morse commit[2] 2022-02-01: Auto merge of - WaffleLapkin:rustcmustimplementoneofchecktarget, r=nagisa commit[3] 2022-02-01: Auto merge of - eddyb:diagbld-scalar-pair, r=jackh726 commit[4] 2022-02-01: Auto merge of - ehuss:rollup-9ecozo9, r=ehuss commit[5] 2022-02-01: Auto merge of - thomcc:chunky-splitz-says-no-checking, r=the8472 commit[6] 2022-02-01: Auto merge of - eholk:disable-drop-range-analysis, r=pnkfelix commit[7] 2022-02-01: Auto merge of - matthiaskrgr:rollup-f7dkn3p, r=matthiaskrgr commit[8] 2022-02-01: Auto merge of - yaahc:Termination-abstraction, r=Mark-Simulacrum ERROR: no CI builds available between and within last 167 days
Actually reduced
Might have been caused by
Ah yes, the assert was there ping :)
Code change:
LL | fn d<'a, const C: S<'a>>() {} |      +++           ++++ <ins> error[E0771]: use of non-static lifetime `'a` in const generic --> $DIR/unusual-rib-combinations.rs:29:22 | LL | struct Bar<const N: &'a (dyn for<'a> Foo<'a>)>; |                      ^^ | = note: for more information, see issue #74052 <https://github.com/rust-lang/rust/issues/74052> </ins> error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/unusual-rib-combinations.rs:7:16 |

Related discussion:
text: This is a fuzzed test case, found with and minimized with . I wasn't able to find any similar issues: : <details<summary<strongBacktrace</strong</summary<p</p</details
This is related to , do we need to keep this ICE or we cover it at here:
The assert was in If you have a reproducer, then it can be to and the assert can be removed.
label +S-bug-has-mcve
Code change:
<ins> // run-pass // edition:2021 struct Props { field_1: u32, //~ WARNING: field is never read: `field_1` field_2: u32, //~ WARNING: field is never read: `field_2` } fn main() { // Test 1 let props_2 = Props { //~ WARNING: unused variable: `props_2` field_1: 1, field_2: 1, }; let _ = || { let _: Props = props_2; }; // Test 2 let mut arr = [1, 3, 4, 5]; let mref = &mut arr; let _c = || match arr { [_, _, _, _] => println!("A") }; println!("{:#?}", mref); } </ins>

Related discussion:
text: Encountered an ICE when building  0.18.0 on edition 2021. I have roughly narrowed it down to the following (can probably be reduced further). Seems to be an issue with closure captures. <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The code can be further simplified to: The issue seems to be around using type annotation. If a type annotation is included, the right hand side of the let statement should always be read.
Is there a runtime check/ is MIR generated for checking if is valid? Because if that's the case then we need props2 to be caputred.
claim I should have a fix later tonight
We found another instance of this ICE that still fails with included: Found trying to migrate . Let me know if you need any more information.
Code change:
<ins> // edition:2021 #![feature(type_alias_impl_trait)] struct CallMe; type ReturnType<'a> = impl std::future::Future<Output = u32> + 'a; type FnType = impl Fn(&u32) -> ReturnType; impl std::ops::Deref for CallMe { type Target = FnType; fn deref(&self) -> &Self::Target { fn inner(val: &u32) -> ReturnType { async move { *val * 2 } } &inner //~ ERROR: expected generic lifetime parameter, found `'_` } } fn main() {} </ins>

Related discussion:
text: <!-- 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. --Explicitly giving lifetimes to with and doing the same on does not fix the ICE either. Version
label +S-bug-has-mcve
Triage: Fixed on the latest nightly, labels: +E-needs-test
Code change:
<ins> // Regression test for issue #124935 // Tests that we do not erroneously emit an error about // missing main function when the mod starts with a `;` ; //~ ERROR expected item, found `;` fn main() { } </ins>

Related discussion:
text: Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.
Code change:
<ins> error: invalid label name `'static` --> $DIR/issue-52437.rs:2:13 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |             ^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52437.rs:2:30 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |                              ^ consider giving this closure parameter a type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>

Related discussion:
text: Binder(<[type error] as ToBytes) This only happens if there are two erroneous functions, if I take out it works fine. It seems like I was trying to do this wrong in the first place since the first function gives an error . Not sure what the right way to do this is. <details<summaryTraceback</summary</details
Tried to reduce it and found a similar case with the same ICE:
Compiler triage: Seems likely to be caused by the need for lazy norm. Marking as p-medium for now.
The ICE doesn't appear on the latest nightly, marked as E-needstest
Code change:
- [rustdoc: Only look at blanket impls in `get_blanket_impls`][83681] - [Rework rustdoc const type][82873] <ins> [85667]: https://github.com/rust-lang/rust/pull/85667 </ins> [83386]: https://github.com/rust-lang/rust/pull/83386 [82771]: https://github.com/rust-lang/rust/pull/82771 [84147]: https://github.com/rust-lang/rust/pull/84147

Related discussion:
text: was re-stabilized in 1.53 after being backed out of 1.51 due to breakage, primarily in the lexical-core crate. This breakage has not been fixed, as far as I can tell, in a vast majority of crates: we're still seeing ~1300 regressions, majority of which are lexical-core in the . There was no discussion on the re-stabilization PR as to whether this level of breakage is acceptable. Comments on the original breakage issue suggest that 0.7.5 was published with a fix, but older versions (0.4, 0.5, 0.6) did not receive similar treatment. The majority of the breakage is in crates locked at 0.7.4; the other versions do share ~400 different crates amongst them, so I think it'd be good to try and help get those series patches as well.
cc Even with 0.7.5 out, it does look like it'll be some time before crates actually update lockfiles (if ever). We don't have a firm policy on whether cargo update being sufficient is "enough" that breakage is OK -- it's a new decision each time pretty much -- but this level of breakage is pretty bad. I guess there may not be much we can do -- IIRC a prelude trait for example adding BITS wouldn't help here, right? Those still introduce conflicts IIRC.
There’s no way around the symbol collision. I think it’s important that stabilize and I’d like us to get out of the way on that. I can take the list of broken crates and start walking it. I can also work on a backport on the older minor series; the reason I did not do so last time is that I was unfamiliar with ’s dependents and didn’t know whether the older series were still in use. What is the most complete course of action we can take to clear for stabilization? Should I yank the conflicting versions in each minor series? Alternatively, would it make sense, and is it even possible, to stabilize only in ?
I wouldn't worry about filing pull requests with 1300+ crates bumping lock files (in part because those are unlikely to get merged quickly). I do think getting patch releases out for each series would already be a significant step forward.
Code change:
- [rustdoc: Only look at blanket impls in `get_blanket_impls`][83681] - [Rework rustdoc const type][82873] <ins> [85667]: https://github.com/rust-lang/rust/pull/85667 </ins> [83386]: https://github.com/rust-lang/rust/pull/83386 [82771]: https://github.com/rust-lang/rust/pull/82771 [84147]: https://github.com/rust-lang/rust/pull/84147

Related discussion:
text: I think yanking is likely not the right step to take at this time. In terms of stabilizing only with - no, that's not really possible. In theory we could stabilize with a different name to avoid all the breakage, but I doubt there's a great name...
The constant would have to be available everywhere, and stable everywhere, but one could think about adding a syntactic hack to interpret the syntax differently depending on the edition, similarly to how it was done for . That would have the desired effect of avoiding breakage on editions 2018 and before, but I'm not sure it's a good idea to double down on adding such hacks.
Attaching it to an edition would not only require compiler changes, but also a lint, a suggestion for rustfix, documentation, etc.
Indeed. Such a policy would be useful. If the decision is that that's fine, we might want to make crater update the lock files when something fails before it considers a crate broken. As another data point: also ignores the lock files and picks the latest matching version of everything.
I assumed the edition route was an infeasible idea but hey might as well get a “no” in writing. I’ll start cutting fixes for the minor series listed in the regression report this weekend.
Thank you! Let me know if I can help.
I'm wondering if we should have a in (just like ) that will make Rustc consider everything that was stabilized in a later version as still unstable. could add it to the uploaded crate if it's not explicitly set, and it makes it easier for crates to track an explicit MSRV.
did you get a chance to release new patch releases on each of the channels to avoid this breakage for the lexical crates, at least? I believe that was the plan but I haven't seen updates on this issue at least :)
Hi; I am so sorry for the radio silence; I have had quite the month since then. Fortunately, Alex Huszagh already did the patch-release issuance back in April. versions , , , and all appear to have the necessary disambiguation in place. These versions also do not appear in the regression report from Bors. I've also run on each of these releases with and passed, so these tips ought to be correct when the constants stabilize. I hope day-before isn't too late and I apologize again for the delay.
Code change:
- [rustdoc: Only look at blanket impls in `get_blanket_impls`][83681] - [Rework rustdoc const type][82873] <ins> [85667]: https://github.com/rust-lang/rust/pull/85667 </ins> [83386]: https://github.com/rust-lang/rust/pull/83386 [82771]: https://github.com/rust-lang/rust/pull/82771 [84147]: https://github.com/rust-lang/rust/pull/84147

Related discussion:
text: If you're comfortable with a "run to un-break your project", then is ready.
No worries. We are planning to move ahead with a compat note indicating cargo update.
Just an FYI: this was fixed ~2 months ago, with , , and . It means that any branch used in the wild should be able to be updated to a compatible version now.
Code change:
<ins> // Out-of-line module is found on the filesystem if passed through a proc macro (issue #58818). // check-pass // aux-build:test-macros.rs #[macro_use] extern crate test_macros; mod outer { identity! { mod inner; } } fn main() {} </ins>

Related discussion:
text: I have this crate layout: src/ parent/ where is an empty file and is: This compiles successfully and we end up with a module at backed by the file But if goes anywhere near a proc macro, it no longer works. where is this macro: The error is: so it is looking for a file corresponding to as though the were not contained inside of . I hit this while working on The same problem does not occur if is defined as a macro_rules macro. Mentioning who may know what is going wrong or whether there is a simple rustc fix.
I never audited the module search code and don't know how it fits into the larger macro story. Even without macros it's , so I'd expect issues in macros as well. I'll investigate.
Still the same behavior as of rustc 1.40.0-nightly ( 2019-10-01).
It's still in my queue, just not with a high enough priority :(
This was fixed by , I'll add a test.
Code change:
} _ => { Err(if self.prev_token_kind == PrevTokenKind::DocComment { <del> self.span_fatal_err(self.prev_span, Error::UselessDocComment) } else { self.expected_ident_found() }) </del> <ins> self.span_fatal_err(self.prev_span, Error::UselessDocComment) } else { self.expected_ident_found() }) </ins> } } }

Related discussion:
text: root: yup-oauth2 - 360 detected crates which regressed due to this; cc <details</details
I think this might have been caused by
I can confirm that is the cause. Patch coming shortly.
Code change:
#[rustc_const_unstable(feature = "const_waker", issue = "102012")] #[unstable(feature = "context_ext", issue = "123392")] pub const fn from(cx: &'a mut Context<'_>) -> Self { <del> let ext = match &mut cx.ext { </del> <ins> let ext = match &mut *cx.ext { </ins> ExtData::Some(ext) => ExtData::Some(*ext), ExtData::None(()) => ExtData::None(()), };

Related discussion:
text: https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.
Code change:
<ins> error[E0599]: no method named `clone` found for struct `issue_69725::Struct<A>` in the current scope --> $DIR/issue-69725.rs:7:32 | LL |     let _ = Struct::<A>::new().clone(); |                                ^^^^^ method not found in `issue_69725::Struct<A>` | ::: $DIR/auxiliary/issue-69725.rs:2:1 | LL | pub struct Struct<A>(A); | ------------------------ doesn't satisfy `issue_69725::Struct<A>: std::clone::Clone` | = note: the method `clone` exists but the following trait bounds were not satisfied: `A: std::clone::Clone` which is required by `issue_69725::Struct<A>: std::clone::Clone` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: I tried code very similar to this: and it produces some type of type checking error when uncommenting the line beginning with . : Backtrace:
The error is likely due to the fact that the trait bounds on don't include for , though the compiler/type checker crashing is still likely a bug.
That code was introduced in , cc Submitted as a quick fix.
I can't get it to work in the same crate, just with two crates, where the first one depends on the other: modify labels: -E-needs-mcve
Thanks I included a test in the PR.
Code change:
use rustc_middle::ty::{self, RegionVid, Ty, TyCtxt, TypeFoldable, TypeVisitableExt}; use rustc_span::Span; <ins> use crate::constraints::graph::{self, NormalConstraintGraph, RegionGraph}; </ins> use crate::dataflow::BorrowIndex; use crate::{ <del> constraints::{ graph::NormalConstraintGraph, ConstraintSccIndex, OutlivesConstraint, OutlivesConstraintSet, }, </del> <ins> constraints::{ConstraintSccIndex, OutlivesConstraint, OutlivesConstraintSet}, </ins> diagnostics::{RegionErrorKind, RegionErrors, UniverseInfo}, member_constraints::{MemberConstraintSet, NllMemberConstraintIndex}, nll::PoloniusOutput,

Related discussion:
text: File: snippet: 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
cc removing the println macro from around the match avoids the ice :thinking:
Fun :)
A more minimal version would be: