jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.

Related discussion:
text: <del> // check-fail // edition:2021 // known-bug: #88908 // This should pass, but seems to run into a TAIT bug. #![feature(type_alias_impl_trait)] use std::future::Future; trait Stream { type Item; } struct Empty<T>(T); impl<T> Stream for Empty<T> { type Item = (); } fn empty<T>() -> Empty<T> { todo!() } trait X { type LineStream<'a, Repr>: Stream<Item = Repr> where Self: 'a; type LineStreamFut<'a,Repr>: Future<Output = Self::LineStream<'a, Repr>> where Self: 'a; fn line_stream<'a,Repr>(&'a self) -> Self::LineStreamFut<'a,Repr>; } struct Y; impl X for Y { type LineStream<'a, Repr> = impl Stream<Item = Repr>; type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>> ; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { async {empty()} } } fn main() {} </del>
Code change:
<!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.

Related discussion:
text: <del> error[E0271]: type mismatch resolving `<Empty<_> as Stream>::Item == Repr` --> $DIR/issue-89008.rs:38:43 | LL |     fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { |                        ----               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type mismatch resolving `<Empty<_> as Stream>::Item == Repr` |                        | |                        this type parameter | note: expected this to be `()` --> $DIR/issue-89008.rs:17:17 | LL |     type Item = (); |                 ^^ = note:   expected unit type `()` found type parameter `Repr` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </del>
Code change:
<!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.

Related discussion:
text: <ins> // check-pass // edition:2021 #![feature(type_alias_impl_trait)] use std::future::Future; use std::marker::PhantomData; trait Stream { type Item; } struct Empty<T> { _phantom: PhantomData<T>, } impl<T> Stream for Empty<T> { type Item = T; } trait X { type LineStream<'a, Repr>: Stream<Item = Repr> where Self: 'a; type LineStreamFut<'a, Repr>: Future<Output = Self::LineStream<'a, Repr>> where Self: 'a; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr>; } struct Y; impl X for Y { type LineStream<'a, Repr> = impl Stream<Item = Repr>; type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>>; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { async { Empty { _phantom: PhantomData } } } } fn main() {} </ins>
Code change:
<!-- 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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: } else if nanos >= MAX_NANOS_F64 { Err(FromSecsError { kind: FromSecsErrorKind::Overflow }) } else if nanos < 0.0 { <del> Err(FromSecsError { kind: FromSecsErrorKind::Underflow }) </del> <ins> Err(FromSecsError { kind: FromSecsErrorKind::Negative }) </ins> } else { let nanos = nanos as u128; Ok(Duration {
Code change:
<!-- 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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: } else if nanos >= MAX_NANOS_F32 { Err(FromSecsError { kind: FromSecsErrorKind::Overflow }) } else if nanos < 0.0 { <del> Err(FromSecsError { kind: FromSecsErrorKind::Underflow }) </del> <ins> Err(FromSecsError { kind: FromSecsErrorKind::Negative }) </ins> } else { let nanos = nanos as u128; Ok(Duration {
Code change:
<!-- 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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: impl FromSecsError { const fn description(&self) -> &'static str { match self.kind { <del> FromSecsErrorKind::NonFinite => { "got non-finite value when converting float to duration" } </del> <ins> FromSecsErrorKind::NonFinite => "non-finite value when converting float to duration", </ins> FromSecsErrorKind::Overflow => "overflow when converting float to duration", <del> FromSecsErrorKind::Underflow => "underflow when converting float to duration", </del> <ins> FromSecsErrorKind::Negative => "negative value when converting float to duration", </ins> } } }
Code change:
<!-- 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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: #[derive(Debug, Clone, PartialEq, Eq)] enum FromSecsErrorKind { <del> // Value is not a finite value (either infinity or NaN). </del> <ins> // Value is not a finite value (either + or - infinity or NaN). </ins> NonFinite, // Value is too large to store in a `Duration`. Overflow, <del> // Value is less than `0.0`. Underflow, </del> <ins> // Value is negative. Negative, </ins> }
Code change:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics

Related discussion:
text: #![allow(incomplete_features)] #![feature(inline_const_pat)] <ins> #![feature(generic_const_exprs)] </ins> // rust-lang/rust#82518: ICE with inline-const in match referencing const-generic parameter fn foo<const V: usize>() { <del> match 0 { const { V } => {}, //~^ ERROR const parameters cannot be referenced in patterns [E0158] _ => {}, } </del> <ins> match 0 { const { V } => {}, //~^ ERROR const parameters cannot be referenced in patterns [E0158] _ => {}, } } const fn f(x: usize) -> usize { x + 1 } fn bar<const V: usize>() where [(); f(V)]: { match 0 { const { f(V) } => {}, //~^ ERROR constant pattern depends on a generic parameter //~| ERROR constant pattern depends on a generic parameter _ => {}, } </ins> } fn main() { foo::<1>(); <ins> bar::<1>(); </ins> }
Code change:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics

Related discussion:
text: error[E0158]: const parameters cannot be referenced in patterns <del> --> $DIR/const-match-pat-generic.rs:8:11 </del> <ins> --> $DIR/const-match-pat-generic.rs:9:9 </ins> | <del> LL |     const { V } => {}, |           ^^^^^ </del> <ins> LL |         const { V } => {}, |         ^^^^^^^^^^^ </ins> <del> error: aborting due to previous error </del> <ins> error: constant pattern depends on a generic parameter --> $DIR/const-match-pat-generic.rs:21:9 | LL |         const { f(V) } => {}, |         ^^^^^^^^^^^^^^ error: constant pattern depends on a generic parameter --> $DIR/const-match-pat-generic.rs:21:9 | LL |         const { f(V) } => {}, |         ^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0158`.
Code change:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

Related discussion:
text: drop(linker); save_temp_bitcode(cgcx, &module, "lto.input"); <del> // Fat LTO also suffers from the invalid DWARF issue similar to Thin LTO. // Here we rewrite all `DICompileUnit` pointers if there is only one `DICompileUnit`. // This only works around the problem when codegen-units = 1. // Refer to the comments in the `optimize_thin_module` function for more details. let mut cu1 = ptr::null_mut(); let mut cu2 = ptr::null_mut(); unsafe { llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2) }; if !cu2.is_null() { let _timer = cgcx.prof.generic_activity_with_arg("LLVM_fat_lto_patch_debuginfo", &*module.name); unsafe { llvm::LLVMRustLTOPatchDICompileUnit(llmod, cu1) }; save_temp_bitcode(cgcx, &module, "fat-lto-after-patch"); } </del> // Internalize everything below threshold to help strip out more modules and such. unsafe { let ptr = symbols_below_threshold.as_ptr();
Code change:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

Related discussion:
text: // an error. let mut cu1 = ptr::null_mut(); let mut cu2 = ptr::null_mut(); <del> llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2); </del> <ins> llvm::LLVMRustThinLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2); </ins> if !cu2.is_null() { let msg = "multiple source DICompileUnits found"; return Err(write::llvm_err(&diag_handler, msg));
Code change:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

Related discussion:
text: let _timer = cgcx .prof .generic_activity_with_arg("LLVM_thin_lto_patch_debuginfo", thin_module.name()); <del> llvm::LLVMRustLTOPatchDICompileUnit(llmod, cu1); </del> <ins> llvm::LLVMRustThinLTOPatchDICompileUnit(llmod, cu1); </ins> save_temp_bitcode(cgcx, &module, "thin-lto-after-patch"); }