jiebi/CodeConvo huggingface dataset:
Change:
} } <del> /// Whether `check_binop` allows overloaded operators to be invoked. </del> <ins> /// Whether `check_binop` is part of an assignment or not. /// Used to know wether we allow user overloads and to print /// better messages on error. </ins> #[deriving(Eq)] <del> enum AllowOverloadedOperatorsFlag { AllowOverloadedOperators, DontAllowOverloadedOperators, </del> <ins> enum IsBinopAssignment{ SimpleBinop, BinopAssignment, </ins> } #[deriving(Clone)]

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
// always None as well let k = CString::new(k.as_bytes())?; unsafe { <del> let _guard = env_read_lock(); </del> <ins> let _guard = env_lock(); </ins> let s = libc::getenv(k.as_ptr()) as *const libc::c_char; let ret = if s.is_null() { None

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
<ins> // check-pass pub trait Trait1 { type C; } struct T1; impl Trait1 for T1 { type C = usize; } pub trait Callback<T: Trait1>: FnMut(<T as Trait1>::C) {} impl<T: Trait1, F: FnMut(<T as Trait1>::C)> Callback<T> for F {} pub struct State<T: Trait1> { callback: Option<Box<dyn Callback<T>>>, } impl<T: Trait1> State<T> { fn new() -> Self { Self { callback: None } } fn test_cb(&mut self, d: <T as Trait1>::C) { (self.callback.as_mut().unwrap())(d) } } fn main() { let mut s = State::<T1>::new(); s.test_cb(1); } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pthe backtrace itself is all </p</details
It's strange, I tried these code in main and it complains about (Compile Error but not ICE) I think the trait is depends on and dyn could resolve this.
Assigning and removing nomination. This was . This one also sounds a bit similar to and which is very old. Would be nice to find if there are duplicates too.
Pinging cleanup to find duplicates ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .
Change:
lint_cap: Option<lint::Level> [TRACKED], describe_lints: bool [UNTRACKED], output_types: OutputTypes [TRACKED], <del> // FIXME(mw): We track this for now but it actually doesn't make too //            much sense: The search path can stay the same while the //            things discovered there might have changed on disk. search_paths: SearchPaths [TRACKED], </del> <ins> search_paths: SearchPaths [UNTRACKED], </ins> libs: Vec<(String, Option<String>, Option<cstore::NativeLibraryKind>)> [TRACKED], maybe_sysroot: Option<PathBuf> [TRACKED],

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.
Change:
<del> //@ known-bug: #124092 //@ compile-flags: -Zvirtual-function-elimination=true -Clto=true //@ only-x86_64 const X: for<'b> fn(&'b ()) = |&()| (); fn main() { let dyn_debug = Box::new(X) as Box<fn(&'static ())> as Box<dyn Send>; } </del>

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --auto-reduced (treereduce-rust): original: 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<!-- query stack: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
<ins> // Copyright 2017 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. pub trait Partial<X: ?Sized>: Copy { } pub trait Complete { type Assoc: Partial<Self>; } impl<T> Partial<T> for T::Assoc where T: Complete { } impl<T> Complete for T { //~ ERROR the trait bound `T: std::marker::Copy` is not satisfied type Assoc = T; } </ins>

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
} let mut head = self.head.index.load(Ordering::Acquire); <del> let mut block = self.head.block.load(Ordering::Acquire); </del> <ins> let mut block = self.head.block.swap(ptr::null_mut(), Ordering::AcqRel); </ins> // If we're going to be dropping messages we need to synchronize with initialization if head >> SHIFT != tail >> SHIFT {

Discussion:
Running this test: with many different seeds in Miri eventually shows: This indicates that the allocation made here does not get freed properly: Specifically when running this with Miri , seed 139 causes the issue. I don't think there is any way for this to be a false positive. Cc
I think this is not recent, it's just hard to trigger. I'll try reproducing on some older versions of rustc+Miri: (Jan 24th): seed 1870 (Nov 22nd, 2023): seed 1020 We can't go back much further since it seems we're not keeping the artifacts long enough for that? So probably this existed ever since landed.
Reproduced this with crossbeam-channel 0.5.11 and miri `.
Change:
<ins> error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/drop_box.rs:1:15 | LL | const fn f<T>(_: Box<T>) {} |               ^           - value is dropped here |               | |               constant functions cannot evaluate destructors error: aborting due to previous error For more information about this error, try `rustc --explain E0493`. </ins>

Discussion:
() Note that this works even if implements in a non- way. This seems hightly problematic, especially provided we eventually want to support constructing at compile time. Relevant PR: Of course that impl claims to be unstable, but as we all know trait implementations are never unstable, unless the trait is unstable. (For ordinary traits, implementations of are thus unstable merely due to the fact that no user can use any such implementations in stable code yet.) label regression-from-stable-to-stable The fix should be straightforward: Remove the implementation (i.e. revert it to be non-), and add a test.
cc
that impl should be illegal, shouldn't it? I would expect us to need an explicit here. But also, reverting and maybe even backporting that impl for now seems like the right choice to me
Good catch! Actually calling this leads to odd behavior: It doesn't even say what went wrong. I expected an error saying a non-const function was called as part of the drop glue.
Change:
unsafe { stack::record_os_managed_stack_bounds(my_stack_bottom, my_stack_top); } <ins> match their_thread.name() { Some(name) => unsafe { imp::set_name(name.as_slice()); }, None => {} } </ins> thread_info::set( (my_stack_bottom, my_stack_top), unsafe { imp::guard::current() },

Discussion:
I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!
Change:
<ins> // run-rustfix fn main() { if 1 === 1 { //~ ERROR invalid comparison operator `===` println!("yup!"); } else if 1 !== 1 { //~ ERROR invalid comparison operator `!==` println!("nope!"); } } </ins>

Discussion:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.
Change:
/// ``` /// This function builds the entire call to format!. fn build_format(&self, input: &String, span: proc_macro2::Span) -> proc_macro2::TokenStream { <del> let mut referenced_fields: HashSet<String> = HashSet::new(); </del> <ins> // This set is used later to generate the final format string. To keep builds reproducible, // the iteration order needs to be deterministic, hence why we use a BTreeSet here instead // of a HashSet. let mut referenced_fields: BTreeSet<String> = BTreeSet::new(); </ins> // At this point, we can start parsing the format string. let mut it = input.chars().peekable();

Discussion:
My nightly script that checks for reproducible builds of rustc failed this morning. Git bisect pointed me to (). With that commit, about 12 rlibs have differences in my parallel builds (librustcprivacy is one) and nothing in the diff of the binaries jumps out as an obvious culprit. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The PR you linked to wasn't merged; I think you meant
Ah, yes, sorry about that. The commit should be correct, though.
cc
oops, yea this is likely (not sure if there are other hashset/hashmap iterations happening, but that's the only one I found). So the fix is twofold: First change all the and to and where possible, and second, collect to a and sort that before iterating over the set/map
Ah, my bad. I can take this. claim
Change:
const CONSTANT: u32; type Type; fn method(&self, s: String) -> Self::Type; <ins> fn method2(self: Box<Self>, s: String) -> Self::Type; fn method3(other: &Self, s: String) -> Self::Type; fn method4(&self, other: &Self) -> Self::Type; fn method5(self: &Box<Self>) -> Self::Type; </ins> }

Discussion:
In the error message below, the first argument of is not named . () Errors: modify labels: T-compiler, A-diagnostics, C-enhancement, D-papercut, F-arbitraryselftypes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I managed to fix this issue by just manually checking if the argument is of type , and if it is it returns where ty is the type of the argument (in this case std::pin::Pin<&mut Self). I'm not sure if there is a better way, I'm going to make a PR tomorrow, if anyone has a better solution, please tell me.
I’m not just interested in a fix for this particular case. Types that allow dispatch can be arbitrarily nested AFAIK and also I didn’t tag for no reason - these can be extended. Furthermore the correct way to fix this is probably not to just add code but rather to change ~existing logic that must be somewhere already, for example some code currently does make , and parameters print correctly and differently from non-self parameters that have type or~...... let me double-check that.... Oh, wow, I’ll expand this bug-report. Create a binary crate named “my-crate” with: Error message is:
Makes sense as if I recall correctly (can't link files rn as I am on my phone) the code literally just checks if the type is (&/&mut)Self and if it is it prints (&/&mut)self otherwise it prints _: Type. A potential fix could be printing (&/&mut)self only if it's the first argument of the function
Won’t be enough. The first parameter of a trait fn could be of type without being named . It actually needs to check if it’s a parameter. That information should be retrievable somewhere in the compiler. Furthermore then the rest is easy: First step: check if it’s a parameter. If not: use . If it however is one, then check for the type being or or , printing , or respectively; otherwise print .

Another issue related to this is when you have a function that has a signature of The compiler suggests to implement the function using , but that doesn't work I should have fixed it, as soon as all of the tests pass I will make a PR
Change:
---- it_fails stderr ---- testing321 thread 'main' panicked at $DIR/test-panic-abort.rs:38:5: <del> assertion failed: `(left == right)` left: `2`, right: `5` </del> <ins> assertion `left == right` failed left: 2 right: 5 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
<ins> // Copyright 2014 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. pub fn foo() {} </ins>

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
<ins> error[E0532]: expected tuple struct or tuple variant, found unit variant `FarmAnimal::Cow` --> $DIR/issue-84700.rs:15:9 | LL |     Cow, |     --- `FarmAnimal::Cow` defined here ... LL |         FarmAnimal::Cow(_) => "moo".to_string(), |         ^^^^^^^^^^^^^^^^^^ help: use this syntax instead: `FarmAnimal::Cow` error[E0532]: expected tuple struct or tuple variant, found struct variant `FarmAnimal::Chicken` --> $DIR/issue-84700.rs:17:9 | LL |     Chicken { num_eggs: usize }, |     --------------------------- `FarmAnimal::Chicken` defined here ... LL |         FarmAnimal::Chicken(_) => "cluck, cluck!".to_string(), |         ^^^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `FarmAnimal::Chicken { num_eggs }` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0532`. </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
pub type Alias = u32; <ins> #[doc(cfg(feature = "foo-method"))] </ins> pub struct Foo { pub x: Alias, }

Discussion:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.