jiebi/CodeConvo huggingface dataset:
Change:
// contains unbound type parameters. It could be a slight // optimization to stop iterating early. if let Err(errors) = fulfill_cx.select_all_or_error(infcx) { <del> bug!("Encountered errors `{:?}` resolving bounds after type-checking", errors); </del> <ins> infcx.tcx.sess.delay_span_bug( rustc_span::DUMMY_SP, &format!("Encountered errors `{:?}` resolving bounds after type-checking", errors), ); </ins> } let result = infcx.resolve_vars_if_possible(result);

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Regression occurred in Rust 1.36.0 per testing in Godbolt.
Regression in nightly-2019-04-24 Range: ... found 9 bors merge commits in the specified range commit[0] 2019-04-22UTC: Auto merge of - varkor:tidy-leading-newline, r=alexcrichton commit[1] 2019-04-22UTC: Auto merge of - estebank:continue-eval, r=oli-obk commit[2] 2019-04-23UTC: Auto merge of - euclio:pulldown-cmark, r=GuillaumeGomez commit[3] 2019-04-23UTC: Auto merge of - davazp:fix-sync-all-macos, r=KodrAus commit[4] 2019-04-23UTC: Auto merge of - varkor:tidy-double-trailing-newline, r=kennytm commit[5] 2019-04-23UTC: Auto merge of - estebank:continue-evaluating, r=oli-obk commit[6] 2019-04-23UTC: Auto merge of - stepnivlk:visit_subpats-removal, r=varkor commit[7] 2019-04-23UTC: Auto merge of - davidtwco:issue-, r=oli-obk commit[8] 2019-04-23UTC: Auto merge of - Centril:rollup-akw4r85, r=Centril , , are likely the culprit.
Assigning as and removing .
Change:
<ins> // check-pass // edition:2021 #![feature(async_fn_in_trait)] #![allow(incomplete_features)] pub trait Foo { async fn foo(&mut self); } struct MyFoo<'a>(&'a mut ()); impl<'a> Foo for MyFoo<'a> { async fn foo(&mut self) {} } fn main() {} </ins>

Discussion:
gives Build using the Nightly version: 1.67.0-nightly (2022-10-31 ) label F-asyncfnin_traits C-bug requires-nightly
searched nightlies: from nightly-2022-10-22 to nightly-2022-11-01 regressed nightly: nightly-2022-10-29 searched commit range: regressed commit: ' likely
Another repro which I believe is the same bug:
Change:
<ins> #![feature(type_alias_impl_trait)] #![feature(generic_associated_types)] // See https://github.com/rust-lang/rust/issues/87258#issuecomment-883293367 trait Trait1 {} struct Struct<'b>(&'b ()); impl<'d> Trait1 for Struct<'d> {} pub trait Trait2 { type FooFuture<'a>: Trait1; fn foo<'a>() -> Self::FooFuture<'a>; } impl<'c, S: Trait2> Trait2 for &'c mut S { type FooFuture<'a> = impl Trait1; fn foo<'a>() -> Self::FooFuture<'a> { //~ ERROR Struct(unimplemented!()) } } fn main() {} </ins>

Discussion:
: (Also ) <details<summary<strongBacktrace</strong</summary<p</p</details
Issue might be related (or this may be a duplicate of it).
This seems to be caused by Re-inserting gets rid of the ICE. What was the rationale for deleting that function?
It was replacing inference lifetimes with concrete ones (but wrong ones, as it was using lifetimes from a completely different item). This avoided certain ICEs and was even correct by accident for the example in the doc comment, but it was just papering over the ICEs causing other examples (where the impl trait is outside the current impl block) to fail. I am looking into this new ICE now
I am getting locally before the ICE, so likely the ICE just hides actual errors. Should still fix that of course, but needs more looking into it
I think you need to use 2018 or 2021 edition.
minimized and edition-free: The problem is that typeck runs some of old borrowck/regionck and that just can't handle GAT and associated TAIT being used together. While worked in this specific case, that function won't work if the TAIT were declared outside the impl block and only used, so the following would just hit a different ICE, even though it should be equivalent (except that the defining use scope is the surrounding module instead of just the impl block).
So... turns out this works just fine with nll... I'd say we just wait for that, nll is only blocked on diagnostics, and those are actively being worked on:
I've found this does work if adding a bound on the TAIT: . It seems to me that should be required, so accepting code without it was actually a bug? Also, how does this work with NLL? I add and it still ICEs. (see the playground). Is there anything else needed for enabling NLL?
It seems the linked example on the playground does not ICE on the 2021-08-03 nightly.
that's with the fixed . Without it it ICEs, both with and without NLL
Hum, indeed, the 2 minimized examples Oli mentioned in do ICE with or without .
oof, not sure what I tested here -.- I'll investigate again. But yea, we can just error out instead of ICEing.
This, and no longer ICE since
GATs issue triage: not blocking. Fixed; needs test.
Change:
//~^ ERROR mismatched types foo::<i64>(x_u64.try_into().unwrap()); //~^ ERROR mismatched types <del> foo::<i64>(x_u32.try_into().unwrap()); </del> <ins> foo::<i64>(x_u32.into()); </ins> //~^ ERROR mismatched types <del> foo::<i64>(x_u16.try_into().unwrap()); </del> <ins> foo::<i64>(x_u16.into()); </ins> //~^ ERROR mismatched types <del> foo::<i64>(x_u8.try_into().unwrap()); </del> <ins> foo::<i64>(x_u8.into()); </ins> //~^ ERROR mismatched types foo::<i64>(x_isize.try_into().unwrap()); //~^ ERROR mismatched types

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
dist-install-dir-$(1): PREPARE_MAN_CMD=$(DEFAULT_PREPARE_MAN_CMD) dist-install-dir-$(1): PREPARE_CLEAN=true dist-install-dir-$(1): prepare-base-dir-$(1) docs compiler-docs <del> $$(Q)$$(PREPARE_MAN_CMD) $$(S)COPYRIGHT $$(PREPARE_DEST_DIR) $$(Q)$$(PREPARE_MAN_CMD) $$(S)LICENSE-APACHE $$(PREPARE_DEST_DIR) $$(Q)$$(PREPARE_MAN_CMD) $$(S)LICENSE-MIT $$(PREPARE_DEST_DIR) $$(Q)$$(PREPARE_MAN_CMD) $$(S)README.md $$(PREPARE_DEST_DIR) </del> $$(Q)mkdir -p $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)COPYRIGHT $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)LICENSE-APACHE $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)LICENSE-MIT $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)README.md $$(PREPARE_DEST_DIR)/share/doc/rust <ins> prepare-overlay-$(1): $$(Q)rm -Rf tmp/dist/$$(PKG_NAME)-$(1)-overlay $$(Q)mkdir -p tmp/dist/$$(PKG_NAME)-$(1)-overlay $$(Q)cp $$(S)COPYRIGHT tmp/dist/$$(PKG_NAME)-$(1)-overlay/ $$(Q)cp $$(S)LICENSE-APACHE tmp/dist/$$(PKG_NAME)-$(1)-overlay/ $$(Q)cp $$(S)LICENSE-MIT tmp/dist/$$(PKG_NAME)-$(1)-overlay/ $$(Q)cp $$(S)README.md tmp/dist/$$(PKG_NAME)-$(1)-overlay/ </ins> # This tiny morsel of metadata is used by rust-packaging <del> $$(Q)echo "$(CFG_VERSION)" > $$(PREPARE_DEST_DIR)/version </del> <ins> $$(Q)echo "$(CFG_VERSION)" > tmp/dist/$$(PKG_NAME)-$(1)-overlay/version </ins> <del> dist/$$(PKG_NAME)-$(1).tar.gz: dist-install-dir-$(1) </del> <ins> dist/$$(PKG_NAME)-$(1).tar.gz: dist-install-dir-$(1) prepare-overlay-$(1) </ins> @$(call E, build: $$@) # Copy essential gcc components into installer ifdef CFG_WINDOWSY_$(1)

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:
// Build cargo command. let mut cargo = builder.cargo(compiler, Mode::Rustc, SourceType::InTree, target, "doc"); <del> cargo.env( "RUSTDOCFLAGS", "--document-private-items  --enable-index-page -Zunstable-options", ); </del> <ins> cargo.rustdocflag("--document-private-items"); cargo.rustdocflag("--enable-index-page"); cargo.rustdocflag("-Zunstable-options"); </ins> compile::rustc_cargo(builder, &mut cargo, target); // Only include compiler crates, no dependencies of those, such as `libc`.

Discussion:
Compare , this was intentional Items which are private, like , have disappeared
The warnings is removed in .
The haven't never been public. Not sure if I made it disappeared. cc
Also this page is 404 now. Before it listed all the internal crates.
I don't see how your PR could've done that -- cc I think you recently had a PR touching document-private-items?
The PR just changed some warnings around intra-doc-links, nothing to do with . My suspicion since the index page is gone is that something changed in bootstrap.
I take it back, I did modify href in That was a few weeks ago now and should have documented strictly more items, though.
This is the issue I pointed out in the second part of I clearly didn't explain the issue well enough.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-42764.rs:21:43 | 21 |     this_function_expects_a_double_option(n); |                                           ^ expected enum `DoubleOption`, found usize | = note: expected type `DoubleOption<_>` found type `usize` help: perhaps you meant to use a variant of the expected type | 21 |     this_function_expects_a_double_option(DoubleOption::FirstSome(n)); |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^ 21 |     this_function_expects_a_double_option(DoubleOption::AlternativeSome(n)); |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
produces I think the first item in this list should be
More generally, if the expected type is an enum, and the found type is T, then you should search the enum's variants and check them whether is the sole argument of one of them. If yes, suggest the variant constructor.
I agree we should list variants like that, but I also think the functions suggestions are sort of silly; see
Change:
/// /// Note: it is *crucial* that this API is private, to avoid /// revealing the internal, platform-specific encodings. <ins> #[inline] </ins> fn bytes(&self) -> &[u8] { unsafe { &*(&self.inner as *const _ as *const [u8]) } }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
} if let Some(s) = since && s.as_str() == VERSION_" { <del> let version = option_env!("CFG_VERSION").unwrap_or("<current>"); let version = version.split(' ').next().unwrap(); since = Some(Symbol::intern(&version)); </del> <ins> since = Some(rust_version_symbol()); </ins> } if let Some(feature) = feature {

Discussion:
with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:
Change:
let mut body = EarlyBinder::bind(body.clone()).instantiate(tcx, args); debug!("make_shim({:?}) = {:?}", instance, body); <del> // Run empty passes to mark phase change and perform validation. </del> pm::run_passes( tcx, &mut body, <del> &[], </del> <ins> &[ &abort_unwinding_calls::AbortUnwindingCalls, &add_call_guards::CriticalCallEdges, ], </ins> Some(MirPhase::Runtime(RuntimePhase::Optimized)), );

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. -- <p<details</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</detailsBuild with
can reproduce
can you include a and (for example as a link to a project (+commit), or right here), to be able to reproduce this in the future?
Sorry, forgot to add those, I've attached them
does needs MCVE mean an example not relying on tokio?
yes
Ran a bisect. searched nightlies: from to regressed nightly: searched commit range: ... regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Spent some unforgettable time chopping down 80k lines of tokio code piece by piece, but it was worth it, I hope. Here's an MCVE: : :
Since this seems to be somehow caused by mir drop tracking, cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
{ err.help( "if you want to experiment with in-band lifetime bindings,  <del> add `#![feature(in_band_lifetimes)]` to the crate attributes", </del> <ins> add `#![feature(in_band_lifetimes)]` to the crate attributes", </ins> ); } err.emit();

Discussion:
In case there is an undeclared lifetime in an ADT deriving a wrong help message is emited causes the following error thx, bye
There are two things here: 1) the suggestion should try and identify spans coming from macro expansion and not suggest changes 2) in this case expands to the following: Note the param, which could avoid having any lifetimes and thing would work correctly. We can probably change the desugaring to not specify the lifetime and then we would avoid the second unnecessary duplicated error. would you happen to know if there's any clear negative in doing 2 above and if not, point me in the right direction in to make that change?
I believe that we can't remove the explicit lifetime here. This would allow for even if is only implemented for .
Change:
<ins> #![crate_type = "bin"] #![feature(start)] #![no_std] extern crate alloc; extern crate a; extern crate b; use alloc::vec::Vec; use core::alloc::*; struct Allocator; unsafe impl GlobalAlloc for Allocator { unsafe fn alloc(&self, _: Layout) -> *mut u8 { loop {} } unsafe fn dealloc(&self, _: *mut u8, _: Layout) { loop {} } } #[global_allocator] static ALLOCATOR: Allocator = Allocator; #[start] fn main(argc: isize, _argv: *const *const u8) -> isize { let mut v = Vec::new(); for i in 0..argc { v.push(i); } v.iter().sum() } </ins>

Discussion:
Compiling following under some circumstances result in undefined references to : This linking issue occurs only under for some codegen partitioning but not the others. Reproducing it requires controlling the options that influence the number of codegen units. I can reproduce it with either , or combined with . The weak lang items introduce cyclic dependencies between crates. For example, the alloc crate depends on oom lang item which is defined in std. When linking the std comes first, and it may so happen that object file that contains definition is not used and omitted (this suggest why large number of codegen units is necessary to reproduce the issue), and subsequently alloc crate will fail to link. The [linking code][0] tries to account for cyclic dependencies using start-group and end-group, but as far as I can see it based on assumption that weak lang items dependencies are always reversed, which no longer holds true. [0]:
Change:
<ins> // Test that we show the correct type parameter that couldn't be inferred and that we don't // end up stating nonsense like "type parameter `'a`" which we used to do. trait Trait<'a, T> { fn m(self); } impl<'a, A> Trait<'a, A> for () { fn m(self) {} } fn qualified() { <() as Trait<'static, _>>::m(()); //~^ ERROR type annotations needed //~| NOTE cannot infer type of the type parameter `T` } fn unqualified() { Trait::<'static, _>::m(()); //~^ ERROR type annotations needed //~| NOTE cannot infer type of the type parameter `T` } 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. --<!-- 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. --: This was also tried on with on Rust Playground, with the same error. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsWithout the fully qualified path, see commented code, the error is . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized: Looking into this. claim label D-incorrect
Change:
[rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/ [contributing-bug-reports]: https://rustc-dev-guide.rust-lang.org/contributing.html#bug-reports [issue template]: https://github.com/rust-lang/rust/issues/new/choose <ins> [internals]: https://internals.rust-lang.org [rust-discord]: http://discord.gg/rust-lang [rust-zulip]: https://rust-lang.zulipchat.com </ins>

Discussion:
The , writes: Perhaps it could be a little better. What throws me off in this last sentence, is the term . I'm just a total newbie and just getting to know the terms in this language, so there's no surprise that I can't explain why I am sent one place or another for documentation. So, this is more of a question to those familiar with the constellation of terms, repositories, web sites, and so on. Could this reference explain why it refers to and not anything else. I want to contribute to documentation of what seems to be a core macro (). So, I'm not sure that reading the "Guide to Rustc Development" would be the correct thing to do (even thought I will surely personally read it at some point). The readme of this repository writes: So, in the file, I expect to be directed to instructions on contributing to all or any of the compiler, standard library and documentation. But I am directed to what seems to be — at least by title alone (I haven't read into it, yet) — solely about contributing to the rust compiler. Any suggestion regarding how to improve this — I have the intention of implementing myself. By the way, I am streaming my contribution to rust live at <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I personally think should still redirect to rustc-dev-guide but I think the guide could be improved. IIRC the guide was not updated regarding the split of , and . The guide talks more about contributing to the rust compiler, but personally I think contributing to the library should be straightforward besides not knowing how to build a custom toolchain which isn't always necessary. I believe you can just create a pull request for this if you see fit to close the issue (so it doesn't hang around and become lost).
Yeah, I've very recently run into a similar issue; based on my research, it seems the original content of now lives at https://rustc-dev- which seems like a better entry point. It seems the contribution/developer docs are currently mid-transition from one approach to a new one.

Related:
cc
Having just discovered that the GitHub "first issue" pop-up also links to this document, I just went ahead & created PR which links to the chapter of the dev guide that now holds the content that was previously in . <details! </detailsUntil the "Getting Started" chapter gets re-written to be less -specific, linking to it rather than "Contributing to Rust" chapter seems unnecessarily unwelcoming to new contributors, particularly those who were specifically directed there while creating an issue. (Of course, if the "first issue" link can be customised that's another option for the future.)
claim
Thank you.