jiebi/CodeConvo huggingface dataset:
Change:
// so its artifacts can't be reused. if builder.download_rustc() && compiler.stage != 0 { // Copy the existing artifacts instead of rebuilding them. <del> // NOTE: this path is only taken for tools linking to rustc-dev. builder.ensure(Sysroot { compiler }); </del> <ins> // NOTE: this path is only taken for tools linking to rustc-dev (including ui-fulldeps tests). let sysroot = builder.ensure(Sysroot { compiler }); let ci_rustc_dir = builder.out.join(&*builder.build.build.triple).join("ci-rustc"); for file in builder.config.rustc_dev_contents() { let src = ci_rustc_dir.join(&file); let dst = sysroot.join(file); if src.is_dir() { t!(fs::create_dir_all(dst)); } else { builder.copy(&src, &dst); } } </ins> return; }

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.
Change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] trait Bar<O> {} impl<O> Bar<O> for [u8; O] {} //~^ ERROR expected value, found type parameter `O` struct Foo<const O: usize> {} impl<const O: usize> Foo<O> where [u8; O]: Bar<[(); O]>, { fn foo() {} } fn main() { Foo::foo(); } </ins>

Discussion:
ran cargo-bisect-rustc on this. It reports: searched nightlies: from nightly-2019-11-18 to nightly-2019-12-02 regressed nightly: nightly-2019-12-02 searched commits: from to regressed commit:
i.e. this was injected by (rollup) PR its not immediately obvious to me which associated PR from that rollup is to blame. Maybe ?
The ICE no longer occurs with latest nightly, I guess fixed it. Marked as E-needs-test.
Change:
} #[test] <ins> fn test_recv_try_iter() { let (request_tx, request_rx) = channel(); let (response_tx, response_rx) = channel(); // Request `x`s until we have `6`. let t = thread::spawn(move|| { let mut count = 0; loop { for x in response_rx.try_iter() { count += x; if count == 6 { return count; } } request_tx.send(()).unwrap(); } }); for _ in request_rx.iter() { if response_tx.send(2).is_err() { break; } } assert_eq!(t.join().unwrap(), 6); } #[test] </ins> fn test_recv_into_iter_owned() { let mut iter = { let (tx, rx) = channel::<i32>();

Discussion:
Tracking issue for the new non-blocking iterator API introduced in . The API is currently gated behind the unstable feature. The API includes: - cc
Hey folks, just thought I'd ping this and ask if there's anything I can do to help guide this towards stable? Would love to start using it, but no worries if it's just low on the priority list :+1:
I'd like to know the same thing as mitchmindtree. Is this being guide towards stable?
fcp merge Seems like a nifty API to have!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell: psst I wasn't able to add the label, please do so.
The final comment period is now complete.
Change:
) }); let index_ty = self.fcx.resolve_vars_if_possible(index_ty); <ins> let resolved_base_ty = self.resolve(*base_ty, &base.span); </ins> <del> if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize { </del> <ins> if self.is_builtin_index(&typeck_results, e, resolved_base_ty, index_ty) { </ins> // Remove the method call record typeck_results.type_dependent_defs_mut().remove(e.hir_id); typeck_results.node_substs_mut().remove(e.hir_id);

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<del> Subproject commit d8e6e4cfcd83d555bd7717ea24224b777ed75773 </del> <ins> Subproject commit 1ff81c1b6d7abdcc9ee47f4a8ab175082cad4421 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Change:
<ins> fn main() { let mut i: i64; // Expected type is an inference variable `?T` // because the `match` is used as a statement. // This is the "initial" type of the `coercion`. match i { // Add `bool` to the overall `coercion`. 0 => true, // Necessary to cause the ICE: 1 => true, // Suppose that we had `let _: bool = match i { ... }`. // In that case, as the expected type would be `bool`, // we would suggest `i == 1` as a fix. // // However, no type error happens when checking `i = 1` because `expected == ?T`, // which will unify with `typeof(i = 1) == ()`. // // However, in #67273, we would delay the unification of this arm with the above // because we used the hitherto accumulated coercion as opposed to the "initial" type. 2 => i = 1, //~^ ERROR match arms have incompatible types _ => (), } } </ins>

Discussion:
Code: <details<summaryBacktrace</summary</details
modify labels: I-ICE C-Bug T-compiler A-mir Regression from 1.34 to 1.35
Additionally, this one ICEs with different error message: () <details<summaryBacktrace</summary</details
This code should not get all the way to codegen without an error
Another, different ICE? <details<summaryBacktrace</summary</summary
Regression somewhere between ...
looks suspicious, cc In particular, maybe is falsly returning here since the expected type is due to the other match arms?
Change:
}; let sp = hir.span(id); let sp = if let Some(first_bound) = has_bounds { <del> // `sp` only covers `T`, change it so that it covers // `T:` when appropriate </del> sp.until(first_bound.span()) <ins> } else if let Some(colon_sp) = // If the generic param is declared with a colon but without bounds: // fn foo<T:>(t: T) { ... } param.colon_span_for_suggestions( self.inh.tcx.sess.source_map(), ) { sp.to(colon_sp) </ins> } else { sp };

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Note: The bound is treated incorrectly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
You mean that does not handle correctly, right?
Correct, the suggestion reads which is not syntactical. The fix would be to detect this case and correctly suggest
It's my first time contributing and i was taking a look at and didn't find a way to detect . So i ended up adding a flag to , setting it in and checking the flag in to handle the case. Does that seem reasonable?
Adding a new flag to seems a bit heavy. I was thinking you could one of the methods on  to detect if there is a colon following the generic param. Also hmm... I think was also looking at ... I opened up this issue before he said that he was trying to , though I'm not sure if in general or just a specific case in something he was working on (i.e. another suggestion). Perhaps he could comment to see if he's already solved this, in order to deduplicate work?
So. I was fixing the same problem in and I just got a working fix! My solution is to use in order to find the span of . It may be hacky, but I think it's good enough for diagnostics. It seems like my fix doesn't fix this issue, because this suggestion is created using different API (), but it should be easy to extend it to this case too. For example could use internally ( produces better suggestions anyway :D). I'll try to clean my fix & create a PR today.
I took a look at your PR, that's way better than my solution. I will use the method you to to fix this issue if you aren't working on it as well.
Change:
#![unstable(issue = "none", feature = "windows_handle")] <ins> #[cfg(test)] mod tests; </ins> use crate::cmp; use crate::io::{self, ErrorKind, IoSlice, IoSliceMut, Read, ReadBuf}; use crate::mem;

Discussion:
on windows. with and rename it back to git bash I expected to see this happen: my really long string gets printed twice, followed by a clean exit Instead, this happened: some amount of my really long string gets printed, followed by: The test case, while simple, does appear to have a minimum size requirement to trigger this crash. Shrinking the string will cause it to stop crashing. I'm using in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too. Redirecting to a file instead of a pipe seems to not trigger this crash. Using is not necessary to trigger the crash, running the built executable directly also crashes. This PR this new error condition: I am not the only one seeing this new error message: modify labels: +regression-from-stable-to-stable +O-windows
I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with . In my original bug report, I suggested calling once if returned , since that will at least resolve the pending IO correctly in the case where the file is not being used for other IOs concurrently. This would cover this and other cases at least as well as the original code calling . This isn't perfect, since of course takes , so you can probably deadlock in a multi-threaded process in this async pipe configuration. But it would at least avoid the common case. However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped?
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap.
Thanks for fixing the issue quickly. When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? Or will we have to wait for a fix in 1.63?
PR was nominated and accepted for both beta and stable backport by T-libs. Leaving this open until those play out. Assigning P-high for the same reasons it was accepted for backports.
Change:
compiler: build_compiler, target: target_compiler.host, }); <del> builder.copy(&lld_wrapper_exe, &gcc_ld_dir.join(exe("ld", target_compiler.host))); </del> <ins> for name in crate::LLD_FILE_NAMES { builder.copy(&lld_wrapper_exe, &gcc_ld_dir.join(exe(name, target_compiler.host))); } </ins> } if builder.config.rust_codegen_backends.contains(&INTERNER.intern_str("llvm")) {

Discussion:
lld-wrapper is unhappy. I tried this code: Instead, this happened: <!-- 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</detailsNote that this worked for months. This is a regression for me.
Is this issue related to ?
I found no traces of the last working nightly.
Is this issue related to It's certainly somehow related because didn't exist before that, but I don't know how it can happen, is in fact passed as snipped posted in the original message shows.
Do you need more information?
Do you need more information? Yes, output of lld-wrapper with inserted here (You don't need whole compiler build to rebuild lld-wrapper, it's a single-file standalone program, it can be built with directly or with , and then temporarily put into the directory.)
Note that main:rs73 is the failure case.
I see. The command line is to long so it's moved to a temporary file and passed with . Neither lld-wrapper nor original (flavorless) lld support specifying the flavor inside the file. Due to the way in which and work for naked LLD never gets into the file, we should do something similar with too.
I don't know whether rustc has utilities for handling response files
Ok, it's actually clang that packs the command line into a , not rustc, so we cannot control or predict when it happens. That's pretty bad. I guess we'll have to partially revert and use something based on file names, like
Fixed in Sorry for the delay, I should have fixed this two months ago. could you test the fix on Darwin?
Change:
<ins> // Copyright 2018 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. // https://github.com/rust-lang/rust/issues/49153 // revisions:rpass1 rpass2 extern "C" { pub static __ImageBase: u8; } pub static FOO: &'static u8 = unsafe { &__ImageBase }; fn main() {} </ins>

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
if type_allowed_to_implement_copy( cx.tcx, <del> param_env, </del> <ins> cx.param_env, </ins> ty, traits::ObligationCause::misc(item.span, item.owner_id.def_id), )

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --This appears to be an issue in the lint, possibly it assuming can be normalized, when due to the bound and the lack of implementation , the type is effectively <!-- 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. --: locally <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Still crashes with , although the Ice is a bit different.
I would appreciate if you opened a new issue for that, and shared the backtrace, etc there instead.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-99073.rs:6:13 | LL | fn fix<F: Fn(G), G: Fn()>(f: F) -> impl Fn() { |                                    --------- the expected opaque type LL |     move || f(fix(&f)) |             ^^^^^^^^^^ types differ | = note: expected opaque type `impl Fn()` found type parameter `G` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> error[E0057]: this function takes 1 parameter but 0 parameters were supplied --> $DIR/E0057.rs:13:13 | 13 |     let a = f(); //~ ERROR E0057 |             ^^^ | = note: the following parameter type was expected: (_,) error[E0057]: this function takes 1 parameter but 2 parameters were supplied --> $DIR/E0057.rs:15:15 | 15 |     let c = f(2, 3); //~ ERROR E0057 |               ^^^^ | = note: the following parameter type was expected: (_,) error: aborting due to 2 previous errors </ins>

Discussion:
From: src/test/compile- Error E0057 needs a span_label, updating it from: To: Bonus 1: The note seems excessive. Check other E0057 errors. If it is not needed, remove the note. Bonus 2: The span for the error could likely focus on the parameters rather than the whole call.
I'm taking this one.
I think I've got most of this fix/working, but I'm having a problem fixing one of the unit test cases - issue- The other related test cases (issue-, issue-4935, method-call-err-msg, not-enough-arguments, overloaded-calls-bad and variadic-ffi-3) I was able to fix by following your blog guide. For some reason, issue-3044 is 'different' and I don't understand why. Not sure how to proceed...
- can you show the errors you get when you try to get issue-3044 to pass?
I think I fixed the problem. I'm now trying to get my code checked in and pushed to by fork. Having some ssh key/cert issues. I think once I do that, I can do a PR?
I just submitted a PR, but not sure if I did it correctly.
The note of and this one are printed by the same function, can I modify it to print the expected types directly in the label? I also did the bonus2 part for both E0060 and E0061.
Freeing this one up as part of the final push for .
Actually, according to the comments in maybe this is already closed? , can you confirm?
I think should be closed, and progress is under way in .
Change:
cfg_if::cfg_if! { if #[cfg(any( target_os = "android", <del> target_os = "illumos", </del> target_os = "redox", <del> target_os = "solaris", </del> target_os = "espidf", target_os = "horizon", target_os = "vita",

Discussion:
The for that function state (emphasis mine) However, the way this function gets called does not ensure that the alignment is at least the size of a word. Cc (discovered by failing CI in )
Change:
let rk = self.substs.get(data.index as usize).map(|k| k.unpack()); match rk { Some(GenericArgKind::Lifetime(lt)) => self.shift_region_through_binders(lt), <del> _ => region_param_out_of_range(data), </del> <ins> Some(other) => region_param_invalid(data, other), None => region_param_out_of_range(data, self.substs), </ins> } } _ => r,

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim