jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2015 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. trait Foo { type A; } struct FooStruct; impl Foo for FooStruct { //~^ ERROR overflow evaluating the requirement `<FooStruct as Foo>::A` type A = <FooStruct as Foo>::A; } fn main() {} </ins>

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
= note: `#[warn(while_true)]` on by default error: unnecessary parentheses around `match` head expression <del> --> $DIR/lint-unnecessary-parens.rs:41:11 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:48:11 </ins> | LL |     match (true) { |           ^^^^^^ help: remove these parentheses error: unnecessary parentheses around `let` head expression <del> --> $DIR/lint-unnecessary-parens.rs:44:16 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:51:16 </ins> | LL |     if let 1 = (1) {} |                ^^^ help: remove these parentheses error: unnecessary parentheses around `let` head expression <del> --> $DIR/lint-unnecessary-parens.rs:45:19 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:52:19 </ins> | LL |     while let 1 = (2) {} |                   ^^^ help: remove these parentheses error: unnecessary parentheses around method argument <del> --> $DIR/lint-unnecessary-parens.rs:59:24 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:66:24 </ins> | LL |     X { y: false }.foo((true)); |                        ^^^^^^ help: remove these parentheses error: unnecessary parentheses around assigned value <del> --> $DIR/lint-unnecessary-parens.rs:61:18 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:68:18 </ins> | LL |     let mut _a = (0); |                  ^^^ help: remove these parentheses error: unnecessary parentheses around assigned value <del> --> $DIR/lint-unnecessary-parens.rs:62:10 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:69:10 </ins> | LL |     _a = (0); |          ^^^ help: remove these parentheses error: unnecessary parentheses around assigned value <del> --> $DIR/lint-unnecessary-parens.rs:63:11 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:70:11 </ins> | LL |     _a += (1); |           ^^^ help: remove these parentheses <del> error: aborting due to 13 previous errors </del> <ins> error: aborting due to 15 previous errors </ins>

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
} } def => { <del> span_bug!(pat.span, "tuple struct pattern didn't resolve  to variant or struct {:?}", def); </del> <ins> debug!( "tuple struct pattern didn't resolve to variant or struct {:?} at {:?}", def, pat.span, ); self.tcx.sess.delay_span_bug(pat.span, &format!( "tuple struct pattern didn't resolve to variant or struct {:?}", def, )); return Err(()); </ins> } };

Discussion:
This one is very interesting IMHO. The "original" ICE was introduced between ..., but if I prepend the before (the outcommented line), there's a second ICE that is there forever (at least since Rust 1.11). modify labels: I-ICE C-bug
modify labels: I-ICE C-bug T-compiler (seems that I cannot ping rustbot from the thread start itself)
Reduced:
This issue exists all the way back to at least 1.7.0.
Change:
ensure_monomorphic_enough(tcx, tp_ty)?; ConstValue::from_u64(tcx.type_id_hash(tp_ty)) } <del> sym::variant_count => { if let ty::Adt(ref adt, _) = tp_ty.kind() { ConstValue::from_machine_usize(adt.variants.len() as u64, &tcx) } else { ConstValue::from_machine_usize(0u64, &tcx) } } </del> <ins> sym::variant_count => match tp_ty.kind() { ty::Adt(ref adt, _) => ConstValue::from_machine_usize(adt.variants.len() as u64, &tcx), ty::Projection(_) | ty::Opaque(_, _) | ty::Param(_) | ty::Bound(_, _) | ty::Placeholder(_) | ty::Infer(_) => throw_inval!(TooGeneric), ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) | ty::Float(_) | ty::Foreign(_) | ty::Str | ty::Array(_, _) | ty::Slice(_) | ty::RawPtr(_) | ty::Ref(_, _, _) | ty::FnDef(_, _) | ty::FnPtr(_) | ty::Dynamic(_, _) | ty::Closure(_, _) | ty::Generator(_, _, _) | ty::GeneratorWitness(_) | ty::Never | ty::Tuple(_) | ty::Error(_) => ConstValue::from_machine_usize(0u64, &tcx), }, </ins> other => bug!("`{}` is not a zero arg intrinsic", other), }) }

Discussion:
For example: Similar to , but with a different intrinsic. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We can probably just put call in front of that if statement. A more precise way to implement this would be to exhaustively match on and forbid , , , , and here. This way we the intrinsic can still be evaluated for which is probably desirable.
claim
Hello, I'm interested in taking the desirable approach. How is the arm for variants like should be handled? Which macro is more appropriate for this situation?
I quickly grepped for and ended up with here. That only works once you know what to search for though.
Change:
if !self.props.aux_bins.is_empty() { let aux_bin_dir = self.aux_bin_output_dir_name(); <ins> remove_and_create_dir_all(&aux_dir); </ins> remove_and_create_dir_all(&aux_bin_dir); }

Discussion:
I checked out the master branch and ran and the test failed: this was on
I am having the same problem on aarch64-apple-darwin. cc this started with .
I can't reproduce this in a clean ubuntu container. Can you? If not, probably something specific about your environments is causing this? The test did pass bors, after all.
This is also happening in dev-desktop-us-, where would be easy to reproduce I guess.
I think it might be an issue with caching, perhaps of the aux-bins. The following should reliably reproduce it:
If I do this, the test goes from failing to passing: So yeah, looks like a problem with cache invalidation of something in that directory.
Thanks for the reproducer. This fixes it for me: The failure is because there is an old .so file lying around: ./build/x8664-unknown-linux-gnu/test/ui/attributes/unixsigpipe/unixsigpipe- It should use: ./build/x8664-unknown-linux-gnu/test/ui/attributes/unixsigpipe/unixsigpipe- By removing the old and obsolete file, the test passes.
Change:
id, &prefix, true, <ins> true, </ins> // The whole `use` item item, ty::Visibility::Restricted(

Discussion:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!
Change:
<ins> // Copyright 2015 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. use std::marker::Send; enum TestE { A } struct MyType; unsafe impl Send for TestE {} unsafe impl Send for MyType {} unsafe impl Send for (MyType, MyType) {} //~^ ERROR builtin traits can only be implemented on structs or enums unsafe impl Send for &'static MyType {} //~^ ERROR builtin traits can only be implemented on structs or enums unsafe impl Send for [MyType] {} //~^ ERROR builtin traits can only be implemented on structs or enums unsafe impl Send for &'static [MyType] {} //~^ ERROR builtin traits can only be implemented on structs or enums fn is_send<T: Send>() {} fn main() { is_send::<(MyType, TestE)>(); } </ins>

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
Change:
<ins> // Test for issue #116766. // Ensure that we don't suggest impl'ing `Copy` for a type if it or at least one // of it's variants are marked as `non_exhaustive`. // check-pass #![deny(missing_copy_implementations)] #[non_exhaustive] pub enum MyEnum { A, } #[non_exhaustive] pub struct MyStruct { foo: usize, } pub enum MyEnum2 { #[non_exhaustive] A, B, } fn main() {} </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. --I have the following minimal example: It does as I expect and gives the error: However, since this enum is going to have more options to it in the future, for example, I go ahead and label it as : I would expect that this would disable the lint in this case. This is because, otherwise adding a implementation, e.g.: would then break when, in the future, I add my variant: with: In short, I would expect that adding would disable the lint as it's not future-proof, and the whole point of the attribute is to say "that a type or variant may have more fields or variants in the future". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
this.resolve_pattern(pat, PatternSource::FnParam, &mut bindings); } }); <ins> // Record elision candidates only for this parameter. debug_assert_matches!(self.lifetime_elision_candidates, None); self.lifetime_elision_candidates = Some(Default::default()); </ins> self.visit_ty(ty); <ins> let local_candidates = self.lifetime_elision_candidates.take(); </ins> <del> if let Some(ref candidates) = self.lifetime_elision_candidates { let new_count = candidates.len(); let local_count = new_count - lifetime_count; if local_count != 0 { </del> <ins> if let Some(candidates) = local_candidates { let distinct: FxHashSet<_> = candidates.iter().map(|(res, _)| *res).collect(); let lifetime_count = distinct.len(); if lifetime_count != 0 { </ins> parameter_info.push(ElisionFnParameter { index, ident: if let Some(pat) = pat && let PatKind::Ident(_, ident, _) = pat.kind {

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
self.worklist.push(def_id); } else { match res { <del> // If this path leads to a constant, then we need to // recurse into the constant to continue finding // items that are reachable. Res::Def(DefKind::Const | DefKind::AssocConst, _) => { </del> <ins> // Reachable constants and reachable statics can have their contents inlined // into other crates. Mark them as reachable and recurse into their body. Res::Def(DefKind::Const | DefKind::AssocConst | DefKind::Static(_), _) => { </ins> self.worklist.push(def_id); } <del> // If this wasn't a static, then the destination is // surely reachable. </del> _ => { self.reachable_symbols.insert(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. --Sorry, haven't tried to minimise this yet. The repro steps are 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. --: Also reproduces in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Hoisting the inline structure initialisation into s makes the ICE go away. That... doesn't make a lot of sense to me. <details<summary<strongDiff</strong</summary<p</p</details
Also reproduces in which is our current MSRV
The implementation here should probably also recurse into :
I can confirm that the ICE goes away with the suggested patch.
Possibly related -- while this made the ICE go away, the code when compiled in mode seems to not link. <details<summary<strongmysterious link error</strong</summary<p</p</detailsNaively -- with no understanding of rustc internals -- it feels like a reachability pass that doesn't find these values won't emit them into the library? Slapping some extra attributes around the place is a workaround.
Change:
<ins> error[E0277]: `()` is not an iterator --> $DIR/issue-108072-unmet-trait-alias-bound.rs:10:7 | LL |     f(()) |     - ^^ `()` is not an iterator |     | |     required by a bound introduced by this call | = help: the trait `Iterator` is not implemented for `()` = note: required for `()` to implement `IteratorAlias` note: required by a bound in `f` --> $DIR/issue-108072-unmet-trait-alias-bound.rs:7:14 | LL | fn f(_: impl IteratorAlias) {} |              ^^^^^^^^^^^^^ required by this bound in `f` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-02-15 regressed nightly: nightly-2023-02-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOf that rollup, looks most likely responsible to me. cc
claim
Ah, I had assumed that was infallible (at least in this context), but apparently not. So prior to calling this, the function should verify that it has the right kind, and if not, bail out (). Ideally it would resolve the trait alias too, but there's enough existing corner-cases which aren't handled that it isn't a big deal.
Actually, I think the problem arises earlier, when building derived obligations for trait aliases: they shouldn't be s at all. I have a fix, about to push.
Change:
} } <ins> fn bindings_after_at_dynamic_init_move(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; let _x; if let bar @ Some(_) = foo { _x = bar; } } fn bindings_after_at_dynamic_init_ref(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; let _x; if let bar @ Some(_baz) = &foo { _x = bar; } } fn bindings_after_at_dynamic_drop_move(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; if let bar @ Some(_) = foo { bar } else { None }; } fn bindings_after_at_dynamic_drop_ref(a: &Allocator, c: bool) { let foo = if c { Some(a.alloc()) } else { None }; if let bar @ Some(_baz) = &foo { bar } else { &None }; } </ins> fn move_ref_pattern(a: &Allocator) { let mut tup = (a.alloc(), a.alloc(), a.alloc(), a.alloc()); let (ref _a, ref mut _b, _c, mut _d) = tup;

Discussion:
The feature which allows for patterns, is implemented in The PR doesn't have as good coverage of the dynamic semantics as we might like. Once the PR lands, we should try to improve things before we stabilize the feature. Notable tests to include: [x] Dynamic drop () cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is now unblocked as has landed.
I would like to work on this one
Go for it :) assign
Now that has landed, I think we can close this once also lands.
Change:
let old_info = old_info.expect("unsized_info: missing old info for trait upcasting coercion"); if data_a.principal_def_id() == data_b.principal_def_id() { <del> // Codegen takes advantage of the additional assumption, where if the // principal trait def id of what's being casted doesn't change, // then we don't need to adjust the vtable at all. This // corresponds to the fact that `dyn Tr<A>: Unsize<dyn Tr<B>>` // requires that `A = B`; we don't allow *upcasting* objects // between the same trait with different args. If we, for // some reason, were to relax the `Unsize` trait, it could become // unsound, so let's assert here that the trait refs are *equal*. // // We can use `assert_eq` because the binders should have been anonymized, // and because higher-ranked equality now requires the binders are equal. debug_assert_eq!( data_a.principal(), data_b.principal(), </del> <ins> debug_assert!( validate_trivial_unsize(fx.tcx, data_a, data_b), </ins> "NOP unsize vtable changed principal trait ref: {data_a} -> {data_b}" ); return old_info;

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
let fn_abi = tcx .fn_abi_of_instance(tcx.param_env(instance.def_id()).and((instance, ty::List::empty()))) <del> .unwrap_or_else(|instance| { bug!("typeid_for_instance: couldn't get fn_abi of instance {:?}", instance) </del> <ins> .unwrap_or_else(|error| { bug!("typeid_for_instance: couldn't get fn_abi of instance {instance:?}: {error:?}") </ins> }); typeid_for_fnabi(tcx, fn_abi, options)

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))', 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim