jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: unexpected `cfg` condition name: `my_value` --> $DIR/cfg-value-for-cfg-name-multiple.rs:8:7 | LL | #[cfg(my_value)] |       ^^^^^^^^ | = help: expected names are: `bar`, `debug_assertions`, `doc`, `doctest`, `foo`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `unix`, `windows` = help: to expect this configuration use `--check-cfg=cfg(my_value)` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration = note: `#[warn(unexpected_cfgs)]` on by default help: found config with similar value | LL | #[cfg(foo = "my_value")] |       ~~~~~~~~~~~~~~~~ help: found config with similar value | LL | #[cfg(bar = "my_value")] |       ~~~~~~~~~~~~~~~~ warning: 1 warning emitted </ins>

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
Repeat{element: elt} } <ins> /// An iterator that yields nothing. #[unstable(feature="iter_empty", reason = "new addition")] pub struct Empty<T>(marker::PhantomData<T>); #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Iterator for Empty<T> { type Item = T; fn next(&mut self) -> Option<T> { None } fn size_hint(&self) -> (usize, Option<usize>){ (0, Some(0)) } } #[unstable(feature="iter_empty", reason = "new addition")] impl<T> DoubleEndedIterator for Empty<T> { fn next_back(&mut self) -> Option<T> { None } } #[unstable(feature="iter_empty", reason = "new addition")] impl<T> ExactSizeIterator for Empty<T> { fn len(&self) -> usize { 0 } } // not #[derive] because that adds a Clone bound on T, // which isn't necessary. #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Clone for Empty<T> { fn clone(&self) -> Empty<T> { Empty(marker::PhantomData) } } // not #[derive] because that adds a Default bound on T, // which isn't necessary. #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Default for Empty<T> { fn default() -> Empty<T> { Empty(marker::PhantomData) } } /// Creates an iterator that yields nothing. #[unstable(feature="iter_empty", reason = "new addition")] pub fn empty<T>() -> Empty<T> { Empty(marker::PhantomData) } /// An iterator that yields an element exactly once. #[unstable(feature="iter_once", reason = "new addition")] pub struct Once<T> { inner: ::option::IntoIter<T> } #[unstable(feature="iter_once", reason = "new addition")] impl<T> Iterator for Once<T> { type Item = T; fn next(&mut self) -> Option<T> { self.inner.next() } fn size_hint(&self) -> (usize, Option<usize>) { self.inner.size_hint() } } #[unstable(feature="iter_once", reason = "new addition")] impl<T> DoubleEndedIterator for Once<T> { fn next_back(&mut self) -> Option<T> { self.inner.next_back() } } #[unstable(feature="iter_once", reason = "new addition")] impl<T> ExactSizeIterator for Once<T> { fn len(&self) -> usize { self.inner.len() } } /// Creates an iterator that yields an element exactly once. #[unstable(feature="iter_once", reason = "new addition")] pub fn once<T>(value: T) -> Once<T> { Once { inner: Some(value).into_iter() } } </ins> /// Functions for lexicographical ordering of sequences. /// /// Lexicographical ordering through `<`, `<=`, `>=`, `>` requires

Discussion:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-53692.rs:13:37 | LL |         let items_clone: Vec<i32> = ref_items.clone(); |                                     ^^^^^^^^^^^^^^^^^ |                                     | |                                     expected struct `std::vec::Vec`, found &[i32] |                                     help: try using a conversion method: `ref_items.to_vec()` | = note: expected type `std::vec::Vec<i32>` found type `&[i32]` error[E0308]: mismatched types --> $DIR/issue-53692.rs:19:30 | LL |         let string: String = s.clone(); |                              ^^^^^^^^^ |                              | |                              expected struct `std::string::String`, found &str |                              help: try using a conversion method: `s.to_string()` | = note: expected type `std::string::String` found type `&str` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Let's say you have the following (simplified) code: () This results in the following error: The suggested fix will work, but already copies the data so the extra is wasteful. The error message should instead suggest . This is an error you can run into if was previously of type and you changed it to a slice after writing the rest of the code.
Note: this kind of improvement applies to too: Err:
Change:
<ins> // Regression test for issue #55001. Previously, we would incorrectly // cache certain trait selection results when checking for blanket impls, // resulting in an ICE when we tried to confirm the cached ParamCandidate // against an obligation. pub struct DefaultAllocator; pub struct Standard; pub struct Inner; pub trait Rand {} pub trait Distribution<T> {} pub trait Allocator<N> {} impl<T> Rand for T where Standard: Distribution<T> {} impl<A> Distribution<Point<A>> for Standard where DefaultAllocator: Allocator<A>, Standard: Distribution<A> {} impl Distribution<Inner> for Standard {} pub struct Point<N> where DefaultAllocator: Allocator<N> { field: N } fn main() {} </ins>

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
#![feature(slice_patterns)] #![feature(float_from_str_radix)] #![feature(cell_extras)] <ins> #![feature(iter_empty)] #![feature(iter_once)] </ins> extern crate core; extern crate test;

Discussion:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.
Change:
<ins> #![feature(ptr_metadata)] // Address issue #112737 -- ICE with dyn Pointee extern crate core; use core::ptr::Pointee; fn unknown_sized_object_ptr_in(_: &(impl Pointee<Metadata = ()> + ?Sized)) {} fn raw_pointer_in(x: &dyn Pointee<Metadata = ()>) { unknown_sized_object_ptr_in(x) //~^ ERROR type mismatch resolving `<dyn Pointee<Metadata = ()> as Pointee>::Metadata == ()` } fn main() { raw_pointer_in(&42) } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- Needs to reproduce, is not enough. <!-- 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
related: This shouldn't compile, but it does:
This is definitely fixed by , I'll add some tests and link this one.
whoops, forgot to add tests. marking as E-needs-test
I wouldn't mind giving this one a try if I'm understanding it correctly. Just add tests for the changes made in , should the original code at the top of this issue compile now and the code in the next comment, shouldn't compile?
correct. Please put some care into which subdirectory in these tests are placed, and make sure they're given at least somewhat descriptive names (i.e. not or anything like that).
Change:
<ins> #![deny(deref_into_dyn_supertrait)] extern crate core; use core::ops::Deref; // issue 89190 trait A {} trait B: A {} impl<'a> Deref for dyn 'a + B { type Target = dyn A; fn deref(&self) -> &Self::Target { todo!() } } fn take_a(_: &dyn A) {} fn whoops(b: &dyn B) { take_a(b) //~^ ERROR `dyn B` implements `Deref` with supertrait `(dyn A + 'static)` as output //~^^ WARN this was previously accepted by the compiler but is being phased out; } fn main() {} </ins>

Discussion:
<!-- 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. --I tried this code: I expected to see this happen: This should probably continue to compile as before, unless proven to be equivalent. Instead, this happened: The detection for seems to be a little too aggressive, so it's flagging the coercion as feature-gated in beta even though a deref coercion is available: Playground: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.55.0 : <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!--<details<summaryBacktrace</summary<p</p</details--(not applicable) <!-- 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 -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Bisection: searched nightlies: from nightly-2020-01-01 to nightly-2021-09-23 regressed nightly: nightly-2021-08-01 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: </details
There is a that discusses this issue. Tagging this with T-lang since this is a change in semantics.

label +A-traits +F-trait_upcasting +T-lang +T-compiler
I'm not sure what the proper procedure is in this case, but I just noticed this hit stable in 1.56.0 (without the lint appearing beforehand) and broke my crate I'll work around it on my end, since I need this to continue work on a downstream crate.
Hmm, it seems that the fix didn't get backported to 1.56. Does 1.57-beta work?
It does indeed: The playground uses as of writing this.
Change:
let mut name = String::with_capacity(prefix.len() + 6); name.push_str(prefix); name.push_str("."); <del> base_n::push_str(idx as u64, base_n::MAX_BASE, &mut name); </del> <ins> base_n::push_str(idx as u64, base_n::ALPHANUMERIC_ONLY, &mut name); </ins> name } }

Discussion:
So I tried to compile core and I get this errors from assembler: the code on line 9468 looks like this: I tried both (4.6.3) and (5.3.0) and both give the same errors. Then I've renamed symbol to in assembly and it compiled successfully. I think msp430 assembler just does not like character in symbol names. So I see 2 options: MSP430 target in LLVM so it will rename symbols with  to not emit on MSP430
Change:
<ins> error[E0412]: cannot find type `Sum` in this scope --> $DIR/erroneous_type_in_promoted.rs:6:22 | LL |     UnusedByTheConst(Sum), |                      ^^^ not found in this scope | help: consider importing this trait | LL + use std::iter::Sum; | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
<ins> struct Take(Take); //~^ ERROR has infinite size //~| ERROR cycle detected // check that we don't hang trying to find the tail of a recursive struct (#79437) fn foo() -> Take { Take(loop {}) } 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 tried this code: Running does not terminate after a long time. After running for 4 minutes, the process is using 99.2% CPU and about 80 MB memory. <!-- 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 following also hangs, though a diagnostic is first emitted:
The hang seems to happen in
I have modified to detect simple cycles like these to obtain a backtrace: <details</details
More minimal example: This one demonstrates that it's a regression, it errors out immediately on 1.35 but hangs on 1.36.
searched toolchains nightly-2019-04-09 through nightly-2019-05-22 Regression in nightly-2019-04-24 found 9 bors merge commits in the specified range commit[0] 2019-04-22UTC: Auto merge of - varkor:tidy-leading-newline, r=alexcrichton commit[1] 2019-04-22UTC: Auto merge of - estebank:continue-eval, r=oli-obk commit[2] 2019-04-23UTC: Auto merge of - euclio:pulldown-cmark, r=GuillaumeGomez commit[3] 2019-04-23UTC: Auto merge of - davazp:fix-sync-all-macos, r=KodrAus commit[4] 2019-04-23UTC: Auto merge of - varkor:tidy-double-trailing-newline, r=kennytm commit[5] 2019-04-23UTC: Auto merge of - estebank:continue-evaluating, r=oli-obk commit[6] 2019-04-23UTC: Auto merge of - stepnivlk:visit_subpats-removal, r=varkor commit[7] 2019-04-23UTC: Auto merge of - davidtwco:issue-, r=oli-obk commit[8] 2019-04-23UTC: Auto merge of - Centril:rollup-akw4r85, r=Centril Probably ? I guess the compiler used to abort early after the recursive type error but now doesn't and hangs because later code assumes structs aren't recursive. label regression-from-stable-to-stable
cc - maybe something similar is necessary here?
What did was stop doing that (aborting early if there's an error) for .

Seems a bit drastic to revert that (making the compiler unable to report other, later errors until the recursive type is fixed) for this - I think we can do something more targeted.
Perhaps the recursive field could be replaced by a ?
Assigning and removing as .20leads.20to.20infinite.20loop) in the prioritization working group.
This issue have been also reported in .
Change:
compiler's name mangling too: ```rust,ignore <del> #![feature(lang_items)] </del> <ins> #![feature(lang_items, core_intrinsics)] </ins> #![feature(start)] #![no_std] #![no_main] <ins> use core::intrinsics; </ins> // Pull in the system libc library for what crt0.o likely requires. extern crate libc;

Discussion:
The following file, when compiled without optimizations, correctly generates an overflow check in : However, compiling with optimizations plus or generates code without the overflow check. However, if I move to a separate no_core crate like this, the issue disappears and the overflow check is generated:
noticed that my panic implementation () is UB according to LLVM (see ), so it optimizes the overflow check out on the assumption that it can never be triggered (since that would be UB). Replacing it with e.g. fixes the issue.
Change:
} impl Default for IO_STATUS_BLOCK_union { fn default() -> Self { <del> Self { Pointer: ptr::null_mut() } </del> <ins> let mut this = Self { Pointer: ptr::null_mut() }; this.Status = STATUS_PENDING; this </ins> } } #[repr(C)]

Discussion:
on windows. with and rename it back to git bash I expected to see this happen: my really long string gets printed twice, followed by a clean exit Instead, this happened: some amount of my really long string gets printed, followed by: The test case, while simple, does appear to have a minimum size requirement to trigger this crash. Shrinking the string will cause it to stop crashing. I'm using in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too. Redirecting to a file instead of a pipe seems to not trigger this crash. Using is not necessary to trigger the crash, running the built executable directly also crashes. This PR this new error condition: I am not the only one seeing this new error message: modify labels: +regression-from-stable-to-stable +O-windows
I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with . In my original bug report, I suggested calling once if returned , since that will at least resolve the pending IO correctly in the case where the file is not being used for other IOs concurrently. This would cover this and other cases at least as well as the original code calling . This isn't perfect, since of course takes , so you can probably deadlock in a multi-threaded process in this async pipe configuration. But it would at least avoid the common case. However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped?
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap.
Thanks for fixing the issue quickly. When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? Or will we have to wait for a fix in 1.63?
PR was nominated and accepted for both beta and stable backport by T-libs. Leaving this open until those play out. Assigning P-high for the same reasons it was accepted for backports.
Change:
] [[package]] <ins> name = "cargo-credential" version = "0.1.0" [[package]] name = "cargo-credential-1password" version = "0.1.0" dependencies = [ "cargo-credential", "serde", "serde_json", ] [[package]] name = "cargo-credential-macos-keychain" version = "0.1.0" dependencies = [ "cargo-credential", "security-framework", ] [[package]] name = "cargo-credential-wincred" version = "0.1.0" dependencies = [ "cargo-credential", "winapi 0.3.9", ] [[package]] </ins> name = "cargo-miri" version = "0.1.0" dependencies = [

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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
} } <del> query mir_generator_witnesses(key: DefId) -> &'tcx mir::GeneratorLayout<'tcx> { </del> <ins> query mir_generator_witnesses(key: DefId) -> &'tcx Option<mir::GeneratorLayout<'tcx>> { </ins> arena_cache desc { |tcx| "generator witness types for `{}`", tcx.def_path_str(key) } cache_on_disk_if { key.is_local() }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
"cannot process registered region obligations in a snapshot" ); <del> debug!("process_registered_region_obligations()"); </del> <ins> debug!(?param_env, "process_registered_region_obligations()"); </ins> let my_region_obligations = self.take_registered_region_obligations();

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. --Within an , a GAT bound of does not compile, asking me to add an explicit bound. This code results in two errors: I believe that the error is a bug, as since is known in this to be , must outlive and the suggested bound should thus already be implied by . Applying the suggested fix removes this error, but obviously cannot compile (as the GAT impl now has a stricter than in the declaration). The first error seems incorrect too, as there is no visible difference between the highlighted lines other than : Adding the type bound on the declaration avoids these errors, but is less generic. <!-- 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 have also encountered this bug on . </details
label +F-genericassociatedtypes +T-compiler
It's both rude and unconstructive to suggest that issues are not tracked. First and foremost, this is an unstable feature. Second, this issue was filed 15 days ago, right in the middle of holidays. Third, its labeled appropriately, and I'll either triage or fix it when I can. I'm going to delete the above comment since it's not constructive at all.
I forgot what I said before, but if I said something bad, I'm really sorry for that