jiebi/CodeConvo huggingface dataset:
Code change:
// since we may be in the process of computing this MIR in the // first place. let layout = if def_id == self.caller_body.source.def_id() { <del> // FIXME: This is not right for async closures. </del> <ins> self.caller_body.coroutine_layout_raw() } else if let Some(hir::CoroutineKind::Desugared( _, hir::CoroutineSource::Closure, )) = self.tcx.coroutine_kind(def_id) && let ty::ClosureKind::FnOnce = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap() && self.caller_body.source.def_id() == self.tcx.coroutine_by_move_body_def_id(def_id) { // Same if this is the by-move body of a coroutine-closure. </ins> self.caller_body.coroutine_layout_raw() } else { self.tcx.coroutine_layout(def_id, args.as_coroutine().kind_ty())

Related discussion:
text: Originally posted at and filing this upon request from . We're using nightly rust and as of nightly-2024-08-29 (prior to this it compiled fine) we see the following error: Function being flagged can be viewed at . We're having a bit of a hard time debugging this issue, it's not very clear what this actually means. I've tried looking at the HIR output but it didn't really help and I'm a bit lost on this one as I'm not familiar with MIR. I expected to see this happen: Compilation succeed. Instead, this happened: Compilation failed due to MIR cycle. : Backtrace contained no extra information.
this kind of looks like it should be an ICE instead? :thinking:
I'll try to put up a fix. It's due to (not that you need to understand what that PR does), not your fault.
For now, though, you'll need to either stop using closures (since you've got an bound, not ; why are you using closures over just , since those don't really buy you anything in this case?) or pin your nightly compiler version until I can minimize this and fix it.
Minimized: To reproduce: (Odd that the "optimization" also happens in debug builds.) Of note: During the minimization process, rust-analyzer froze multiple times. And a few times, also froze.
you're awesome! thanks for the minimization.
Thanks for confirming. We were having a lot of issues with lifetimes when using the async blocks which lead to us using async closures instead. Possibly we should just revisit that...
You might be interested in these two links for an explanation on how exactly async closures differ from a closure that returns an async block: https://rust-
Thanks I'll take a look at those.
Code change:
"bad output4: {}", s); } <del> #[cfg(not(all(windows, target_arch = "x86")))] </del> fn main() { <ins> if cfg!(windows) && cfg!(target_arch = "x86") && cfg!(target_env = "gnu") { return } </ins> let args: Vec<String> = env::args().collect(); if args.len() >= 2 && args[1] == "fail" { foo();

Related discussion:
text: Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.
Code change:
} let definition_ty = instantiated_ty <del> .remap_generic_params_to_declaration_params(opaque_type_key, self.tcx, false, origin) </del> <ins> .remap_generic_params_to_declaration_params(opaque_type_key, self.tcx, false) </ins> .ty; if !check_opaque_type_parameter_valid(

Related discussion:
text: Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that
Code change:
| ----- in this macro invocation error: expected identifier, found reserved identifier `$crate` <del> --> $DIR/dollar-crate-is-keyword.rs:11:23 </del> <ins> --> $DIR/dollar-crate-is-keyword.rs:10:23 </ins> | LL |         use $crate as $crate; |                       ^^^^^^ expected identifier, found reserved identifier

Related discussion:
text: The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.
Code change:
= help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <del> error: aborting due to 5 previous errors </del> <ins> error[E0658]: the `!` type is experimental --> $DIR/feature-gate-never_type.rs:16:43 | LL | fn look_ma_no_feature_gate<F: FnOnce() -> !>() {} |                                           ^ | = note: see issue #35121 <https://github.com/rust-lang/rust/issues/35121> for more information = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0658]: the `!` type is experimental --> $DIR/feature-gate-never_type.rs:17:26 | LL | fn tadam(f: &dyn Fn() -> !) {} |                          ^ | = note: see issue #35121 <https://github.com/rust-lang/rust/issues/35121> for more information = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0658]: the `!` type is experimental --> $DIR/feature-gate-never_type.rs:21:30 | LL | fn toudoum() -> impl Fn() -> ! { |                              ^ | = note: see issue #35121 <https://github.com/rust-lang/rust/issues/35121> for more information = help: add `#![feature(never_type)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error: aborting due to 8 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

Related discussion:
text: I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet for ). <!-- 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. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.
Code change:
// The correct solution would be to add symbolic computations to miri, // so we wouldn't have to compute and store the actual value <del> let hir::ExprKind::Path(ref qpath) = source.kind else { return ExprKind::Cast { source: self.mirror_expr(source) }; }; let res = self.typeck_results().qpath_res(qpath, source.hir_id); let ty = self.typeck_results().node_type(source.hir_id); let ty::Adt(adt_def, args) = ty.kind() else { return ExprKind::Cast { source: self.mirror_expr(source) }; }; let Res::Def(DefKind::Ctor(CtorOf::Variant, CtorKind::Const), variant_ctor_id) = res else { return ExprKind::Cast { source: self.mirror_expr(source) }; }; </del> let idx = adt_def.variant_index_with_ctor_id(variant_ctor_id); let (discr_did, discr_offset) = adt_def.discriminant_def_for_variant(idx);

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: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.
Code change:
adt_def, variant_index: adt_def.variant_index_with_ctor_id(def_id), substs, <del> user_ty: user_provided_type, </del> <ins> user_ty, </ins> fields: vec![], base: None, }, <ins> _ if ty.references_error() => { // Handle degenerate input without ICE (#67377). ExprKind::Literal { literal: ty::Const::zero_sized(cx.tcx, cx.tcx.types.err), user_ty: None, } } </ins> _ => bug!("unexpected ty: {:?}", ty), } }

Related discussion:
text: The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc
Code change:
.map(|lazy| lazy.decode((cdata, tcx))) .process_decoded(tcx, || panic!("{def_id:?} does not have trait_impl_trait_tys"))) } <del> implied_predicates_of => { cdata .root .tables .implied_predicates_of .get(cdata, def_id.index) .map(|lazy| lazy.decode((cdata, tcx))) .unwrap_or_else(|| { debug_assert_eq!(tcx.def_kind(def_id), DefKind::Trait); tcx.super_predicates_of(def_id) }) } </del> associated_types_for_impl_traits_in_associated_fn => { table_defaulted_array }

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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry
Code change:
panic::panic_any(InjectedFailure) ); }); <del> assert_eq!(get(), vec![14, 19, 20, 17, 15, 11, 18, 16, 12, 13]); </del> <ins> assert_eq!(get(), vec![20, 17, 15, 11, 19, 18, 16, 12, 14, 13]); </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: both compiles successfully Instead, this happened: fails to compile <!-- 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 --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.
Code change:
panic::panic_any(InjectedFailure) ); }); <del> assert_eq!(get(), vec![14, 19, 20, 17, 15, 11, 18, 16, 12, 13]); </del> <ins> assert_eq!(get(), vec![20, 17, 15, 11, 19, 18, 16, 12, 14, 13]); </ins> }

Related discussion:
text: It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-54505.rs:14:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `std::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `std::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:19:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `std::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:24:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `std::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `std::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505.rs:29:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `std::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:34:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `std::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `std::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505.rs:39:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `std::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `std::ops::RangeToInclusive<{integer}>` error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.
Code change:
pub type ExternType; } <ins> pub trait T { fn test(&self) {} } pub trait G<N> { fn g(&self, n: N) {} } </ins> impl ExternType { <del> pub fn f(&self) { </del> <ins> pub fn f(&self) {} } </ins> <del> } </del> <ins> impl T for ExternType { fn test(&self) {} } impl G<usize> for ExternType { fn g(&self, n: usize) {} </ins> } // @has 'extern_type/foreigntype.ExternType.html' // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.f"' <ins> // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.test"' // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.g"' </ins> /// See also [ExternType::f] <ins> /// See also [ExternType::test] /// See also [ExternType::g] </ins> pub fn links_to_extern_type() {}

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Example code: docs build successfully on 1.57.0: docs fail to build on 1.59.0-nightly ( 2022-01-04): </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --The generics appear necessary for the bug. Removing them from either the type or the trait resolves the failure. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably . searched nightlies: from nightly-2022-01-06 to nightly-2022-01-07 regressed nightly: nightly-2022-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
just saw this, I think might be caused by this change: I'm looking into it
claim
Code change:
<ins> error[E0507]: cannot move out of `var`, a captured variable in an `FnMut` closure --> $DIR/option-content-move2.rs:9:9 | LL |     let mut var = None; |         ------- captured outer variable ... LL |         move || { |         ^^^^^^^ move out of `var` occurs here LL | LL |             var = Some(NotCopyable); |             --- |             | |             move occurs because `var` has type `std::option::Option<NotCopyable>`, which does not implement the `Copy` trait |             move occurs due to use in closure error: aborting due to previous error For more information about this error, try `rustc --explain E0507`. </ins>

Related discussion:
text: gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler
Code change:
<del> Subproject commit 130721d6f4e6cba3b910ccdf5e0aa62b9dffc95f </del> <ins> Subproject commit 027e428197f3702599cfbb632883768175f49173 </ins>

Related discussion:
text: The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.
Code change:
<ins> error: unknown start of token: u{2a75} --> $DIR/unicode-double-equals-recovery.rs:1:16 | LL | const A: usize ⩵ 2; |                ^ | help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not | LL | const A: usize == 2; |                ~~ error: unexpected `==` --> $DIR/unicode-double-equals-recovery.rs:1:16 | LL | const A: usize ⩵ 2; |                ^ | help: try using `=` instead | LL | const A: usize = 2; |                ~ error: aborting due to 2 previous errors </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium