jiebi/CodeConvo huggingface dataset:
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. --As part of an ongoing effort to eliminate all panics from one of my projects, I discovered that does not elide bounds checks in release mode, whereas does. This issue also affects . The following examples illustrate this issue: The generated asm for elides all bounds checks: Unfortunately, the bounds check is reintroduced when is used instead: It seems that the following code in the iterator is responsible for introducing the bounds check (specifically the array index on line 640): <!-- 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 tested on from the Rust playground. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nice catch. Oh, I'm doing the same (but in regular std code). stdsort is full of bound tests (issue ). I'm dreaming of having red squiggles under divisions/mods/rems and array/slice accesses where a bound test hasn't being removed. And built-in annotations like . And more :)
label +A-codegen +A-slice +T-libs +T-compiler
claim
Awesome, thanks for looking into this

Discussion:
return None; } <del> let idx_opt = { // work around borrowck limitations let pred = &mut self.pred; self.v.iter().position(|x| (*pred)(x)) }; match idx_opt { </del> <ins> match self.v.iter().position(|x| (self.pred)(x)) { </ins> None => self.finish(), Some(idx) => { <del> let tmp = mem::replace(&mut self.v, &mut []); let (head, tail) = tmp.split_at_mut(idx); self.v = &mut tail[1..]; Some(head) </del> <ins> let tmp = mem::take(&mut self.v); // idx is the index of the element we are splitting on. We want to set self to the // region after idx, and return the subslice before and not including idx. // So first we split after idx let (head, tail) = tmp.split_at_mut(idx + 1); self.v = tail; // Then return the subslice up to but not including the found element Some(&mut head[..idx]) </ins> } } }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
sure !

Discussion:
<del> Subproject commit e5c3af6f516311cc4b1fc017c58d83b7442cbc34 </del> <ins> Subproject commit 35af23b6a94459da538ee1479e863c7699620f84 </ins>
Change:
This only happens when compiled in a library, not an executable. The associated type , both of the 's, the (instead of just ), and the match statement are all needed to make it panic. Replacing the match statement with errors gracefully, and says that I cannot call unwrap on a trait object; so I assume the error that should have been emitted for the match statement is that I cannot destructure a trait object. Replacing the match with compiles successfully. This happens on stable, nightly, and beta. : <details<summary<strongBacktrace</strong</summary<p</p</details
also happens on nightly
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
This ICE still exists, but the "internal compiler error" and "query stack during panic" sections of the error output have changed on 1.58.0-nightly. I'm running this on a different machine than the one I initially posted the issue from. The output in 1.56.1-stable is still the same as it was when I originally posted the issue. <details<summary<strongBacktrace</strong</summary<p</p</details
Additionally, the new ICE now happens when the code is compiled into an executable, but only on nightly. This didn't happen before. On 1.56.1-stable in , the compiler emits a warning that is never used, and compiles successfully. Edit: the error now happens on 1.60.0 stable when compiling in a binary as well.
Triage: the issue has been fixed on the latest nightly, marking as .

Discussion:
<ins> // compile-flags: --crate-type=lib -Zmir-opt-level=2 // build-pass // ^-- Must be build-pass, because check-pass will not run const prop. pub trait TestTrait { type MyType; fn func() -> Option<Self> where Self: Sized; } impl<T> dyn TestTrait<MyType = T> where Self: Sized, { pub fn other_func() -> Option<Self> { match Self::func() { Some(me) => Some(me), None => None, } } } </ins>
Change:
It would be nice if supported lowercase error codes: The current output is: Ideally, the command would work regardless of whether you enter or : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-driver +A-error-codes +C-enhancement +T-compiler claim
I'm just about to open a pull request for this. Thank you for bringing it up!

Discussion:
} fn handle_explain(registry: Registry, code: &str, output: ErrorOutputType) { <del> let normalised = if code.starts_with('E') { code.to_string() } else { format!("E{0:0>4}", code) }; </del> <ins> let upper_cased_code = code.to_ascii_uppercase(); let normalised = if upper_cased_code.starts_with('E') { upper_cased_code } else { format!("E{0:0>4}", code) }; </ins> match registry.try_find_description(&normalised) { Ok(Some(description)) => { let mut is_in_code_block = false;
Change:
I tried this code: I expected to see this happen: No warning Instead, this happened: Got the warning: AFAIK, this should not be ambiguous, since it is an inherent method, which should take priority over the TryInto trait. Also, the suggestion doesn't make much sense, since it just surrounds the variable with parenthesis, which have no effect (and indeed, can be removed even on 2021). cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'll look into it, in some cases inherent methods do collide but this is definitely a false positive, might just be checking the number of derefs.
claim
label +A-diagnostics +A-edition-2021 +D-incorrect +T-compiler

Discussion:
{ return; } <ins> // if it's an inherent `self` method (not `&self` or `&mut self`), it will take // precedence over the `TryInto` impl, and thus won't break in 2021 edition if pick.autoderefs == 0 && pick.autoref_or_ptr_adjustment.is_none() { return; } </ins> // Inherent impls only require not relying on autoref and autoderef in order to // ensure that the trait implementation won't be used self.tcx.struct_span_lint_hir(

<ins> // edition:2018 // check-pass #![allow(unused)] #![deny(future_prelude_collision)] struct S; impl S { fn try_into(self) -> S { S } } // See https://github.com/rust-lang/rust/issues/86633 fn main() { let s = S; let s2 = s.try_into(); } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!

Discussion:
<del> Subproject commit 61605ebde25f920b18cc2f7e1b92838cd7b6fa67 </del> <ins> Subproject commit 05fdec916a3a9755c6ea603bab79cdb2f7c062bf </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
<del> Subproject commit 05fdec916a3a9755c6ea603bab79cdb2f7c062bf </del> <ins> Subproject commit 15e81a94b1aff99f7c38151d6976757ee0ed0097 </ins>
Change:
In particular, this means you have to rebuild llvm for the host when cross-compiling. I tried this code: . I expected to see this happen: The compiler builds successfully. Instead, this happened: I think there's a secondary bug which is that x.py hard-codes instead of . But that seems easier to fix. <!-- 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<summaryBacktrace</summary<p</p</details
Mentoring instructions: where in it generates the component (I think I might be in ) llvm-tblgen to the binaries that are copied a PR and ask someone to run , which will generate CI artifacts. the merge commit from the build locally and confirm that works successfully (or if you're not on Linux, some other platform that's binary compatible).
label: +E-mentor
Make sure to only copy it if it exists. It doesn't get build if the llvm backend isn't enabled.
It looks like unconditionally copies llvm binaries right now, so I think should be no different.

Discussion:
"llvm-nm", "llvm-dwarfdump", "llvm-dis", <ins> "llvm-tblgen", </ins> ] { tarball.add_file(src_bindir.join(exe(bin, target)), "bin", 0o755); }

Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/97550 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/102790 </ins>

// https://llvm.org/docs/HowToCrossCompileLLVM.html if target != builder.config.build { <del> builder.ensure(Llvm { target: builder.config.build }); // FIXME: if the llvm root for the build triple is overridden then we //        should use llvm-tblgen from there, also should verify that it //        actually exists most of the time in normal installs of LLVM. let host_bin = builder.llvm_out(builder.config.build).join("bin"); cfg.define("LLVM_TABLEGEN", host_bin.join("llvm-tblgen").with_extension(EXE_EXTENSION)); // LLVM_NM is required for cross compiling using MSVC cfg.define("LLVM_NM", host_bin.join("llvm-nm").with_extension(EXE_EXTENSION)); cfg.define( "LLVM_CONFIG_PATH", host_bin.join("llvm-config").with_extension(EXE_EXTENSION), ); </del> <ins> let llvm_config = builder.ensure(Llvm { target: builder.config.build }); if !builder.config.dry_run { let llvm_bindir = output(Command::new(&llvm_config).arg("--bindir")); let host_bin = Path::new(llvm_bindir.trim()); cfg.define( "LLVM_TABLEGEN", host_bin.join("llvm-tblgen").with_extension(EXE_EXTENSION), ); // LLVM_NM is required for cross compiling using MSVC cfg.define("LLVM_NM", host_bin.join("llvm-nm").with_extension(EXE_EXTENSION)); } cfg.define("LLVM_CONFIG_PATH", llvm_config); </ins> if builder.config.llvm_clang { let build_bin = builder.llvm_out(builder.config.build).join("build").join("bin"); let clang_tblgen = build_bin.join("clang-tblgen").with_extension(EXE_EXTENSION);
Change:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2021-02-10 to nightly-2021-05-01 regressed nightly: nightly-2021-03-19 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: </detailsIt looks like is when this error started happening. cc
I'm going to take a look at this. claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Discussion:
if self.check_keyword(kw::Pub) { let sp = sp_start.to(self.prev_token.span); if let Ok(snippet) = self.span_to_snippet(sp) { <del> let vis = self.parse_visibility(FollowedByType::No)?; </del> <ins> let vis = match self.parse_visibility(FollowedByType::No) { Ok(v) => v, Err(mut d) => { d.cancel(); return Err(err); } }; </ins> let vs = pprust::vis_to_string(&vis); let vs = vs.trim_end(); err.span_suggestion(

<ins> const pub () {} //~^ ERROR expected one of `async`, `extern`, `fn`, or `unsafe` pub fn main() {} </ins>

<ins> error: expected one of `async`, `extern`, `fn`, or `unsafe`, found keyword `pub` --> $DIR/issue-86895.rs:1:7 | LL | const pub () {} |       ^^^ expected one of `async`, `extern`, `fn`, or `unsafe` error: aborting due to previous error </ins>
Change:
(As I mentioned :) I tried out the migration lints on some of my own code, and ran into one false positive: A struct being used with This doesn't actually become ambiguous when FromIterator is imported, because Opt doesn't implement that. Niko :
(If we don't end up doing this, we should at least change the wording to say instead of .)
Which exact function on which type do you mean? Do you have some pointers here?
Maybe Niko meant evaluate-obligation ?
Okay I have an implementation that uh.. compiles. And seems to work, maybe? (:

Discussion:
FormatSpec, Formatter, From, <ins> FromIterator, </ins> Future, FxHashMap, FxHashSet,

use rustc_ast::Mutability; use rustc_errors::Applicability; use rustc_hir as hir; <ins> use rustc_middle::ty::subst::InternalSubsts; </ins> use rustc_middle::ty::{Ref, Ty}; use rustc_session::lint::builtin::RUST_2021_PRELUDE_COLLISIONS; use rustc_span::symbol::kw::Underscore; use rustc_span::symbol::{sym, Ident}; use rustc_span::Span; <ins> use rustc_trait_selection::infer::InferCtxtExt; </ins> use crate::check::{ method::probe::{self, Pick},

return; } <ins> // For from_iter, check if the type actually implements FromIterator. // If we know it does not, we don't need to warn. if method_name.name == sym::from_iter { if let Some(trait_def_id) = self.tcx.get_diagnostic_item(sym::FromIterator) { if !self .infcx .type_implements_trait( trait_def_id, self_ty, InternalSubsts::empty(), self.param_env, ) .may_apply() { return; } } } </ins> // No need to lint if this is an inherent method called on a specific type, like `Vec::foo(...)`, // since such methods take precedence over trait methods. if matches!(pick.kind, probe::PickKind::InherentImplPick) {

over elements of type `{A}`", label = "value of type `{Self}` cannot be built from `std::iter::Iterator<Item={A}>`" )] <ins> #[rustc_diagnostic_item = "FromIterator"] </ins> pub trait FromIterator<A>: Sized { /// Creates a value from an iterator. ///

} } <del> // See https://github.com/rust-lang/rust/issues/86633 </del> <ins> struct X; trait Hey { fn from_iter(_: i32) -> Self; } impl Hey for X { fn from_iter(_: i32) -> Self { X } } struct Y<T>(T); impl Hey for Y<i32> { fn from_iter(_: i32) -> Self { Y(0) } } struct Z<T>(T); impl Hey for Z<i32> { fn from_iter(_: i32) -> Self { Z(0) } } impl std::iter::FromIterator<u32> for Z<u32> { fn from_iter<T: IntoIterator<Item = u32>>(_: T) -> Self { todo!() } } </ins> fn main() { <ins> // See https://github.com/rust-lang/rust/issues/86633 </ins> let s = S; let s2 = s.try_into(); <ins> // Check that we do not issue suggestions for types that do not implement `FromIter`. // // See https://github.com/rust-lang/rust/issues/86902 X::from_iter(1); Y::from_iter(1); Y::<i32>::from_iter(1); Z::<i32>::from_iter(1); </ins> }
Change:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for . The feature adds the method to , which allow a safe transformation from a to a . [x] [x] [ ] None yet.
It's from a , right? The nesting is a bit odd. But I guess it is what comes up in practice?
Ah, yes, sorry — fixed!
Are there any remaining blockers on this? It's a pretty useful function for blanket impls for traits with poll methods (e.g. Future already uses it in its impl).
Not that I know of — given it touches the machinery, I suspect it should go through an actual FCP, but I'll let others be the judge of that :)
Currently this method is located in its own solitary impl block: I'd like to consider changing it to: Some advantages: Synergy with the existing and signatures (stable since Rust 1.33) Lifetime elision reduces noise in the signature Turbofish less verbose: vs
Any concern blocks this from stablization?
I agree — that is better :+1:
Would it be possible to start an FCP on this?
fcp merge  is like , but without enforcing an unnecessary . It is like , but is unconditionally safe. The use case arises in real-world code when you are implementing a trait that takes where the Self type of your impl is . So what you have is something like , and want to delegate to the impl for which takes . Some examples: In tokio:  In hyper:  In futures:  In actix:  In libcore:
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.

Discussion:
/// move in the future, and this method does not enable the pointee to move. "Malicious" /// implementations of `Ptr::DerefMut` are likewise ruled out by the contract of /// `Pin::new_unchecked`. <del> #[unstable(feature = "pin_deref_mut", issue = "86918")] </del> <ins> #[stable(feature = "pin_deref_mut", since = "CURRENT_RUSTC_VERSION")] </ins> #[must_use = "`self` will be dropped if the result is not used"] #[inline(always)] pub fn as_deref_mut(self: Pin<&mut Pin<Ptr>>) -> Pin<&mut Ptr::Target> {
Change:
Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
I'm ambivalent, I don't think showing zero is necessarily wrong, especially since that's what's reported by .
In my opinion, I think that while size 0 is not wrong, that showing that it's uninhabited is more right, or at least more clear and makes the distinction.
I don't understand uninhabited when I first see it. It is a hard word compared to 0. I think 0 is easier. Why not both? What if we show ? Also, what if the enum is not empty but have a single/multiple ZST like phantom type?
I think displaying 0 is better as well, but we can do as suggested and simply display both.
0 is wrong. 0 means "this is a zero sized type", like or ; it can be created. Uninhabited types cannot be created, they are things like and . IMO posting 0 there is actively misleading. See also Ok, then we can link to some docs. I didn't see anything in the nomicon but I'm sure they'd take a PR adding it to "exotically sized types".
This is a bug imo, it allows transmuting from ZSTs to uninhabited types which is UB.
Even if they cannot be created, their size remain 0 as they don't "exist", however since they cannot be constructed, it makes sense to mention they're unhabited types. Well, I don't have a strong conviction on this in any case. I think we all agree for the mention of "unhabited" though.
Yeah, that solved the issue of 0 which is wrong. I do think it is better to link it to , but I think it's wrong to put that in "size" such that it should be in "type" instead, because it doesn't have a size to begin with. Well, there are parts where rust sacrificed correctness for ease of understanding, one example is which means uniqueness not exactly mutable all the time.
claim
Note that uninhabited is orthogonal to size. You can have an uninhabited type of any size. So I think showing uninhabitedness is good, but in addition to the size+align, not instead.
Hmm, I think that will report that the size is always 0 for an uninhabited type though, unless that's changed recently.
That would surprise me, since that'd be different from what and do:

Discussion:
} else { let size = layout.size.bytes() - tag_size; write!(w, "{size} byte{pl}", pl = if size == 1 { "" } else { "s" },); <ins> if layout.abi.is_uninhabited() { write!( w, " (<a href="https://doc.rust-lang.org/stable/reference/glossary.html#uninhabited">uninhabited</a>)" ); } </ins> } }

None, Some(std::num::NonZeroU32), } <ins> // @hasraw type_layout/enum.Uninhabited.html 'Size: ' // @hasraw - '0 bytes (<a href="https://doc.rust-lang.org/stable/reference/glossary.html#uninhabited">uninhabited</a>)' pub enum Uninhabited {} // @hasraw type_layout/struct.Uninhabited2.html 'Size: ' // @hasraw - '8 bytes (<a href="https://doc.rust-lang.org/stable/reference/glossary.html#uninhabited">uninhabited</a>)' pub struct Uninhabited2(std::convert::Infallible, u64); </ins>
Change:
I haven't gotten it to error without nightly features, so I believe it has to do with the generated enum for the Generator. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsAs an aside, if one gets rid of the , this fails (kind of expected, though the error message could be improved) with
No longer ICEs since

Discussion:
<ins> // compile-flags: -Cdebuginfo=2 // build-pass // Regression test for #87142 // This test needs the above flags and the "lib" crate type. #![feature(type_alias_impl_trait, generator_trait, generators)] #![crate_type = "lib"] use std::ops::Generator; pub trait GeneratorProviderAlt: Sized { type Gen: Generator<(), Return = (), Yield = ()>; fn start(ctx: Context<Self>) -> Self::Gen; } pub struct Context<G: 'static + GeneratorProviderAlt> { pub link: Box<G::Gen>, } impl GeneratorProviderAlt for () { type Gen = impl Generator<(), Return = (), Yield = ()>; fn start(ctx: Context<Self>) -> Self::Gen { move || { match ctx { _ => (), } yield (); } } } </ins>
Change:
I experienced build failure during , and I've heard same problem today at irc. Here's the . Seems like configure failed to find definitions for win32. ()
For record: it is due to CRLF (wow!), and fixes it by force git checkout LF for certain files. However, the fix does not help if you already checkout out repo before landed. For those cases, remove jemalloc directory () and checkout again ().

Discussion:
src/rt/vg/* -whitespace src/rt/linenoise/* -whitespace src/rt/jemalloc/**/* -whitespace <ins> src/rt/jemalloc/include/jemalloc/jemalloc.h.in text eol=lf src/rt/jemalloc/include/jemalloc/jemalloc_defs.h.in text eol=lf src/rt/jemalloc/include/jemalloc/internal/jemalloc_internal.h.in text eol=lf </ins>