jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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. --: <details<summary<strongBacktrace</strong</summary<p(F# highlighting looks reasonably nice) </p</details
modify labels +requires-nightly +F-genericassociatedtypes +F-typealiasimpl_trait
GATs issue triage: not blocking. Works on latest nightly; needs test.
label: +E-needs-test

Discussion:
<ins> #![feature(generic_associated_types)] #![feature(type_alias_impl_trait)] fn main() {} trait A<'a> { type B<'b>: Clone // FIXME(generic_associated_types): Remove one of the below bounds // https://github.com/rust-lang/rust/pull/90678#discussion_r744976085 where 'a: 'b, Self: 'a, Self: 'b; fn a(&'a self) -> Self::B<'a>; } struct C; impl<'a> A<'a> for C { type B<'b> = impl Clone; //~^ ERROR: lifetime bound not satisfied //~| ERROR: could not find defining uses fn a(&'a self) -> Self::B<'a> {} //~ ERROR: non-defining opaque type use in defining scope } </ins>

<ins> error[E0478]: lifetime bound not satisfied --> $DIR/issue-88595.rs:19:5 | LL |     type B<'b> = impl Clone; |     ^^^^^^^^^^^^^^^^^^^^^^^^ | note: lifetime parameter instantiated with the lifetime `'a` as defined here --> $DIR/issue-88595.rs:18:6 | LL | impl<'a> A<'a> for C { |      ^^ note: but lifetime parameter must outlive the lifetime `'b` as defined here --> $DIR/issue-88595.rs:19:12 | LL |     type B<'b> = impl Clone; |            ^^ error: non-defining opaque type use in defining scope --> $DIR/issue-88595.rs:23:23 | LL |     fn a(&'a self) -> Self::B<'a> {} |                       ^^^^^^^^^^^ | note: lifetime used multiple times --> $DIR/issue-88595.rs:18:6 | LL | impl<'a> A<'a> for C { |      ^^ LL |     type B<'b> = impl Clone; |            ^^ error: could not find defining uses --> $DIR/issue-88595.rs:19:18 | LL |     type B<'b> = impl Clone; |                  ^^^^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0478`. </ins>

<ins> // edition:2018 #![feature(generic_associated_types)] #![feature(type_alias_impl_trait)] use std::future::Future; trait MakeFut { type Fut<'a> where Self: 'a; fn make_fut<'a>(&'a self) -> Self::Fut<'a>; } impl MakeFut for &'_ mut () { type Fut<'a> = impl Future<Output = ()>; //~^ ERROR: the type `&mut ()` does not fulfill the required lifetime fn make_fut<'a>(&'a self) -> Self::Fut<'a> { async { () } } } fn main() {} </ins>

<ins> error[E0477]: the type `&mut ()` does not fulfill the required lifetime --> $DIR/issue-90014.rs:14:5 | LL |     type Fut<'a> = impl Future<Output = ()>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: type must outlive the lifetime `'a` as defined here --> $DIR/issue-90014.rs:14:14 | LL |     type Fut<'a> = impl Future<Output = ()>; |              ^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0477`. </ins>
Change:
Building on Windows ( toolchain) causes an ICE: <details<summarybacktrace</summary</detailsBisecting reveals this was injected by (cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
I'll look into it.
Since landed in 1.57, labeling as stable-to-beta regression.
Re-opening to track the beta backport.
fix backported to beta in PR rollup

Discussion:
} if let Some(trait_ref) = trait_ref { <del> push_item_name(tcx, trait_ref.skip_binder().def_id, true, &mut vtable_name); </del> <ins> let trait_ref = tcx.normalize_erasing_late_bound_regions(ty::ParamEnv::reveal_all(), trait_ref); push_item_name(tcx, trait_ref.def_id, true, &mut vtable_name); </ins> visited.clear(); <del> push_generic_params_internal( tcx, trait_ref.skip_binder().substs, &mut vtable_name, &mut visited, ); </del> <ins> push_generic_params_internal(tcx, trait_ref.substs, &mut vtable_name, &mut visited); </ins> } else { vtable_name.push_str("_"); }

// MSVC-LABEL: !DIGlobalVariable(name: "impl$<debug_vtable::Foo, _>::vtable$" // CHECK: !DISubrange(count: 3 <ins> // NONMSVC-LABEL: !DIGlobalVariable(name: "<debug_vtable::bar::{closure#0} as core::ops::function::FnOnce<(core::option::Option<&dyn core::ops::function::Fn<(), Output=()>>)>>::{vtable}" // MSVC-LABEL: !DIGlobalVariable(name: "impl$<debug_vtable::bar::closure$0, core::ops::function::FnOnce<tuple$<enum$<core::option::Option<ref$<dyn$<core::ops::function::Fn<tuple$<>,assoc$<Output,tuple$<> > > > > >, {{.*}}, {{.*}}, Some> > > >::vtable$" </ins> #![crate_type = "lib"] pub struct Foo;

let z: &dyn SomeTraitWithGenerics<u64, i8> = x; (y.method1(), z.method1(), x as &dyn Send) } <ins> // Constructing the debuginfo name for the FnOnce vtable below initially caused an ICE on MSVC // because the trait type contains a late bound region that needed to be erased before the type // layout for the niche enum `Option<&dyn Fn()>` could be computed. pub fn bar() -> Box<dyn FnOnce(Option<&dyn Fn()>)> { Box::new(|_x: Option<&dyn Fn()>| {}) } </ins>
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --This code: () Panics with the message from inside futures-rs. The code driving this particular object is also in futures-rs , but this code couldn't possibly result in the panic that we see. That would require the Join future to get polled after it was completed, but that future is only ed, so this should never happen. This is a regression from stable to beta, bisected to PR . It still exists in nightly. <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-beta -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this regression is in the newly-promoted-to-beta 1.57, not 1.56 which is being released as stable this week.
Minimized:
claim
label: -A-async-await
Assigning as and removing .
(Posted in the fix PR as well for redundancy) For the record, while I may have seen I do not recall ever reviewing the change it links to (), which is where the bug was introduced (I was tipped off by the closures which did not exist in the version of that PR I reviewed).
the fix still needs a backport
This was backported in

Discussion:
// In practice this means that enums with `count > 1` are unlikely to claim niche zero, since they have to fit perfectly. // If niche zero is already reserved, the selection of bounds are of little interest. let move_start = |v: WrappingRange| { <del> let start = v.start.wrapping_sub(1) & max_value; </del> <ins> let start = v.start.wrapping_sub(count) & max_value; </ins> Some((start, Scalar { value, valid_range: v.with_start(start) })) }; let move_end = |v: WrappingRange| {

<ins> // run-pass #[repr(u32)] pub enum Foo { // Greater than or equal to 2 A = 2, } pub enum Bar { A(Foo), // More than two const variants B, C, } fn main() { match Bar::A(Foo::A) { Bar::A(_) => (), _ => unreachable!(), } } </ins>
Change:
The following code : run under miri reports UB:
cc
The underlying issue is in : this has the same error.
This is actually tricky, I think -- an unexpected consequence of the Stacked Borrows rules. When is being passed to , it gets reborrowed and then "protected", meaning the mutable reference passed to must outlive that function call. But then it goes ahead and reads the old reference from directly via the raw pointer, which reborrows that reference, therefore invalidating the earlier other reborrow. There is a sense in which the reborrow of passed to is truly invalidated here -- and in fact it is not possible to access that value later: I am surprised by this error, since usually mutable references are reborrowed, not moved. But it seems here it somehow knows not to reborrow?
cc -- could be related? Fully-qualifying the call with yields a different error (where reborrowed rather than moved), so it seems at least partially related:
Ah, yes that's it. Not that the exact error makes such a big difference, but now at least it is more clear that the reborrow makes later uses of fail.
Type inference will prevent reborrowing from happening.
Could we say that a mutable reference that comes from a type parameter shouldn't be protected?
That seems a bit strange, to have a particular instance of a generic function behave differently than if that same instance had been written monomorphically.
Well, generic function is different from an monomorphic function. In a monomorphic function you can dereference the reference, but (if there're no bounds) then in generic function you just have and would need to treat it "just as data" and the fact it's monomorphized to be a reference shouldn't be special. I.e. I would expect a to behave more closely to or than a dedicated, say type. It is strange to me that two monomorphized versions of the same function should behave differently.
Sure, a monomorphic function can be changed to do more things. But when a generic and monomorphic function are the same in the source code, they also should behave the same. They use completely different types, so them behaving the same does not even make sense? Like, e.g., will literally return different values. In general, two monomorphized versions of the same function have no choice but to behave differently. To give another example, if you a to , then again of course this is UB for some (e.g., ) but totally fine for others (e.g., ).

Discussion:
// We replace self[index] with the last element. Note that if the // bounds check above succeeds there must be a last element (which // can be self[index] itself). <del> let last = ptr::read(self.as_ptr().add(len - 1)); let hole = self.as_mut_ptr().add(index); </del> <ins> let value = ptr::read(self.as_ptr().add(index)); let base_ptr = self.as_mut_ptr(); ptr::copy(base_ptr.add(len - 1), base_ptr.add(index), 1); </ins> self.set_len(len - 1); <del> ptr::replace(hole, last) </del> <ins> value </ins> } }
Change:
Bisected to a rollup, but I think it's very likely to be . cc searched nightlies: from nightly-2021-10-01 to nightly-2021-10-19 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The old suggestion was actually incorrect because it suggested , which is a private import. However, the new error is "more incorrect" IMO since it says something confusing (and incorrect).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Discussion:
return; } <ins> // #90113: Do not count an inaccessible reexported item as a candidate. if let NameBindingKind::Import { binding, .. } = name_binding.kind { if this.is_accessible_from(binding.vis, parent_scope.module) && !this.is_accessible_from(name_binding.vis, parent_scope.module) { return; } } </ins> // collect results based on the filter function // avoid suggesting anything from the same module in which we are resolving if ident.name == lookup_ident.name

<ins> mod list { pub use self::List::Cons; pub enum List<T> { Cons(T, Box<List<T>>), } } mod alias { use crate::list::List; pub type Foo = List<String>; } fn foo(l: crate::alias::Foo) { match l { Cons(..) => {} //~ ERROR: cannot find tuple struct or tuple variant `Cons` in this scope } } fn main() {} </ins>

<ins> error[E0531]: cannot find tuple struct or tuple variant `Cons` in this scope --> $DIR/issue-90113.rs:17:9 | LL |         Cons(..) => {} |         ^^^^ not found in this scope | help: consider importing this tuple variant | LL | use list::List::Cons; | error: aborting due to previous error For more information about this error, try `rustc --explain E0531`. </ins>
Change:
Prior to Rust 1.56, I could use values when defining rkyv structs. However, in Rust 1.56, this is no longer allowed. I tried this code: I expected to see this happen: Prior to Rust 1.56, this compiled. Instead, this happened: The following error appears: It most recently worked on: Rust 1.55 : <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Further information: This is using the crate. We use an older , however this still occurs with the latest version.
Bisected to . label +E-needs-mcve
Reproducer without macros, but still dependent on rkyv:
Reduced: Also, if you remove one of the lines, the code still compiles on 1.55 but the error on 1.56 changes to: label regression-from-stable-to-stable (not sure what happened with rustbot and the labels above)
label -E-needs-mcve
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Ok, I know what is the problem and have a fix. Apparently when looking for implementation for compiler considers candidates: one for top-level impl and two s. Before was using that was enough to discard the two s. But changed it to use instead, which is pessimistic, so now the compiler drops the global impl instead (because is not sure) and then can't decide between the two s.
Funny thing is it seems like it's fixed already in the master branch... Trying to bisect what fixed it to better understand if my change is needed after all.
also fixes it.

Discussion:
// Check if a bound would previously have been removed when normalizing // the param_env so that it can be given the lowest priority. See // #50825 for the motivation for this. <del> let is_global = |cand: &ty::PolyTraitRef<'_>| cand.is_known_global() && !cand.has_late_bound_regions(); </del> <ins> let is_global = |cand: &ty::PolyTraitRef<'tcx>| { cand.is_global(self.infcx.tcx) && !cand.has_late_bound_regions() }; </ins> // (*) Prefer `BuiltinCandidate { has_nested: false }`, `PointeeCandidate`, // and `DiscriminantKindCandidate` to anything else.

<ins> // check-pass pub trait Archive { type Archived; } impl<T> Archive for Option<T> { type Archived = (); } pub type Archived<T> = <T as Archive>::Archived; pub trait Deserialize<D> {} const ARRAY_SIZE: usize = 32; impl<__D> Deserialize<__D> for () where Option<[u8; ARRAY_SIZE]>: Archive, Archived<Option<[u8; ARRAY_SIZE]>>: Deserialize<__D>, { } fn main() {} </ins>

<ins> // check-pass pub trait Archive { type Archived; } impl<T> Archive for Option<T> { type Archived = (); } pub type Archived<T> = <T as Archive>::Archived; pub trait Deserialize<D> {} const ARRAY_SIZE: usize = 32; impl<__D> Deserialize<__D> for () where Option<[u8; ARRAY_SIZE]>: Archive, Option<[u8; ARRAY_SIZE]>: Archive, Archived<Option<[u8; ARRAY_SIZE]>>: Deserialize<__D>, { } fn main() {} </ins>
Change:
<!-- 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. -- On stable the code produces the following error as expected: <details<summary<strongExpected result</strong</summary<p</p</details<!-- 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</detailssearched nightlies: from nightly-2021-10-04 to nightly-2021-10-23 regressed nightly: nightly-2021-10-16 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Also ICEs on beta. label regression-from-stable-to-beta
Interesting, this is rustc now, right? There has been as similar rustdoc ice:
Yes, this can be hit with or for example. I tried running the code in , but it seems to have been fixed by now.
claim I'll try to take a look at this.

Discussion:
.. }, method, <del> )) if Some(recv_ty.def_id()) == pin_did && method.ident.name == sym::new => { </del> <ins> )) if recv_ty.opt_def_id() == pin_did && method.ident.name == sym::new => { </ins> err.span_suggestion( fn_name.span, "use `Box::pin` to pin and box this expression",

<ins> // Checks that we do not ICE when comparing `Self` to `Pin` // edition:2021 struct S; impl S { fn foo(_: Box<Option<S>>) {} fn bar() { Self::foo(None) //~ ERROR mismatched types } } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-90213-expected-boxfuture-self-ice.rs:9:19 | LL |         Self::foo(None) |                   ^^^^ expected struct `Box`, found enum `Option` | = note: expected struct `Box<Option<S>>` found enum `Option<_>` = note: for more on the distinction between the stack and the heap, read https://doc.rust-lang.org/book/ch15-01-box.html, https://doc.rust-lang.org/rust-by-example/std/box.html, and https://doc.rust-lang.org/std/boxed/index.html help: store this in the heap by calling `Box::new` | LL |         Self::foo(Box::new(None)) |                   +++++++++    + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
While looking at the standard library documentation of I found some trait implementations of documented there. These belong to the crate. I do not think this trait implementation belongs in the standard library documentation. See This is also present in the standard library documentation that installs locally. The Version string on is at the time of writing. I was told on the discord channel to tag in this issue.
They should definitely not be displayed.
After taking a look, I have to admit that I have no idea how to handle this... We could add on implementation I guess, but do we want this? Maybe you have an idea ?
This seems related to
Thanks for the link!
I think this is exactly what  is for, isn't it?
It is, but the crate might still want to show these impls though. EDIT: nevermind, you're absolutely right I confused it with ...

Discussion:
#[allow(unused_extern_crates)] extern crate unwind; <ins> #[doc(masked)] #[allow(unused_extern_crates)] extern crate miniz_oxide; </ins> // During testing, this crate is not actually the "real" std library, but rather // it links to the real std library, which was compiled from this same source // code. So any lang items std defines are conditionally excluded (or else they
Change:
When using to insert another file as a docstring, it seems that the last line gets cut off if it contains only one character. : : (Both files have a trailing new line.) : Running on the above produces output like this: That is, the file gets included correctly, but the file loses its second line. This bug only seems to happen if the last line is a single character. Reproduced this bug on both stable and nightly. : :
does this also happen for string constants and other things using ? Or just the doc attribute?
Oh I didn't think to check that. Looks like the bug doesn't reproduce with a non- use of . This runs without error:
Ok cool and follow-up question - does have the same issue? Or only with include_str?
That does reproduce the issue. The rustdoc output looks like .
cc this is probably related to your changes to try and make the indentation smarter.
You mean removing the smart indent? ;) But yes, very likely. I'll take a look.

Discussion:
i += 1; } // like the first, a last line of all stars should be omitted <del> if j > i && lines[j - 1].chars().skip(1).all(|c| c == '*') { </del> <ins> if j > i && !lines[j - 1].is_empty() && lines[j - 1].chars().all(|c| c == '*') { </ins> j -= 1; }

<ins> #![crate_name = "foo"] #![no_std] // @has 'foo/fn.foo.html' // @has - '//*[@class="docblock"]' 'inc2 x' #[doc = include_str!("short-line.md")] pub fn foo() {} </ins>
Change:
The failing assert is I don't know why my Windows is special in this way and the symlink contains the drive letter in lowercase, this version of Windows was pre-installed on an HP laptop. Anyway, the Rust test suite fails due to this easily fixable mismatch. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Other links in the test have the same lowercase issue:
It might not be a good idea to hardcode these paths in general. I'm not sure what the state of things is with windows 10 but with windows 7 it was at least possible to install on other drives than and so they might not even exist.
Whichever drive you install Windows on, they system drive will be labelled from within the running system. And certain directories must be on the system drive, e.g. the Windows and Users folders. However those folders could, potentially, be called something different. It's happened before with "Documents and Settings" being renamed "Users", hence the existence of all the symlinks being tested. That said, I think it's pretty unlikely to change again anytime soon. But it is possible. In any case the simple fix here is to compare s rather than ings.
claim

Discussion:
fn read_link() { if cfg!(windows) { // directory symlink <del> assert_eq!( check!(fs::read_link(r"C:UsersAll Users")).to_str().unwrap(), r"C:ProgramData" ); </del> <ins> assert_eq!(check!(fs::read_link(r"C:UsersAll Users")), Path::new(r"C:ProgramData")); </ins> // junction <del> assert_eq!( check!(fs::read_link(r"C:UsersDefault User")).to_str().unwrap(), r"C:UsersDefault" ); </del> <ins> assert_eq!(check!(fs::read_link(r"C:UsersDefault User")), Path::new(r"C:UsersDefault")); </ins> // junction with special permissions <del> assert_eq!( check!(fs::read_link(r"C:Documents and Settings")).to_str().unwrap(), r"C:Users" ); </del> <ins> assert_eq!(check!(fs::read_link(r"C:Documents and Settings")), Path::new(r"C:Users")); </ins> } let tmpdir = tmpdir(); let link = tmpdir.join("link");
Change:
I tried to build on a new machine. Got this message: Which I'm used to. I googled a bit, installed , figured out how to get PATH set up, et cetera. Then I built again. And got this: I'm not sure, but: Isn't solely necessary in our build for building LLVM? if that's the case, then shouldn't both the failure and the failure be providing the same level of feedback (namely, suggesting that one side-step building LLVM altogether as an alternative option to downloading and installing )? (Or is the assumption here that will be used by so many crates, people should just bite bullet and install it? Even so, we could give better guidance up front about where to look for it.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think cmake intentionally has a worse error, it's just that a bunch of people building from source for the first time have been confused what ninja is and where to get it. If you made a PR improving the error for cmake I'd approve it :)
label: +E-easy
claim
Hello I'd like to claim this issue if you're interested in releasing it.
Sorry about that Gave it a try but got sidetracked and wasn't really interested in doing it anymore
claim

Discussion:
.any(|build_llvm_ourselves| build_llvm_ourselves); let need_cmake = building_llvm || build.config.any_sanitizers_enabled(); if need_cmake { <del> cmd_finder.must_have("cmake"); </del> <ins> if cmd_finder.maybe_have("cmake").is_none() { eprintln!( " Couldn't find required command: cmake You should install cmake, or set `download-ci-llvm = true` in the `[llvm]` section section of `config.toml` to download LLVM rather than building it. " ); std::process::exit(1); } </ins> } build.config.python = build