jiebi/CodeConvo huggingface dataset:
Code change:
The "Notable traits" popup for [] shows notable traits for when it should show (or at least ): ! Note that this happens for other functions on . Another example is [] which shows when it should show . I'm not 100% sure this is a bug, but the behavior is definitely confusing: I'm not sure what the notable traits popup is referring to when it references an type parameter ( doesn't even appear in the file that is defined in...). []: []:
I think this is a duplicate of
Hmm, that seems possible. Wow, that issue is so old: it refers to ! Off-topic: is there a way to see what the docs from then look like?
Yes, you can manually type the version number in the URL:
Thanks! I forgot about that. However, I meant for the docs pre-1.0. Do you know of any way to view those?
Followup: 0.11.0 is the earliest version I could find docs for:

Related discussion:
text: <ins> //! Test case for [#80737]. //! //! A SomeTrait that is implemented for `&mut T where T: SomeTrait` //! should not be marked as "notable" for return values that do not //! have bounds on the trait itself. //! //! [#80737]: https://github.com/rust-lang/rust/issues/80737 #![feature(rustdoc_internals)] #![no_std] #[doc(primitive = "reference")] /// Some useless docs, wouhou! /// /// We need to put this in here, because notable traits /// that are implemented on foreign types don't show up. mod reference {} // @has doc_notable_trait_mut_t_is_not_an_iterator/fn.fn_no_matches.html // @!has - '//code[@class="content"]' 'Iterator' pub fn fn_no_matches<'a, T: 'a>() -> &'a mut T { panic!() } </ins>
Code change:
A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test

Related discussion:
text: <ins> #![allow(unreachable_code)] use std::marker::PhantomData; use std::ops::Deref; use std::sync::Arc; pub struct Guard<T> { _phantom: PhantomData<T>, } impl<T> Deref for Guard<T> { type Target = T; fn deref(&self) -> &T { unimplemented!() } } pub struct DirectDeref<T>(T); impl<T> Deref for DirectDeref<Arc<T>> { type Target = T; fn deref(&self) -> &T { unimplemented!() } } pub trait Access<T> { type Guard: Deref<Target = T>; fn load(&self) -> Self::Guard { unimplemented!() } } impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { //~^ NOTE: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` type Guard = A::Guard; } impl<T> Access<T> for ArcSwapAny<T> { //~^ NOTE: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found type Guard = Guard<T>; } impl<T> Access<T> for ArcSwapAny<Arc<T>> { type Guard = DirectDeref<Arc<T>>; } pub struct ArcSwapAny<T> { _phantom_arc: PhantomData<T>, } pub fn foo() { let s: Arc<ArcSwapAny<Arc<usize>>> = unimplemented!(); let guard: Guard<Arc<usize>> = s.load(); //~^ ERROR: type annotations needed //~| HELP: try using a fully qualified path to specify the expected types } fn main() {} </ins>
Code change:
A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test

Related discussion:
text: <ins> error[E0283]: type annotations needed --> $DIR/issue-80816.rs:49:38 | LL |     let guard: Guard<Arc<usize>> = s.load(); |                                      ^^^^ | note: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found --> $DIR/issue-80816.rs:35:1 | LL | impl<T> Access<T> for ArcSwapAny<T> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | impl<T> Access<T> for ArcSwapAny<Arc<T>> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` --> $DIR/issue-80816.rs:31:45 | LL | impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { |                                             ^^^^^^^^^     ^ help: try using a fully qualified path to specify the expected types | LL |     let guard: Guard<Arc<usize>> = <Arc<ArcSwapAny<Arc<usize>>> as Access<T>>::load(&s); |                                    ++++++++++++++++++++++++++++++++++++++++++++++++++ ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: fn source_info(&self, cx: &CodegenCx<'ll, 'tcx>) -> Option<SourceInfo<'ll>> { match self { VariantInfo::Generator { def_id, variant_index, .. } => { <del> let span = cx.tcx.generator_layout(*def_id).variant_source_info[*variant_index].span; </del> <ins> let span = cx.tcx.generator_layout(*def_id).unwrap().variant_source_info [*variant_index] .span; </ins> if !span.is_dummy() { let loc = cx.lookup_debug_loc(span.lo()); return Some(SourceInfo {
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: ) -> Result<&'tcx Layout, LayoutError<'tcx>> { use SavedLocalEligibility::*; let tcx = self.tcx; let subst_field = |ty: Ty<'tcx>| ty.subst(tcx, substs); <del> let info = tcx.generator_layout(def_id); </del> <ins> let info = match tcx.generator_layout(def_id) { None => return Err(LayoutError::Unknown(ty)), Some(info) => info, }; </ins> let (ineligible_locals, assignments) = self.generator_saved_local_eligibility(&info); // Build a prefix layout, including "promoting" all ineligible
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: self.trait_def(trait_def_id).has_auto_impl } <del> pub fn generator_layout(self, def_id: DefId) -> &'tcx GeneratorLayout<'tcx> { self.optimized_mir(def_id).generator_layout.as_ref().unwrap() </del> <ins> /// Returns layout of a generator. Layout might be unavailable if the /// generator is tainted by errors. pub fn generator_layout(self, def_id: DefId) -> Option<&'tcx GeneratorLayout<'tcx>> { self.optimized_mir(def_id).generator_layout.as_ref() </ins> } /// Given the `DefId` of an impl, returns the `DefId` of the trait it implements.
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: #[inline] pub fn variant_range(&self, def_id: DefId, tcx: TyCtxt<'tcx>) -> Range<VariantIdx> { // FIXME requires optimized MIR <del> let num_variants = tcx.generator_layout(def_id).variant_fields.len(); </del> <ins> let num_variants = tcx.generator_layout(def_id).unwrap().variant_fields.len(); </ins> VariantIdx::new(0)..VariantIdx::new(num_variants) }
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: def_id: DefId, tcx: TyCtxt<'tcx>, ) -> impl Iterator<Item = impl Iterator<Item = Ty<'tcx>> + Captures<'tcx>> { <del> let layout = tcx.generator_layout(def_id); </del> <ins> let layout = tcx.generator_layout(def_id).unwrap(); </ins> layout.variant_fields.iter().map(move |variant| { variant.iter().map(move |field| layout.field_tys[*field].subst(tcx, self.substs)) })
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: <ins> // Verifies that computing a layout of a generator tainted by type errors // doesn't ICE. Regression test for #80998. // // edition:2018 #![feature(type_alias_impl_trait)] use std::future::Future; pub struct Task<F: Future>(F); impl<F: Future> Task<F> { fn new() -> Self { todo!() } fn spawn(&self, _: impl FnOnce() -> F) { todo!() } } fn main() { async fn cb() { let a = Foo; //~ ERROR cannot find value `Foo` in this scope } type F = impl Future; // Check that statics are inhabited computes they layout. static POOL: Task<F> = Task::new(); Task::spawn(&POOL, || cb()); } </ins>
Code change:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:

Related discussion:
text: <ins> error[E0425]: cannot find value `Foo` in this scope --> $DIR/layout-error.rs:21:17 | LL |         let a = Foo; |                 ^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>
Code change:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: debug!("exp_found {:?} terr {:?}", exp_found, terr); if let Some(exp_found) = exp_found { self.suggest_as_ref_where_appropriate(span, &exp_found, diag); <ins> self.suggest_accessing_field_where_appropriate(cause, &exp_found, diag); </ins> self.suggest_await_on_expect_found(cause, span, &exp_found, diag); }
Code change:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: } } <ins> fn suggest_accessing_field_where_appropriate( &self, cause: &ObligationCause<'tcx>, exp_found: &ty::error::ExpectedFound<Ty<'tcx>>, diag: &mut DiagnosticBuilder<'tcx>, ) { debug!( "suggest_accessing_field_where_appropriate(cause={:?}, exp_found={:?})", cause, exp_found ); if let ty::Adt(expected_def, expected_substs) = exp_found.expected.kind() { if expected_def.is_enum() { return; } if let Some((name, ty)) = expected_def .non_enum_variant() .fields .iter() .filter(|field| field.vis.is_accessible_from(field.did, self.tcx)) .map(|field| (field.ident.name, field.ty(self.tcx, expected_substs))) .find(|(_, ty)| ty::TyS::same_type(ty, exp_found.found)) { if let ObligationCauseCode::Pattern { span: Some(span), .. } = cause.code { if let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span) { let suggestion = if expected_def.is_struct() { format!("{}.{}", snippet, name) } else if expected_def.is_union() { format!("unsafe {{ {}.{} }}", snippet, name) } else { return; }; diag.span_suggestion( span, &format!( "you might have meant to use field `{}` of type `{}`", name, ty ), suggestion, Applicability::MaybeIncorrect, ); } } } } } </ins> /// When encountering a case where `.as_ref()` on a `Result` or `Option` would be appropriate, /// suggests it. fn suggest_as_ref_where_appropriate(
Code change:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: <ins> // run-rustfix #![allow(dead_code)] struct A { b: B, } enum B { Fst, Snd, } union Foo { bar: u32, qux: f32, } fn main() { let a = A { b: B::Fst }; if let B::Fst = a.b {}; //~ ERROR mismatched types [E0308] //~^ HELP you might have meant to use field `b` of type `B` match a.b { //~^ HELP you might have meant to use field `b` of type `B` //~| HELP you might have meant to use field `b` of type `B` B::Fst => (), //~ ERROR mismatched types [E0308] B::Snd => (), //~ ERROR mismatched types [E0308] } let foo = Foo { bar: 42 }; match unsafe { foo.bar } { //~^ HELP you might have meant to use field `bar` of type `u32` 1u32 => (), //~ ERROR mismatched types [E0308] _ => (), } } </ins>
Code change:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: <ins> // run-rustfix #![allow(dead_code)] struct A { b: B, } enum B { Fst, Snd, } union Foo { bar: u32, qux: f32, } fn main() { let a = A { b: B::Fst }; if let B::Fst = a {}; //~ ERROR mismatched types [E0308] //~^ HELP you might have meant to use field `b` of type `B` match a { //~^ HELP you might have meant to use field `b` of type `B` //~| HELP you might have meant to use field `b` of type `B` B::Fst => (), //~ ERROR mismatched types [E0308] B::Snd => (), //~ ERROR mismatched types [E0308] } let foo = Foo { bar: 42 }; match foo { //~^ HELP you might have meant to use field `bar` of type `u32` 1u32 => (), //~ ERROR mismatched types [E0308] _ => (), } } </ins>
Code change:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/field-access.rs:20:12 | LL |     Fst, |     --- unit variant defined here ... LL |     if let B::Fst = a {}; |            ^^^^^^   - this expression has type `A` |            | |            expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     if let B::Fst = a.b {}; |                     ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:25:9 | LL |     Fst, |     --- unit variant defined here ... LL |     match a { |           - this expression has type `A` ... LL |         B::Fst => (), |         ^^^^^^ expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     match a.b { |           ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:26:9 | LL |     Snd, |     --- unit variant defined here ... LL |     match a { |           - this expression has type `A` ... LL |         B::Snd => (), |         ^^^^^^ expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     match a.b { |           ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:32:9 | LL |     match foo { |           --- this expression has type `Foo` LL | LL |         1u32 => (), |         ^^^^ expected union `Foo`, found `u32` | help: you might have meant to use field `bar` of type `u32` | LL |     match unsafe { foo.bar } { |           ^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

Related discussion:
text: FakeReadCause, Local, LocalDecl, LocalInfo, LocalKind, Location, Operand, Place, PlaceRef, ProjectionElem, Rvalue, Statement, StatementKind, Terminator, TerminatorKind, VarBindingForm, }; <del> use rustc_middle::ty::{self, suggest_constraining_type_param, Instance, Ty}; use rustc_span::{source_map::DesugaringKind, symbol::sym, Span}; </del> <ins> use rustc_middle::ty::{self, suggest_constraining_type_param, Ty, TypeFoldable}; use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::sym; use rustc_span::Span; </ins> use crate::dataflow::drop_flag_effects; use crate::dataflow::indexes::{MoveOutIndex, MovePathIndex}; use crate::util::borrowck_errors; use crate::borrow_check::{ <del> borrow_set::BorrowData, prefixes::IsPrefixOf, InitializationRequiringAction, MirBorrowckCtxt, PrefixSet, WriteKind, </del> <ins> borrow_set::BorrowData, diagnostics::Instance, prefixes::IsPrefixOf, InitializationRequiringAction, MirBorrowckCtxt, PrefixSet, WriteKind, </ins> }; use super::{
Code change:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

Related discussion:
text: if return_span != borrow_span { err.span_label(borrow_span, note); <ins> let tcx = self.infcx.tcx; let ty_params = ty::List::empty(); let return_ty = self.regioncx.universal_regions().unnormalized_output_ty; let return_ty = tcx.erase_regions(return_ty); // to avoid panics if !return_ty.has_infer_types() { if let Some(iter_trait) = tcx.get_diagnostic_item(sym::Iterator) { if tcx.type_implements_trait((iter_trait, return_ty, ty_params, self.param_env)) { if let Ok(snippet) = tcx.sess.source_map().span_to_snippet(return_span) { err.span_suggestion_hidden( return_span, "use `.collect()` to allocate the iterator", format!("{}{}", snippet, ".collect::<Vec<_>>()"), Applicability::MaybeIncorrect, ); } } } } </ins> } Some(err)
Code change:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

Related discussion:
text: message = "`{Self}` is not an iterator" )] #[doc(spotlight)] <ins> #[rustc_diagnostic_item = "Iterator"] </ins> #[must_use = "iterators are lazy and do nothing unless consumed"] pub trait Iterator { /// The type of the elements being iterated over.
Code change:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.

Related discussion:
text: <ins> // run-rustfix fn main() { let _ = vec![vec![0, 1], vec![2]] .into_iter() .map(|y| y.iter().map(|x| x + 1).collect::<Vec<_>>()) //~^ ERROR cannot return value referencing function parameter `y` .collect::<Vec<_>>(); } </ins>