jiebi/CodeConvo huggingface dataset:
Change:
// Check if a bound would previously have been removed when normalizing // the param_env so that it can be given the lowest priority. See // #50825 for the motivation for this. <del> let is_global = |cand: &ty::PolyTraitRef<'_>| cand.is_known_global() && !cand.has_late_bound_regions(); </del> <ins> let is_global = |cand: &ty::PolyTraitRef<'tcx>| { cand.is_global(self.infcx.tcx) && !cand.has_late_bound_regions() }; </ins> // (*) Prefer `BuiltinCandidate { has_nested: false }`, `PointeeCandidate`, // and `DiscriminantKindCandidate` to anything else.

Discussion:
Prior to Rust 1.56, I could use values when defining rkyv structs. However, in Rust 1.56, this is no longer allowed. I tried this code: I expected to see this happen: Prior to Rust 1.56, this compiled. Instead, this happened: The following error appears: It most recently worked on: Rust 1.55 : <!-- 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 --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Further information: This is using the crate. We use an older , however this still occurs with the latest version.
Bisected to . label +E-needs-mcve
Reproducer without macros, but still dependent on rkyv:
Reduced: Also, if you remove one of the lines, the code still compiles on 1.55 but the error on 1.56 changes to: label regression-from-stable-to-stable (not sure what happened with rustbot and the labels above)
label -E-needs-mcve
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Ok, I know what is the problem and have a fix. Apparently when looking for implementation for compiler considers candidates: one for top-level impl and two s. Before was using that was enough to discard the two s. But changed it to use instead, which is pessimistic, so now the compiler drops the global impl instead (because is not sure) and then can't decide between the two s.
Funny thing is it seems like it's fixed already in the master branch... Trying to bisect what fixed it to better understand if my change is needed after all.
also fixes it.
Change:
LL |     let _: ConstBytes<b"AAA"> = ConstBytes::<b"BBB">; |                                 ^^^^^^^^^^^^^^^^^^^^ expected `b"AAA"`, found `b"BBB"` | <del> = note: expected type `ConstBytes<>` found type `ConstBytes<>` </del> <ins> = note: expected type `ConstBytes<b"AAA">` found type `ConstBytes<b"BBB">` </ins> error: aborting due to 3 previous errors

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
traits.push(self.tcx.def_span(trait_pred.def_id())); } } <del> derives.sort(); let derives_grouped = derives.into_iter().fold( Vec::<(String, Span, String)>::new(), |mut acc, (self_name, self_span, trait_name)| { if let Some((acc_self_name, _, ref mut traits)) = acc.last_mut() { if acc_self_name == &self_name { traits.push_str(format!(", {}", trait_name).as_str()); return acc; } } acc.push((self_name, self_span, trait_name)); acc }, ); </del> traits.sort(); traits.dedup(); <ins> derives.sort(); derives.dedup(); let mut derives_grouped = Vec::<(String, Span, String)>::new(); for (self_name, self_span, trait_name) in derives.into_iter() { if let Some((last_self_name, _, ref mut last_trait_names)) = derives_grouped.last_mut() { if last_self_name == &self_name { last_trait_names.push_str(format!(", {}", trait_name).as_str()); continue; } } derives_grouped.push((self_name, self_span, trait_name)); } </ins> let len = traits.len(); if len > 0 { let span: MultiSpan = traits.into();

Discussion:
Given the following code: The current output is: Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// FIXME: The following limits should be reduced eventually. const ROOT_ENTRY_LIMIT: usize = 983; const ISSUES_ENTRY_LIMIT: usize = 2310; <del> const PARSER_LIMIT: usize = 1010; </del> <ins> const PARSER_LIMIT: usize = 1012; </ins> fn check_entries(path: &Path, bad: &mut bool) { let dirs = walkdir::WalkDir::new(&path.join("test/ui"))

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Affected versions: probably all versions since that panic was introduced, I tried nightly 2021-11-07 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsA quick inspection of the code shows that the similar case is handled the same as : So if I had to guess I would say that the match is missing this one case, so should be handled the same as : But no idea what does that code even do, it has a FIXME by so maybe he knows better. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::mem; struct Test { f: usize } impl Drop for Test { fn drop(&mut self) {} } fn main() { let mut x = (Test { f: 2 }, Test { f: 4 }); mem::drop(x.0); x.0.f = 3; //~^ ERROR partial reinitialization of uninitialized structure `x.0` } </ins>

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
if self_ty.span.edition() >= Edition::Edition2021 { let msg = "trait objects must include the `dyn` keyword"; let label = "add `dyn` keyword before this trait"; <del> rustc_errors::struct_span_err!(tcx.sess, self_ty.span, E0782, "{}", msg) .multipart_suggestion_verbose(label, sugg, Applicability::MachineApplicable) .emit(); </del> <ins> let mut diag = rustc_errors::struct_span_err!(tcx.sess, self_ty.span, E0782, "{}", msg); diag.multipart_suggestion_verbose(label, sugg, Applicability::MachineApplicable); // check if the impl trait that we are considering is a impl of a local trait self.maybe_lint_blanket_trait_impl(&self_ty, &mut diag); diag.emit(); </ins> } else { let msg = "trait objects without an explicit `dyn` are deprecated"; tcx.struct_span_lint_hir(

Discussion:
One of the big problems with the 2015-style trait object syntax (no ) was that users often write things like when what they really meant was . Back then, the error message would more often than not be some inscrutable message about , which would send them on a wild goose chase of adding bounds everywhere they could think of, leading to even more inscrutable messages. Now, the error message is clearer: it tells users they need to add for a trait object type. However, I find in many cases (most cases?) this is not what users actually want - what they actually want is the blanket impl. It would be helpful to have a note suggesting the correct syntax for a blanket impl, or better yet just presenting both correct syntaxes (impl for trait object and blanket impl) on equal footing and making it clear the difference between them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I work to reproduce this issue and start to understand what type of check we need to do, and in particular the work that we need to do is the following one: If the traits are local traits we can perform the suggestion of the blanket impls, for example in the following code But we need to skip the following suggestion in case we are using not local traits, like the following code here
Change:
else: exit_code = 1 print(error) <ins> success_word = "unsuccessfully" </ins> if not help_triggered: <del> print("Build completed successfully in", format_build_time(time() - start_time)) </del> <ins> print("Build completed", success_word, "in", format_build_time(time() - start_time)) </ins> sys.exit(exit_code)

Discussion:
do you have time to fix this regression? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Yes, will do claim
Change:
| ty::Never | ty::Tuple(_) | ty::Dynamic(_, _) <del> | ty::Adt(..) | ty::Foreign(_) // should be unreachable, but there's no hurt in printing it (and better than ICEing) | ty::Error </del> => self.pretty_print_type(ty), <del> | ty::Infer(_) | ty::Bound(_, _) </del> <ins> // Placeholders (all printed as `_` to uniformize them). </ins> | ty::Param(_) <ins> | ty::Bound(..) </ins> | ty::Placeholder(_) <del> | ty::Projection(_) | ty::UnnormalizedProjection(_) | ty::GeneratorWitness(_) => bug!( "{:#?} in `type_name` should not happen because we are always monomorphized", ty, ), // types with identity (print the module path instead) | ty::FnDef(did, substs) | ty::Opaque(did, substs) => self.print_def_path(did, substs), ty::Closure(did, substs) => self.print_def_path(did, substs.substs), ty::Generator(did, substs, _) => self.print_def_path(did, substs.substs), </del> <ins> | ty::Infer(_) | ty::Error => { write!(self, "_")?; Ok(self) } // Types with identity (print the module path). | ty::Adt(&ty::AdtDef { did: def_id, .. }, substs) | ty::FnDef(def_id, substs) | ty::Opaque(def_id, substs) | ty::Projection(ty::ProjectionTy { item_def_id: def_id, substs }) | ty::UnnormalizedProjection(ty::ProjectionTy { item_def_id: def_id, substs }) | ty::Closure(def_id, ty::ClosureSubsts { substs }) | ty::Generator(def_id, ty::GeneratorSubsts { substs }, _) => self.print_def_path(def_id, substs), ty::Foreign(def_id) => self.print_def_path(def_id, &[]), ty::GeneratorWitness(_) => { bug!("type_name: unexpected `GeneratorWitness`") } </ins> } }

Discussion:
I believe this happened after
triage: P-high because it blocks presumed stabilization of (). Removing nomination tag.
you can have parameterization in scope that's not part of monomorphization (like the above). For name mangling (with the new scheme) we produce something that demangles to in that case. We could use in this case too.
I'm working on a fix that uses .
Change:
<ins> trait Trait<'1> { s> {} fn main() {} </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. --<!-- 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
cc
Probably a duplicate of , and hopefully will be fixed by .
no, I checked, while is fixed, this one isn't :(
Change:
try!(write!(fmt, r##"<span id='render-detail'> <del> <a id="collapse-all" href="#">[-] </a>&nbsp;<a id="expand-all" href="#">[+]</a> </del> <ins> <a id="collapse-all" href="#">[-]</a>&nbsp;<a id="expand-all" href="#">[+]</a> </ins> </span>"##)); // Write `src` tag

Discussion:
Markdown list items separated by blank lines are wrapped in p tags within li tags ("loose" list). formatting. List items not separated by blank lines use only li tags ("tight" list). Links in loose lists are displayed in blue and are easily distinguishable as links. Links in tight lists are normal text colored and do not appear as links (although clicking them still works). Examples of both list types follow: Adding the missing formatting to loose lists is difference appears to be straight-forward CSS change. In , two rules control link appearance in loose lists (lines 377 & 378 in the commit): Adding a second selector to each rule colors the links: There are only two other li rules and these do not affect color. So, the change above may be all that is needed to fix this issue.
Just patched locally and can confirm it works. Thanks! R/Scott
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl AsRef<OsStr> for String { <ins> #[inline] </ins> fn as_ref(&self) -> &OsStr { (&**self).as_ref() }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
//! Some things are not yet fully implemented in the current version of this //! module. //! <del> //! ### Initializers of Constants and Statics //! Since no MIR is constructed yet for initializer expressions of constants and //! statics we cannot inspect these properly. //! </del> //! ### Const Fns //! Ideally, no mono item should be generated for const fns unless there //! is a call to them that cannot be evaluated at compile time. At the moment

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
the iterator, and we loop another time. When there are no more values, the `for` loop is over. <del> In our example, the `range` function is a function, provided by Rust, that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </del> <ins> In our example, `range` is a function that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </ins> Rust does not have the "C style" `for` loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C

Discussion:
Section 11.1, for loops says "In our example, the range function is a function, provided by Rust, " The repetition of the word "function" is awkward. The "provided by Rust" is redundant. I suggest re-wording to: "The range function takes a start and end position, and returns an iterator over those values."

Section 5, Variable bindings, mentions "Well, Rust has this thing called "Hindley-Milner type inference", named after some really smart type theorists." This is a minor nitpick, but I cringed when I read that sentence. There are lots of features in Rust that are the result of work by smart people. There is no need to single out the Hindley-Milner algorithm. Also the follow on text seems a bit patronising "If you clicked that link, don't be scared:" Writing like that tends to perpetuate the idea that type inference is deep magic, when it is not. I expect many people reading the Rust guide will be familiar with type inference, even the HM algorithm. It is fine to link to the Wikipedia article, but I think the Guide should not imply that it is a difficult topic or something which is scary.
I very strongly disagree with this, but do agree that I don't have the right tone here. !
I'd call this fallacy "Appeal to unfamiliar notation."
If stylistic concerns are not compelling, there is a good technical one: Rust no longer uses H-M type inference. See and that mentions abandoning H-M.
Oh, I mean, I do think that style arguments are. Didn't mean to imply otherwise. But I also forgot that we switched, so thanks for the reminder.=
Rust also never really used H-M.
Change:
<del> Subproject commit 1cf1a2e40a6867948db84f806085a875fbefce3c </del> <ins> Subproject commit de0800e83b4e15cf3c6aa8f15f8328e86a95d955 </ins>

Discussion:
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!
Yeah I expected that PR to break Miri.^^ I'll look into it.
I'll take a look.
Is there a failed CI job that I can look at?
Thanks for the offer! However, this will be much easier to do with some Miri experience, so in the interest of getting Miri to work again ASAP, it's probably better if I do it.
Oh, certainly. I spent some time trying to learn how to get Miri building and running, which I have always wanted to do, anyway. Here's my first attempt at fixing it: Pretty obvious stuff, I guess.
Change:
<ins> /// When reexporting this function, make sure the anonymous lifetimes are not rendered. /// /// https://github.com/rust-lang/rust/issues/98697 pub fn repro<F>() where F: Fn(&str), { unimplemented!() } </ins>

Discussion:
The correct behavior is for both crates' docs to render as: <img src="https://user-" height="100"However, recent versions of nightly rustdoc render as the above, while rendering incorrectly as: <img src="https://user-" height="100"I believe this is a bug because that is not valid syntax in Rust.
bisects to in nightly-2022-06-23 ( &mdash;
Example affecting the standard library docs: not affected. <img src="https://user-" height="100"- broken. <img src="https://user-" height="100"
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // no-prefer-dynamic </ins> thread_local!(static FOO: Foo = Foo); thread_local!(static BAR: Bar = Bar(1)); thread_local!(static BAZ: Baz = Baz);

Discussion:
Not even sure if this is a real bug or not, but it's 100% reproducible in my environment, even after .
This is also reproducible on a completely i686 toolchain and environment (only the processor is x64, edit: also the kernel), see and some build logs: I currently have an uncleaned build tree with the failing compiled test files intact, in case you have further ideas on how to debug this. (I already tried setting to 10x the default value and it's still failing.)
I can reproduce this outside of the bootstrap as well. By downloading the i686 linux nightlies and compiling this tests I get the same valgrind error. I'm not really sure if it's legitimate or not, as it only causes weird behavior in valgrind...
Here's the proc-mem map from vgdb
Hm, shouldn't we at least file a bug upstream to valgrind?
Perhaps, yeah, but I'm also not confident that it's a bug in valgrind, so it may be premature to do so
I can confirm that it fixed the test failure on Debian i386 and the build is now green on this arch. Thanks
Also fixed on my ubuntu builds. However, I'd suggest that we file this to valgrind even if we're "not sure" if it's a bug, since otherwise this is going to get lost to history - the issue is "closed" and nobody looks at these afterwards.
Sure, go ahead !
Alright I filed feel free to add details, I'm not an expert in this topic.
Change:
// not ever be possible for us to pass this flag. no_default_libraries: false, has_thread_local: true, <del> debuginfo_kind: DebuginfoKind::Pdb, </del> ..base }

Discussion:
The UEFI targets (x8664-unknown-uefi, i686-unknown-uefi, and aarch64-unknown-uefi) started failing to compile in the latest nightly when using , failing with "LLVM ERROR: dwo only supported with ELF and Wasm". : : Build: searched nightlies: from nightly-2022-08-25 to nightly-2022-08-27 regressed nightly: nightly-2022-08-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsCC since bisect pointed to
Can confirm. Definitely needs to be looked into by the team — can you reproduce this?
I see in that is set in . I think that needs to be in , or maybe directly in ? I tested this out locally by using a custom target JSON that matches except adds , and that seems to fix the bug.
Change:
fn suggest_traits_to_import<'a, 'tcx>(fcx: &FnCtxt<'a, 'tcx>, span: Span, <del> _rcvr_ty: Ty<'tcx>, </del> <ins> rcvr_ty: Ty<'tcx>, </ins> method_name: ast::Name, valid_out_of_scope_traits: Vec<ast::DefId>) {

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.