jiebi/CodeConvo huggingface dataset:
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)) //~^ ERROR cannot return value referencing function parameter `y` .collect::<Vec<_>>(); } </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: <ins> error[E0515]: cannot return value referencing function parameter `y` --> $DIR/issue-81584.rs:5:22 | LL |             .map(|y| y.iter().map(|x| x + 1)) |                      -^^^^^^^^^^^^^^^^^^^^^^ |                      | |                      returns a value referencing data owned by the current function |                      `y` is borrowed here | = help: use `.collect()` to allocate the iterator error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </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: | |                   ------------------------------ temporary value created here LL | |     } | |_____^ returns a value referencing data owned by the current function <ins> | = help: use `.collect()` to allocate the iterator </ins> error: aborting due to 4 previous errors
Code change:
The LLDB provider for hash maps has been broken since . Repro: Run this, notice that it doesn't print any values for the hash map: Using an older version works (1.49 or earler): I don't understand the motivation for , as you can see the older versions are able to display the type. can you clarify what is going on? I did some debugging, and the and values are invalid. Another way to check this is to run the  test. Due to it hasn't been running on CI. It has a check for the following output: But the actual output is:
I checked the issue with two different LLDB: shipped with LLDB built from LLVM 10.0.1 sources with Rust patches by adding the following code to the method: So it seems like the problem only occurs with . Probably this is due to the lack of Rust patches in . AFAIU the Rust patches still have not been to (I remember this related issue ). To fix this problem, the following code should be used insted: I've opened a PR with these changes: However, I believe that should use Rust patches not only to avoid this specific problem but to provide a much better debugging experience, with proper type rendering (e.g. instead of ), some expression evaluation support, and so forth. It is really unfortunate that Rust debugging support is not maintained enough except for some independent forks, for example, and CLion's LLDB.
I may be misunderstanding you, but is just a that runs the system lldb. Building lldb with patches was removed a long time ago (), and I suspect is not coming back in the foreseeable future.
Oh, that's even worse since macOS LLDB has very poor Rust support. I believe that debugging support is crucial for any compiled programming language, surely including Rust. So it would be really great to consider shipping rust-enabled LLDB and, more importantly, to maintain and improve Rust support in both GDB and LLDB.

Related discussion:
text: ctrl = table.GetChildMemberWithName("ctrl").GetChildAtIndex(0) self.size = table.GetChildMemberWithName("items").GetValueAsUnsigned() <del> self.pair_type = table.type.template_args[0].GetTypedefedType() </del> <ins> self.pair_type = table.type.template_args[0] if self.pair_type.IsTypedefType(): self.pair_type = self.pair_type.GetTypedefedType() </ins> self.pair_type_size = self.pair_type.GetByteSize() self.new_layout = not table.GetChildMemberWithName("data").IsValid()
Code change:
Hi, When running doc-tests with the latest Nightly on my crate, I get an ICE after the first doc-test is executed twice in a row. The issue does not occur on Stable. The issue seems to be caused when multiple threads are used for doc-tests. The ICE is caused by in . The issue occured on the and targets. Curiously, there are multiple targets on which it does not occur (according to Travic CI builds). The Travis CI build status is available here : . the repo for the ; commit ; either or . The actual number of threads does not seem to matter as long as there is more than one. In my case, specifying was not necessary, since I think the number of threads is determined automatically in this case. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is now a regression from stable to beta.
Bisection says the regression happened in . label -E-needs-bisection
cc do you have time to take a look?
It seems like the underlying problem is that it’s possible for different tests to collide to the same when macros are involved. Minimal example: /// asserteq!(1, 1); /// /// asserteq!(1, 1); /// Before , this produced and now it panics. We should fix the underlying problem, but a simple band-aid for beta would be to turn the into an . The only side effect would be that we don’t get the benefits of in the presence of these collisions.
I’ve submitted that workaround as .

Related discussion:
text: } let mut completed_test = res.unwrap(); <del> let running_test = running_tests.remove(&completed_test.desc).unwrap(); if let Some(join_handle) = running_test.join_handle { if let Err(_) = join_handle.join() { if let TrOk = completed_test.result { completed_test.result = TrFailedMsg("panicked after reporting success".to_string()); </del> <ins> if let Some(running_test) = running_tests.remove(&completed_test.desc) { if let Some(join_handle) = running_test.join_handle { if let Err(_) = join_handle.join() { if let TrOk = completed_test.result { completed_test.result = TrFailedMsg("panicked after reporting success".to_string()); } </ins> } } }
Code change:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!

Related discussion:
text: | GenericArgKind::Const(_), _, ) => { <del> // I *think* that HIR lowering should ensure this // doesn't happen, even in erroneous // programs. Else we should use delay-span-bug. span_bug!( </del> <ins> // HIR lowering sometimes doesn't catch this in erroneous // programs, so we need to use delay_span_bug here. See #82126. self.infcx.tcx.sess.delay_span_bug( </ins> hir_arg.span(), <del> "unmatched subst and hir arg: found {:?} vs {:?}", kind, hir_arg, </del> <ins> &format!("unmatched subst and hir arg: found {:?} vs {:?}", kind, hir_arg), </ins> ); } }
Code change:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!

Related discussion:
text: <ins> // Regression test for #82126. Checks that mismatched lifetimes and types are // properly handled. // edition:2018 use std::sync::Mutex; struct MarketMultiplier {} impl MarketMultiplier { fn buy(&mut self) -> &mut usize { todo!() } } async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { //~^ ERROR this struct takes 0 lifetime arguments but 1 lifetime argument was supplied //~^^ ERROR this struct takes 1 type argument but 0 type arguments were supplied LockedMarket(generator.lock().unwrap().buy()) //~^ ERROR cannot return value referencing temporary value } struct LockedMarket<T>(T); fn main() {} </ins>
Code change:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!

Related discussion:
text: <ins> error[E0107]: this struct takes 0 lifetime arguments but 1 lifetime argument was supplied --> $DIR/issue-82126-mismatched-subst-and-hir.rs:16:59 | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { |                                                           ^^^^^^^^^^^^---- help: remove these generics |                                                           | |                                                           expected 0 lifetime arguments | note: struct defined here, with 0 lifetime parameters --> $DIR/issue-82126-mismatched-subst-and-hir.rs:23:8 | LL | struct LockedMarket<T>(T); |        ^^^^^^^^^^^^ error[E0107]: this struct takes 1 type argument but 0 type arguments were supplied --> $DIR/issue-82126-mismatched-subst-and-hir.rs:16:59 | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { |                                                           ^^^^^^^^^^^^ expected 1 type argument | note: struct defined here, with 1 type parameter: `T` --> $DIR/issue-82126-mismatched-subst-and-hir.rs:23:8 | LL | struct LockedMarket<T>(T); |        ^^^^^^^^^^^^ - help: add missing type argument | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_, T> { |                                                                          ^^^ error[E0515]: cannot return value referencing temporary value --> $DIR/issue-82126-mismatched-subst-and-hir.rs:19:5 | LL |     LockedMarket(generator.lock().unwrap().buy()) |     ^^^^^^^^^^^^^-------------------------^^^^^^^ |     |            | |     |            temporary value created here |     returns a value referencing data owned by the current function error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0515. For more information about an error, try `rustc --explain E0107`. </ins>
Code change:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.

Related discussion:
text: fn run(self, builder: &Builder<'_>) -> Option<PathBuf> { let compiler = self.compiler; let target = self.target; <del> let tool = self.tool; </del> <ins> let mut tool = self.tool; </ins> let path = self.path; let is_optional_tool = self.is_optional_tool;
Code change:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.

Related discussion:
text: None } } else { <ins> // HACK(#82501): on Windows, the tools directory gets added to PATH when running tests, and // compiletest confuses HTML tidy with the in-tree tidy. Name the in-tree tidy something // different so the problem doesn't come up. if tool == "tidy" { tool = "rust-tidy"; } </ins> let cargo_out = builder.cargo_out(compiler, self.mode, target).join(exe(tool, compiler.host)); let bin = builder.tools_dir(compiler).join(exe(tool, compiler.host));
Code change:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.

Related discussion:
text: version = "0.1.0" authors = ["Alex Crichton <alex@alexcrichton.com>"] edition = "2018" <ins> autobins = false </ins> [dependencies] cargo_metadata = "0.11" regex = "1" lazy_static = "1" walkdir = "2" <ins> [[bin]] name = "rust-tidy" path = "src/main.rs" </ins>
Code change:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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
Caused by :

Related discussion:
text: use rustc_hir::{ExprKind, ItemKind, Node}; use rustc_infer::infer; use rustc_middle::lint::in_external_macro; <del> use rustc_middle::ty::{self, Ty}; </del> <ins> use rustc_middle::ty::{self, Binder, Ty}; </ins> use rustc_span::symbol::kw; use std::iter;
Code change:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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
Caused by :

Related discussion:
text: let found = self.resolve_vars_with_obligations(found); if let hir::FnRetTy::Return(ty) = fn_decl.output { let ty = AstConv::ast_ty_to_ty(self, ty); <ins> let ty = self.tcx.erase_late_bound_regions(Binder::bind(ty)); </ins> let ty = self.normalize_associated_types_in(expr.span, ty); if self.can_coerce(found, ty) { err.multipart_suggestion(
Code change:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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
Caused by :

Related discussion:
text: <ins> // Regression test for #82612. use std::marker::PhantomData; pub trait SparseSetIndex { fn sparse_set_index(&self) -> usize; } pub struct SparseArray<I, V = I> { values: Vec<Option<V>>, marker: PhantomData<I>, } impl<I: SparseSetIndex, V> SparseArray<I, V> { pub fn get_or_insert_with(&mut self, index: I, func: impl FnOnce() -> V) -> &mut V { let index = index.sparse_set_index(); if index < self.values.len() { let value = unsafe { self.values.get_unchecked_mut(index) }; value.get_or_insert_with(func) //~ ERROR mismatched types } unsafe { self.values.get_unchecked_mut(index).as_mut().unwrap() } } } fn main() {} </ins>
Code change:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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
Caused by :

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/issue-82612-return-mutable-reference.rs:18:13 | LL | /         if index < self.values.len() { LL | |             let value = unsafe { self.values.get_unchecked_mut(index) }; LL | |             value.get_or_insert_with(func) | |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `&mut V` LL | |         } | |_________- expected this to be `()` | = note:      expected unit type `()` found mutable reference `&mut V` help: consider using a semicolon here | LL |             value.get_or_insert_with(func); |                                           ^ help: consider using a semicolon here | LL |         }; |          ^ help: you might have meant to return this value | LL |             return value.get_or_insert_with(func); |             ^^^^^^                               ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>