jiebi/CodeConvo huggingface dataset:
Change:
let from = normalize(from); let to = normalize(to); trace!(?from, ?to); <ins> if from.has_non_region_infer() || to.has_non_region_infer() { tcx.sess.delay_span_bug(span, "argument to transmute has inference variables"); return; } </ins> // Transmutes that are only changing lifetimes are always ok. if from == to { return;

Discussion:
Found with a <details<summaryBacktrace</summary</details<details<summaryBacktrace</summary</detailsRegression in nightly-2022-05-28, perhaps from () nightly: 2022-11-18 on playground with debug assertions: slightly newer, built locally from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might be a duplicate of
Should be an easy fix, just need to delay a bug if the transmute source/target has (non-region) infer vars and bail from the fn.
claim
Change:
<ins> #![crate_name = "inner"] /// Links to [crate::g] pub fn f() {} pub fn g() {} </ins>

Discussion:
Crate exports from . is documented in quit and has no documentation in quitmacros. When that documentation has a link to , which is only in crate quit, it is unresolved. However, is resolved. Rustdoc gives no warnings with either. You can see the result with quit version 1.1.1 . cc cc
<details<summaryAll of this was wrong, I forgot to use +nightly</summaryThis isn't related to scopes, rustdoc will also fail to resolve these links: Something about the re-export itself is messing it up. </details
The good news is this is unrelated to proc-macros. Here's what I found: This is really strange. I would have expected it to resolve relative to , not relative to the current crate.
Ok, I found the issue: rustdoc and resolve disagree about which crate this is in For , rustdoc passes the original module of String, , and resolve correctly says there's no item named . But for , resolve thinks that refers to the current crate, not to alloc. This explains a lot of other broken links I've been seeing actually: anything that has will be wrong. So you were actually correct to start that this was the same issue as ;) The fix will be a little tricky ... there's no 'change ' button for resolve. There are a few things rustdoc can do: all links relative to the current module (the status quo before ). This is a no-go, because it means links will break on re-exports (). all links relative to the original module. This is what I thought was the current behavior. It means that additional documentation can't refer to things in the current lexical scope, which is non-intuitive (cc ). links in lexical scope: the original docs get resolved in the original module; the new docs get resolved in the module with the re-export. This is the ideal fix but somewhat hard to do because rustdoc doesn't distinguish between the two internally. A possible way to implement 2. is by stripping wherever we see it and resolving relative to the crate root instead of the current module. This is slightly_ hacky but should work fairly reliably.
Marking as P-high after discussing with ; it would be unfortunate to still have this bug on the first release after stabilization.
Change:
/// An iterator that splits an environment variable into paths according to /// platform-specific conventions. /// <ins> /// The iterator element type is [`PathBuf`]. /// </ins> /// This structure is created by the [`std::env::split_paths`] function. See its /// documentation for more. /// <ins> /// [`PathBuf`]: ../../std/path/struct.PathBuf.html </ins> /// [`std::env::split_paths`]: fn.split_paths.html #[stable(feature = "env", since = "1.0.0")] pub struct SplitPaths<'a> { inner: os_imp::SplitPaths<'a> }

Discussion:
Reading both and there's no specification that the type for the iterator is . To me it seemed ambiguous what an "iterator that splits an environment variable into paths" or "an iterator over the paths" returns since it could be the string representing the paths -- which is -- or an actual object. I'm happy to submit a PR if this is makes sense enough to fix (since according it used to specify this detail and now it doesn't with a quick perusal of not turning up anything obvious as to why the change).
If you unfold at the Trait Implementation section in you can see that . Did you mean that this should be more clearly mentioned in the description of (or maybe as well)? I do think it would be nice if some extra text on would be that clarifies the item type of the iterator!
since I didn't even think of expanding for the info (which in hindsight makes sense), my answer is "yes" , mentioning it explicitly as part of the main summary would be handy". As I said, if this is deemed reasonable I'm happy to do the PR to add the change.
That would be great! Let us know what you come up with!
Looks like someone snagged fixing this before I had a chance to get to it, so I'll let and its author handle fixing this.
Nice :) Let's wait for that then :)
Change:
<ins> //@ revisions: x86_64 aarch64 //@ assembly-output: emit-asm //@ compile-flags: --crate-type=lib -O //@[aarch64] only-aarch64 //@[x86_64] only-x86_64 //@[x86_64] compile-flags: -Ctarget-feature=+sse3 #![feature(portable_simd)] #![feature(core_intrinsics)] use std::intrinsics::simd as intrinsics; use std::simd::*; // Regression test for https://github.com/rust-lang/rust/issues/130028 // This intrinsic produces much worse code if you use +0.0 instead of -0.0 because // +0.0 isn't as easy to algebraically reassociate, even using LLVM's reassoc attribute! // It would emit about an extra fadd, depending on the architecture. // CHECK-LABEL: reduce_fadd_negative_zero pub unsafe fn reduce_fadd_negative_zero(v: f32x4) -> f32 { // x86_64: addps // x86_64-NEXT: movshdup // x86_64-NEXT: addss // x86_64-NOT: xorps // aarch64: faddp // aarch64-NEXT: faddp // CHECK-NOT: {{f?}}add{{p?s*}} // CHECK: ret intrinsics::simd_reduce_add_unordered(v) } </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. --Code generation for generates an extra floating-point add that adds +0.0 to the result: The problem seems to be because the compiler uses +0.0 as the starting value of instead of -0.0. Comparing LLVM code generation for the two cases, we get the more efficient version when using -0.0: This generates the following assembly for AArch64: To me, this behaviour seems to be caused by using +0.0 instead of -0.0 here in the compiler:
This sounds somewhat related to
Yeah, this is fixed by
wait, not in the... sec, will PR.
Change:
<ins> // Copyright 2014 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. trait Common {} impl<'t, T> Common for (T, &'t T) {} impl<'t, T> Common for (&'t T, T) {} fn main() {} </ins>

Discussion:
This is a minimal reproduction of something I saw when updating some of my projects to use . This manifested in other ways in larger programs, ICEing in one case: This can be reproduced by taking and changing lines 592 and 598 of to use partial type hints. cc
Maybe partial type hints need feature gating.
I knew that feature was too easy to implement... Lets see if I can find the cause.
Well, I'm not sure how to fix this. This inference error implies to me that partial type hints actually don't work at all for the case right now, and the existing tests didn't catch it because they inferred right from both sides. According to this is because the in and don't have any direct constrain to be identical. (Which would be possible with HKT though) While there is a , this link is apparently not currently considered, leading to the inference failure here. cc
Any idea why there are so many stacks in the backtrace? Does a non- build not contain enough debug info for libbacktrace to work off of?
I expect that there would be other ways of hitting these same inference bugs.
This is working on 0.12 and master: I'm sure one of PR that got merged in the last two months fixed inference from partial hints. Not sure which one though. I think this should be closed. (Unless someone got another test case that fails to infer from partial hints)
:dancer: I've been meaning to look into why this doesn't work. Happy to not have to.
Change:
self.tail = 0; self.head = len; } <del> } else if free >= self.head { </del> <ins> } else if free > self.head { // FIXME: We currently do not consider ....ABCDEFGH // to be contiguous because `head` would be `0` in this // case. While we probably want to change this it // isn't trivial as a few places expect `is_contiguous` // to mean that we can just slice using `buf[tail..head]`. </ins> // there is enough free space to copy the head in one go, // this means that we first shift the tail forwards, and then // copy the head to the correct position.

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. --This is my first bug report, so please correct me s if I miss anything :-) I use VecDeque<u8in a toy application () which is handling external reads in a loop, and does possible partial handling of the input. My pattern is I call reserve(N) before pushback() N times, then makecontiguous(), then doing some popfront(). I noticed the app was behaving badly, and was able to generate a stand-alone test case which shows the bug. The code is pretty boring and repetitive, so I put it at to avoid spamming here. Just issue "cargo run" after cloning out that code, and look for the word "BUG" within the terminal output: According to the docs, popfront() on an empty VecDeque should return None. Instead, this happens: If I set the boolean "doreserve" to be false, thus getting rid of all the reserve() calls, I get the expected behavior: The same happens if I set "domake_contiguous" to false as well - so calling both functions is a prerequisite to trigger the bug. The same thing happens in debug and release builds. <!-- 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 below is the version I found it in, but thanks a lot to Steve Klabnik for also testing it on nightly and getting the same buggy behavior. :
I created a minimal sample:
Hmm, if it double-frees then why does Miri not catch it?
Assigning and removing as in the prioritization working group.
Some time ago I've read somewhere that Rust stdlib VecDeque is cursed. I didn't believe them. I'm changing opinion... -.-
This specific case doesn't double free (i32::drop is a noop), using a might have been a better example...
Still, this is memory-unsafe, right?
Yes, It's still a use-after-free regardless
claim
Based on my conversation with lcnr, jonas-schievink, and others , it seems that using with copy types is not UB (it still exhibits a bug though!) because copy types aren't freed. It is UB with non-copy types though (e.g. ).
Change:
offset += machine::llsize_of_alloc(ccx, val_ty(val)); } <del> if offset < st.min_size.bytes() { cfields.push(padding(ccx, st.min_size.bytes() - offset)); </del> <ins> if offset < st.stride().bytes() { cfields.push(padding(ccx, st.stride().bytes() - offset)); </ins> } cfields

Discussion:
Running this code in either release or debug mode will yield a segfault: It looks like this also runs successfully on stable, just failing on beta/nightly cc
This looks very similar to .
This was introduced between and (). I'm no llvm ir expert, however I believe the following excerpts show the problem: The definition in the case is missing the padding between the slice elements. Edit: Note that this ir was obtained from a slightly modified code, the definition was changed to And the struct changed to Also, some manually edited impl's revealed that (in the modified case) the first is correctly handled as a , however the second is (which then leads to the segfault when trying read the string literal from an invalid address.
The following code reproduces the problem without the segfault: The expected hexdump would be (from the working nightly): The actual hexdump is:
Waiting on backport.
Reopened because this still affects beta.
Backported in , so closing.
Change:
} fn report_unused_parameter(tcx: TyCtxt<'_>, span: Span, kind: &str, name: &str) { <del> struct_span_err!( </del> <ins> let mut err = struct_span_err!( </ins> tcx.sess, span, E0207,

Discussion:
The following code does NOT compile: it errors with: However, when using normal generics in the places of the const generics, wrapping the in an and sticking that into the struct does work: Is it intended that const generic dont mimmic this behaviour?
This is probably a decision that has to be made (although if it is disallowed, then we'd want a better error message). However, at present, this is a implementation limitation: we really only properly support const generics of the form at the moment (cc ).
Considering that anon consts are mostly just projections, wouldn't this be similar to which doesn't really make a lot of sense (we have to guarantee that the projection maps each value of to a unique type). While is injective, finding an intuitive subset of expressions for which this is the case is hard and imo not actually desirable rn. Not quite sure what's the best error message though :thinking: probably something like
That's a good point I think adding a note explaining the problem would be the best solution, though the tricky part is working out how to explain it concisely (rather than just stating what the problem is).
Change:
/// /// It is often expected that if you can obtain an object of type `T`, then /// you can name the type `T` as well, this lint attempts to enforce this rule. <ins> /// The recommended action is to either reexport the type properly to make it nameable, /// or document that users are not supposed to be able to name it for one reason or another. /// /// Besides types, this lint applies to traits because traits can also leak through signatures, /// and you may obtain objects of their `dyn Trait` or `impl Trait` types. </ins> pub UNNAMEABLE_TYPES, Allow, "effective visibility of a type is larger than the area in which it can be named", <del> @feature_gate = sym::type_privacy_lints; </del> } declare_lint! {

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
}; for id in ids { self.check_gated_lint(id, DUMMY_SP); <del> let src = LintSource::CommandLine(lint_flag_val); </del> <ins> let src = LintSource::CommandLine(lint_flag_val, orig_level); </ins> specs.insert(id, (level, src)); } }

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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
} } <del> ty </del> <ins> // Typeck doesn't expect erased regions to be returned from `type_of`. tcx.fold_regions(&ty, &mut false, |r, _| match r { ty::ReErased => tcx.lifetimes.re_static, _ => r, }) </ins> } fn report_assoc_ty_on_inherent_impl(tcx: TyCtxt<'_>, span: Span) {

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit:
This is presumably due to -- cc
This was . Tagging it as . Not removing nomination until we can assign this issue.
assign (assigning based on claim that this was injected by PR )
This is the feature where for a with a missing type will look at the body and get the type from there. We should replace all regions in that situation with , just so the code which ICEs here will continue to ICE for legitimate bugs.
Doesn't reproduce with ( ):
Hmmmm, I'm not sure I agree with that assessment, unless -- well -- I guess you're saying that the "correct static type" for any such expression would be anyway?
yes, this is recovery for a guaranteed error, after all. A slightly more aggressive example: Results in this query stack for the ICE: I have no idea why changing to changes anything but they should both ICE IMO (before we switch to replacing erased regions with ). I'm now worried there are other places in which is used to extract some type and "export" it outside of the context of the body, without the necessary precautions.
Change:
name = variant.name.as_ref().unwrap(), ); for field in fields { <del> use crate::clean::StructFieldItem; if let StructFieldItem(ref ty) = *field.kind { let id = cx.derive_id(format!( "variant.{}.field.{}", variant.name.as_ref().unwrap(), field.name.as_ref().unwrap() )); write!( w, "<span id="{id}" class="variant small-section-header"> <a href="#{id}" class="anchor field"></a> <code>{f}:&nbsp;{t}</code> </span>", id = id, f = field.name.as_ref().unwrap(), t = ty.print(cx) ); document(w, cx, field, Some(variant)); </del> <ins> match *field.kind { clean::StrippedItem(box clean::StructFieldItem(_)) => {} clean::StructFieldItem(ref ty) => { let id = cx.derive_id(format!( "variant.{}.field.{}", variant.name.as_ref().unwrap(), field.name.as_ref().unwrap() )); write!( w, "<span id="{id}" class="variant small-section-header"> <a href="#{id}" class="anchor field"></a> <code>{f}:&nbsp;{t}</code> </span>", id = id, f = field.name.as_ref().unwrap(), t = ty.print(cx) ); document(w, cx, field, Some(variant)); } _ => unreachable!(), </ins> } } w.write_str("</div></div>");

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. --panics when running . This seems to come from cc <!-- 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
what is that attribute intended to do? Enum fields are always public.
I wanted to hide the field from docs because it was not important. But I agree it's probably a bit strange.
Assigning priority as in the prioritization working group.
Change:
// At the bottom of this function, we invert `inverse_memory_index` to // produce `memory_index` (see `invert_mapping`). <ins> let mut sized = true; let mut offsets = vec![Size::ZERO; fields.len()]; </ins> let mut offset = Size::ZERO; let mut largest_niche = None; let mut largest_niche_available = 0;

Discussion:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(