jiebi/CodeConvo huggingface dataset:
Change:
|     | |     required by a bound introduced by this call | <del> = note: consider using `Box::pin` </del> <ins> = note: consider using the `pin!` macro consider using `Box::pin` if you need to access the pinned value outside of the current scope </ins> note: required by a bound in `f_unpin` --> $DIR/issue-84973-blacklist.rs:8:15 |

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
<del> Subproject commit fed7a31cd93bbd3c8a9f38871838b59b5dce2a35 </del> <ins> Subproject commit 7c0489c5ff4f5c594e65a3b22efd9ce373deab9b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage P-medium removing nomination.
Change:
self.queries.on_disk_cache.serialize(self.global_tcx(), encoder) } <del> /// This checks whether one is allowed to have pattern bindings /// that bind-by-move on a match arm that has a guard, e.g.: /// /// ```rust /// match foo { A(inner) if { /* something */ } => ..., ... } /// ``` /// /// It is separate from check_for_mutation_in_guard_via_ast_walk, /// because that method has a narrower effect that can be toggled /// off via a separate `-Z` flag, at least for the short term. pub fn allow_bind_by_move_patterns_with_guards(self) -> bool { self.features().bind_by_move_pattern_guards } /// If true, we should use a naive AST walk to determine if match /// guard could perform bad mutations (or mutable-borrows). pub fn check_for_mutation_in_guard_via_ast_walk(self) -> bool { !self.allow_bind_by_move_patterns_with_guards() } </del> /// If true, we should use the AST-based borrowck (we may *also* use /// the MIR-based borrowck). pub fn use_ast_borrowck(self) -> bool {

Discussion:
Current handling of this feature goes through functions and . One or both of these functions should be removed. cc
NLL triage: prioritizing as P-medium.
Change:
} layout::StructWrappedNullablePointer { ref nonnull, nndiscr, .. } => { if discr.0 == nndiscr { <del> C_struct(ccx, &build_const_struct(ccx, &nonnull, vals), false) </del> <ins> C_struct(ccx, &build_const_struct(ccx, &nonnull, vals), false) </ins> } else { let fields = compute_fields(ccx, t, nndiscr as usize, false); let vals = fields.iter().map(|&ty| {

Discussion:
This code () gives me a segfault on the current beta: I've reduced it as much as I can, even removing the constructor on the enum causes it to work. I expect the output to be (which it is on stable), but instead I get
Appears to be broken on nightly as well - I get a stack overflow on x86_64 darwin.
FWIW, I don't get a segfault on beta or nightly with the playpen, I just get this output for both:
The stackoverflow on x86_64 darwin goes away for me on any .
This strongly reminds me of and .
Change:
- [Bumped minimum LLVM version to 5.0.][51899] - [Added `powerpc64le-unknown-linux-musl` target.][51619] - [Added `aarch64-unknown-hermit` and `x86_64-unknown-hermit` targets.][52861] <ins> - [Upgraded to LLVM 7.][51966] </ins> Libraries ---------

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
} } <ins> #[allow(semicolon_in_expressions_from_macros)] async fn bar() { foo!(first); } </ins> fn main() { // This `allow` doesn't work #[allow(semicolon_in_expressions_from_macros)]

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
use rustc_query_system::cache::Cache; pub type SelectionCache<'tcx> = Cache< <del> ty::ParamEnvAnd<'tcx, ty::TraitPredicate<'tcx>>, </del> <ins> // This cache does not use `ParamEnvAnd` in its keys because `ParamEnv::and` can replace // caller bounds with an empty list if the `TraitPredicate` looks global, which may happen // after erasing lifetimes from the predicate. (ty::ParamEnv<'tcx>, ty::TraitPredicate<'tcx>), </ins> SelectionResult<'tcx, SelectionCandidate<'tcx>>, >; <del> pub type EvaluationCache<'tcx> = Cache<ty::ParamEnvAnd<'tcx, ty::PolyTraitPredicate<'tcx>>, EvaluationResult>; </del> <ins> pub type EvaluationCache<'tcx> = Cache< // See above: this cache does not use `ParamEnvAnd` in its keys due to sometimes incorrectly // caching with the wrong `ParamEnv`. (ty::ParamEnv<'tcx>, ty::PolyTraitPredicate<'tcx>), EvaluationResult, >; </ins> /// The selection process begins by considering all impls, where /// clauses, and so forth that might resolve an obligation. Sometimes

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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This crashes nightly, beta and stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
<del> Subproject commit bebcf527e67755a989a1739b7cfaa8f0e6b30040 </del> <ins> Subproject commit 5e9051f71638aa941cd5dda465e25c61cde9594f </ins>

Discussion:
TOC entries for impls contain special characters like etc and the links are not sanitized correctly per pandoc's rules.
Change:
use crate::hair::*; use rustc_ast::ast::InlineAsmOptions; use rustc_data_structures::fx::FxHashMap; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_hir as hir; use rustc_middle::mir::*; use rustc_middle::ty::{self, CanonicalUserTypeAnnotation};

Discussion:
First reported to me at I believe the stack overflow is in rustc itself. when compiled yields: where nightly today is:
Assigning as and removing .
It would be nice to bisect this one if possible ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-05 to nightly-2020-07-22 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
cc for anyone wanting to fix this, these kind of bugs are very easy to fix. You run rustc in until you get a stack overflow, then you look at the backtrace and look for recursion in there. Then you break the recursion overflow by inserting a use of at the recursive call site.
That sounds a good first bug to me. I'll give it a shot.
Change:
) .is_ok() { <del> // Suppress this error, since we already emitted // a deref suggestion in check_overloaded_binop err.downgrade_to_delayed_bug(); </del> <ins> // If LHS += RHS is an error, but *LHS += RHS is successful, then we will have // emitted a better suggestion during error handling in check_overloaded_binop. if self .lookup_op_method( lhs_ty, Some(rhs_ty), Some(rhs), Op::Binary(op, IsAssign::Yes), expected, ) .is_err() { err.downgrade_to_delayed_bug(); } else { // Otherwise, it's valid to suggest dereferencing the LHS here. err.span_suggestion_verbose( lhs.span.shrink_to_lo(), "consider dereferencing the left-hand side of this operation", "*", Applicability::MaybeIncorrect, ); } </ins> } } });

Discussion:
: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(update, I've reproduced it on smaller example)
Error -ICE regression in 1.63 label regression-from-stable-to-stable
searched nightlies: from nightly-2022-05-01 to nightly-2022-07-01 regressed nightly: nightly-2022-05-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegresses in rollup , most likely , cc
claim
Change:
// For each `AllocId`, we keep track of which decoding state it's currently in. decoding_state: Vec<Lock<State>>, // The offsets of each allocation in the data stream. <del> data_offsets: Vec<u32>, </del> <ins> data_offsets: Vec<u64>, </ins> } impl AllocDecodingState {

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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:
Change:
# } fn compute_area(shape: &Shape) -> f64 { match *shape { <del> Circle(_, radius) => 2.0 * std::f64::consts::PI * radius * radius, </del> <ins> Circle(_, radius) => std::f64::consts::PI * radius * radius, </ins> Rectangle(_, ref size) => size.w * size.h } }

Discussion:
If I'm not mistaken, . It won't terminate the program. It's or unwraps the value. Also, wouldn't a call to the IoResult's  be more direct? Although the custom failure message would be lost.
I thought this was already fixed :/

Quoting the Rust References and Lifetimes Guide: Without arguing over the merits of pi versus tau, a Rust guide is not the place for introducing a less common mathematical notation that most people will not have seen. Doubly so because this is one of the specific cases where tau is less clear than pi; the equivalent code with pi would not need the extra factor of 0.5. And triply so because this should be using a constant from the standard library, like . All three make this an unnecessary distraction in the middle of a Rust tutorial guide.
This guide is being re-written, and I can assure you, there will be no Tau advocacy in it. That said, in the meantime I would accept a patch to fix this.=

Quoting the Rust Guide: This has two separate problems. First, C has no value named ; C has instead. Second, and more importantly, is not a valid value for a variable of type in C, because has pointer type (typically ). Making a direct analogy to C here requires Rust concepts not yet explained at this point in the guide (pointers). Two possible alternatives: either generalize the explanation a bit with less specific references to C and Rust syntax ("For example, any C string can be NULL, making it invalid to access as a string; a Rust string cannot be null and is always a valid string."). or make an analogy to another language that uses boxed types by default, such as Java.
Just change it from C to C++, since is usually a valid value of type there. ;)
This has been on my list for a while, :+1:. I think the comparison is bad, and would prefer to just re-write this paragraph.=
Change:
} } f!("Foonbar [BarF] barnbaz"); <ins> /** # for example, * * time to introduce a link [error]*/ pub struct A; /** * # for example, * * time to introduce a link [error] */ pub struct B; #[doc = "single line [error]"] pub struct C; #[doc = "single line with "escaping" [error]"] pub struct D; /// Item docs. #[doc="Hello there!"] /// [error] pub struct E; /// /// docs [error1] /// docs [error2] /// pub struct F; </ins>

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
<ins> pub trait Meow { fn meow(&self) {} } pub struct GlobalMeow; impl Meow for GlobalMeow {} pub(crate) struct PrivateMeow; impl Meow for PrivateMeow {} </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
} let from_layout = cx.layout_of(*inner_start_ty).ok()?; <ins> // if the type isn't sized, we bail out, instead of potentially giving // the user a meaningless warning. if from_layout.is_unsized() { return None; } </ins> let alloc_layout = cx.layout_of(alloc_ty).ok()?; let to_layout = cx.layout_of(*inner_end_ty).ok()?;

Discussion:
I believe this code is well defined. It runs successfully in Miri with . However, since (nightly-2024-02-14), the following deny-by-default lint is triggered in : Rustc thinks the is 0 bytes, whereas for the purpose of the memory model as I understand it, it has a runtime size that is bigger than 0 bytes.
The here is the size reported at compile time, which obviously doesn't make sense with DST, the lint implementation should be gated on the types being sized. (to be honest, I completely forgot about this). There should probably be an somewhere after this
My code is also regressing in this: Gives the error on nightly This doesn't involve DST though. But the pattern is the same as we just go through a which shouldn't count as a dereference.
Your sample code is as far as I can tell UB and with the lint. <subIf you want to continue this conversation, let's create a new issue as to not diverge this specific issue.</sub
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
} else if i == 0 { (format!("use of undeclared type or module `{}`", ident), None) } else { <del> (format!("could not find `{}` in `{}`", ident, path[i - 1].ident), None) </del> <ins> let mut msg = format!("could not find `{}` in `{}`", ident, path[i - 1].ident); if ns == TypeNS || ns == ValueNS { let ns_to_try = if ns == TypeNS { ValueNS } else { TypeNS }; if let FindBindingResult::Binding(Ok(binding)) = find_binding_in_ns(self, ns_to_try) { let mut found = |what| { msg = format!( "expected {}, found {} `{}` in `{}`", ns.descr(), what, ident, path[i - 1].ident ) }; if binding.module().is_some() { found("module") } else { match binding.res() { def::Res::<NodeId>::Def(kind, id) => found(kind.descr(id)), _ => found(ns_to_try.descr()), } } }; } (msg, None) </ins> }; return PathResult::Failed { span: ident.span,

Discussion:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- 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. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.
Change:
fn may_have_side_effect() -> bool { true } } <ins> #[doc(hidden)] unsafe impl<'a, I, T: 'a> TrustedRandomAccess for Cloned<I> where I: TrustedRandomAccess<Item=&'a T>, T: Copy { unsafe fn get_unchecked(&mut self, i: usize) -> Self::Item { *self.it.get_unchecked(i) } #[inline] fn may_have_side_effect() -> bool { false } } </ins> #[unstable(feature = "trusted_len", issue = "37572")] unsafe impl<'a, I, T: 'a> TrustedLen for Cloned<I> where I: TrustedLen<Item=&'a T>,

Discussion:
I compared the performance of three equivalent functions: This is results (release mode):
IIRC zip is specialized for slices which is why the last case is so much faster.
Try also to compile with
A question could be: is it possible for to return something similar to ?
It makes the two times faster, the speed of the and the has stayed the same as before.
You've discovered the "untweaked speed" of zip :frowning_face:, which is what has. can implement the same way slice iterators do, in fact is just a newtype around an iterator that already implements that trait.
Change:
#[unstable(feature = "proc_macro", issue = "38356")] impl iter::FromIterator<TokenTree> for TokenStream { fn from_iter<I: IntoIterator<Item = TokenTree>>(trees: I) -> Self { <ins> trees.into_iter().map(TokenStream::from).collect() } } #[unstable(feature = "proc_macro", issue = "38356")] impl iter::FromIterator<TokenStream> for TokenStream { fn from_iter<I: IntoIterator<Item = TokenStream>>(streams: I) -> Self { </ins> let mut builder = tokenstream::TokenStreamBuilder::new(); <del> for tree in trees { builder.push(tree.to_internal()); </del> <ins> for stream in streams { builder.push(stream.0); </ins> } TokenStream(builder.build()) }

Discussion:
Servo doesn’t build in today’s Nightly: Since the type is stable I think this is a breaking change. CC for
The type is stable, but that impl is . Edit: just realised that's not the impl in question, just wanted to say that I don't think it's a breaking change with regard to stable.
Oops. Indeed, that's a regression.
Egad sorry about that! I've posted to revert this change