jiebi/CodeConvo huggingface dataset:
Code change:
// `PathSegment`, for which there is no associated `'_` or `&T` with no explicit // lifetime. Instead, we simply create an implicit lifetime, which will be checked // later, at which point a suitable error will be emitted. <del> LifetimeRibKind::AnonymousPassThrough(..) | LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => break, </del> <ins> LifetimeRibKind::AnonymousPassThrough(binder) => { res = LifetimeRes::Anonymous { binder, elided: true }; break; } LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => { // FIXME(cjgillot) This resolution is wrong, but this does not matter // since these cases are erroneous anyway.  Lifetime resolution should // emit a "missing lifetime specifier" diagnostic. res = LifetimeRes::Anonymous { binder: DUMMY_NODE_ID, elided: true }; break; } </ins> _ => {} } } <del> let res = if error { LifetimeRes::Error } else { LifetimeRes::Anonymous { binder: segment_id, elided: true } }; </del> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id,

Related discussion:
text: I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.
Code change:
assert_eq!(ys, [1, 2, 3]); } <ins> #[test] fn test_box_slice_clone() { let data = vec![vec![0, 1], vec![0], vec![1]]; let data2 = data.clone().into_boxed_slice().clone().to_vec(); assert_eq!(data, data2); } #[test] fn test_box_slice_clone_panics() { use std::sync::Arc; use std::sync::atomic::{AtomicUsize, Ordering}; use std::thread::spawn; struct Canary { count: Arc<AtomicUsize>, panics: bool } impl Drop for Canary { fn drop(&mut self) { self.count.fetch_add(1, Ordering::SeqCst); } } impl Clone for Canary { fn clone(&self) -> Self { if self.panics { panic!() } Canary { count: self.count.clone(), panics: self.panics } } } let drop_count = Arc::new(AtomicUsize::new(0)); let canary = Canary { count: drop_count.clone(), panics: false }; let panic = Canary { count: drop_count.clone(), panics: true }; spawn(move || { // When xs is dropped, +5. let xs = vec![canary.clone(), canary.clone(), canary.clone(), panic, canary].into_boxed_slice(); // When panic is cloned, +3. xs.clone(); }).join().unwrap_err(); // Total = 8 assert_eq!(drop_count.load(Ordering::SeqCst), 8); } </ins> mod bench { use std::iter::repeat; use std::{mem, ptr};

Related discussion:
text: We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.
Code change:
assert_eq!(vec![1; 2], vec![1, 1]); assert_eq!(vec![1; 1], vec![1]); assert_eq!(vec![1; 0], vec![]); <ins> // from_elem syntax (see RFC 832) let el = Box::new(1); let n = 3; assert_eq!(vec![el; n], vec![Box::new(1), Box::new(1), Box::new(1)]); </ins> }

Related discussion:
text: Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.
Code change:
use rustc_hir::def::{self, DefKind, NonMacroAttrKind}; use rustc_hir::def_id; use rustc_middle::middle::stability; <del> use rustc_middle::{span_bug, ty}; </del> <ins> use rustc_middle::ty; </ins> use rustc_session::lint::builtin::UNUSED_MACROS; use rustc_session::Session; use rustc_span::edition::Edition;

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in
Code change:
<ins> // In rustc_typeck::check::expr::no_such_field_err we recursively // look in subfields for the field. This recursive search is limited // in depth for compile-time reasons and to avoid infinite recursion // in case of cycles. This file tests that the limit in the recursion // depth is enforced. struct Foo { first: Bar, second: u32, third: u32, } struct Bar { bar: C, } struct C { c: D, } struct D { test: E, } struct E { e: F, } struct F { f: u32, } fn main() { let f = F { f: 6 }; let e = E { e: f }; let d = D { test: e }; let c = C { c: d }; let bar = Bar { bar: c }; let fooer = Foo { first: bar, second: 4, third: 5 }; let test = fooer.f; //~^ ERROR no field } </ins>

Related discussion:
text: I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
Thank you.
Code change:
<ins> // run-rustfix fn main() { let a: usize = 123; let b: &usize = &a; if true { a } else { b //~ ERROR `if` and `else` have incompatible types [E0308] }; if true { 1 } else { &1 //~ ERROR `if` and `else` have incompatible types [E0308] }; if true { 1 } else { &mut 1 //~ ERROR `if` and `else` have incompatible types [E0308] }; } </ins>

Related discussion:
text: <!-- 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. --I tried this code: I expected to see this happen: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- 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. --: Also occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.
Code change:
<ins> // rust-lang/rust#60654: Do not ICE on an attempt to use GATs that is // missing the feature gate. struct Foo; impl Iterator for Foo { type Item<'b> = &'b Foo; //~ ERROR generic associated types are unstable [E0658] fn next(&mut self) -> Option<Self::Item> { None } } fn main() { } </ins>

Related discussion:
text: The following minimal example causes an internal compiler error. Error in question: rustc version: This error was encountered on stable, but I can confirm that it also occurs on the latest nightly ().
Hasn't the feature gate issue been fixed? :|
I've removed the nomination and this to the tracking issue for GATs . The current impl is highly incomplete and ICEs are, sadly, expected. Also, I verified that a feature gate is indeed required.
triage: P-medium
I don't know if I get you wrong, but the example above ICEs on stable, beta and nightly without feature gate
oops, looks like I accidentally left the feature gate in there when I tried it out, but it produces the same ICE when it is omitted as well.
No, niko edited your question. ping I think you got something wrong there. Can you please clarify that?
Oh, I guess I was indeed incorreect. I tried it on play but didn't notice that, after the "correct" error, it goes on to print an ICE.
What about adding the I-nominated tag again?
I'm not sure why we would nominate this for discussion. Yes, it is an ICE (and an ICE that occurs without the user adding a feature gate), but the message pretty clearly states that you're using an unstable feature. It would be great to fix it so that it issues the error diagnostic without ICEing, but I wouldn't re-prioritize that work above P-medium.
assigning to self since its a clear annoyance
triage: P-medium. (dupe of )
(the remaining bug, when the feature gate is enabled, is tracked in issue )
Code change:
// SAFETY: left and right must be valid and part of v same for out. unsafe { <del> let to_copy = if is_less(&*right, &**left) { get_and_increment(&mut right) } else { get_and_increment(left) }; ptr::copy_nonoverlapping(to_copy, get_and_increment(out), 1); </del> <ins> let is_l = is_less(&*right, &**left); let to_copy = if is_l { right } else { *left }; ptr::copy_nonoverlapping(to_copy, *out, 1); *out = out.add(1); right = right.add(is_l as usize); *left = left.add(!is_l as usize); </ins> } } } else {

Related discussion:
text: I tried this code, sorting 30 million random : On this machine: Using the vendored version of from mid 2022 see here I expected to see this happen: Runtime ~1.45s Instead, this happened: Runtime ~2s I bisected the issue down to with . The same happens if you do instead of . So this also affects the current implementation which is very similar to my vendored version.
Dinging into it, I think the relevant code that has this impact is in the function. Which has two blocks of logic one for if the left side is shorter and one if the right side is shorter. Previously both sides generated code that is branchless in terms of jumping based on the comparison result. Now the block handling left side is shorter generates a jump based on the comparison result. LLVM 15: ! LLVM 16: ! This can be fixed in code by using 'proper' branchless code: -This would fix the stdlib, but it would still mean a regression for any other code out there that relies on this.
I feel like I should attach the usual disclaimer that this kind of optimization can never be considered fully stable, specifically LLVM has various heuristics that affect whether it compiles a segment of code to use a "branchless" CMOV-alike or use a jump, however that doesn't mean there's nothing we can do here. label: +A-LLVM +A-codegen +regression-from-stable-to-beta +I-slow
WG-prioritization assigning priority (). label -I-prioritize +P-low +T-compiler
out of curiosity. What is the future for a perf regression marked as P-low? Is there any work planned on this? Personally I was surprised that it even generated branchless code in the first place.
A P-high or P-critical compiler issue means that it will be reviewed regularly by T-compiler until it is resolved, where "regularly" is a much higher frequency for P-critical. So a P-low implicitly means "this isn't so important that we need to keep putting it on the agenda". Though I should note that periodically, all T-compiler issues do get reviewed and triaged, just on a more irregular basis.
Code change:
// SAFETY: left and right must be valid and part of v same for out. unsafe { <del> let to_copy = if is_less(&*right, &**left) { get_and_increment(&mut right) } else { get_and_increment(left) }; ptr::copy_nonoverlapping(to_copy, get_and_increment(out), 1); </del> <ins> let is_l = is_less(&*right, &**left); let to_copy = if is_l { right } else { *left }; ptr::copy_nonoverlapping(to_copy, *out, 1); *out = out.add(1); right = right.add(is_l as usize); *left = left.add(!is_l as usize); </ins> } } } else {

Related discussion:
text: Performance work is one of those "never done" things so it's rare for it to be high priority in general, which isn't the same as "no one will work on it". It just means it would be addressed in a somewhat irregular fashion.
I'm not sure I understand the difference between "never done" and "no one will work on it".
"Never done" as in "never finished" not "never worked on"
Ohh, thanks for clarifying. Anyway from my perspective me and other people I've talked to were surprised this even generated branchless code in the first place, I'd be fine with closing this issue as won't fix.
since you have opened a PR (thanks a lot for that!), it makes totally sense to try fixing it, no matter the priority we assign to issues.
I think the issue can be split into two parts: A) A significant regression in . B) LLVM no longer generating branchless code for a certain pattern. I think A should definitely be fixed, and that's what my PR is for. B however I'd argue doesn't really need fixing, because the code in question was not obviously branchless.
Code change:
)]; let mut has_unsized_tuple_coercion = false; <del> let mut has_trait_upcasting_coercion = false; </del> <ins> let mut has_trait_upcasting_coercion = None; </ins> // Keep resolving `CoerceUnsized` and `Unsize` predicates to avoid // emitting a coercion in cases like `Foo<$1>` -> `Foo<$2>`, where

Related discussion:
text: <!-- 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. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --It should name the traits are attempted to be coerced, maybe tell me why that's not allowed (yet), etc. Right now it just highlights the entire line. The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed". Note that I understand why it's not allowed, I was just disappointed by the error message. I already talked to about this, and they also thought this output may be problematic. Even though the feature may be unstable, it's quite easy to arrive at a situation where you may get this error. <!-- 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 --
claim
Code change:
// More information on the environment variable is available here: // https://www.gnu.org/prep/standards/html_node/DESTDIR.html if let Some(destdir) = env::var_os("DESTDIR").map(PathBuf::from) { <ins> // Sanity check for the user write access on DESTDIR assert!(is_dir_writable_for_user(&destdir), "User doesn't have write access on DESTDIR."); </ins> let without_destdir = path.clone(); path = destdir; // Custom .join() which ignores disk roots.

Related discussion:
text: In the followup discussion on , we discovered that their original problem was because they had chosen a path under their home directory for , but they had not changed the default . So most things installed fine, but they didn't have permission to write . Bootstrap could sanity check this when starting an install, seeing that is writable by the current user but the absolute is not. (A relative goes under , which should be fine.) This should also take into account as a further prefix on all installation paths.
I have just updated to version 1.71.0, and now I'm receiving the terminal warning: In my previous setup, I the line to my file.
yeah, made that effectively . That was reverted in , and now proposed for stable and beta backports. So you could add for now, but it will be going back to the way it was.
Code change:
# "-C", "linker=arm-none-eabi-gcc", # "-C", "link-arg=-Wl,-Tlink.x", # "-C", "link-arg=-nostartfiles", <del> ] </del>  No newline at end of file <ins> ] </ins>

Related discussion:
text: I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.
Code change:
if x == 0.0 { 0 } else { 1 } } <ins> pub fn bitwise_not() -> i32 { // CHECK-LABEL: fn bitwise_not( // CHECK: switchInt( // Test for #131195, which was optimizing `!a == b` into `a != b`. let mut a: i32 = 0; a = 1; if !a == 0 { 1 } else { 0 } } </ins> fn main() { // CHECK-LABEL: fn main( too_complex(Ok(0));

Related discussion:
text: <!-- 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. --I tried this code: I expected to see this happen: always panic Instead, this happened: only -Zmir-opt-level=2 panic For mir-opt-level 0, 1 and 3, they all normally return <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
equals , so I think the panic case is incorrect?
Yeah, I think so.
Looks like it's JumpThreading that incorrectly removes the condition
I managed to create an example without panic, just wrong value
Most likely
ha, I found the bug. We're optimizing incorrectly in the jump threading code. Right now it's only written to handle bool correctly. I'll put up a fix claim
Code change:
None, ); if let Some(infer::RelateParamBound(_, t, _)) = origin { <del> let return_impl_trait = self.tcx.return_type_impl_trait(generic_param_scope).is_some(); </del> let t = self.resolve_vars_if_possible(t); match t.kind() { // We've got: // fn get_later<G, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ // suggest: // fn get_later<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a <del> ty::Closure(..) | ty::Alias(ty::Opaque, ..) if return_impl_trait => { </del> <ins> ty::Closure(..) | ty::Alias(ty::Opaque, ..) => { </ins> new_binding_suggestion(&mut err, type_param_span); } _ => {

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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