jiebi/CodeConvo huggingface dataset:
Code change:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :

Related discussion:
text: /// ``` #[lang = "index_mut"] #[rustc_on_unimplemented( <ins> on( _Self="&str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="std::string::String", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), </ins> message="the type `{Self}` cannot be mutably indexed by `{Idx}`", label="`{Self}` cannot be mutably indexed by `{Idx}`", )]
Code change:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :

Related discussion:
text: |                 ^^^^ `str` cannot be indexed by `{integer}` | = help: the trait `std::ops::Index<{integer}>` is not implemented for `str` <ins> = note: you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings> </ins> error: aborting due to previous error
Code change:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :

Related discussion:
text: |     ^^^^^^^^^ `str` cannot be mutably indexed by `usize` | = help: the trait `std::ops::IndexMut<usize>` is not implemented for `str` <ins> = note: you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings> </ins> error: aborting due to 3 previous errors
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: ///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: !preds.is_empty() && { let ty_empty_region = cx.tcx.mk_imm_ref(cx.tcx.lifetimes.re_root_empty, ty); preds.iter().all(|t| { <del> let ty_params = &t.skip_binder().trait_ref.substs.iter().skip(1).collect::<Vec<_>>(); </del> <ins> let ty_params = &t .skip_binder() .trait_ref .substs .iter() .skip(1) .collect::<Vec<_>>(); </ins> implements_trait(cx, ty_empty_region, t.def_id(), ty_params) }) },
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: /// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: declare_clippy_lint! { /// **What it does:** This lint warns when you use `print!()` with a format <del> /// string that ends in a newline. </del> <ins> /// string that /// ends in a newline. </ins> /// /// **Why is this bad?** You should use `println!()` instead, which appends the /// newline.
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: /// # use std::fmt::Write; /// # let mut buf = String::new(); /// # let name = "World"; <del> /// /// // Bad </del> /// write!(buf, "Hello {}!n", name); <del> /// /// // Good /// writeln!(buf, "Hello {}!", name); </del> /// ``` pub WRITE_WITH_NEWLINE, style,
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: /// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: } fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,
Code change:
When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.

Related discussion:
text: <ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>
Code change:
As of rustc 1.33.0-nightly ( 2018-12-22) the following macro invocation fails with an ICE. Mentioning and because this may have to do with slicing introduced in . Same repro in script form:
is working on a solution in

Related discussion:
text: ); // See https://github.com/rust-lang/rust/issues/32354 <del> if old_binding.is_import() || new_binding.is_import() { let binding = if new_binding.is_import() && !new_binding.span.is_dummy() { new_binding </del> <ins> let directive = match (&new_binding.kind, &old_binding.kind) { (NameBindingKind::Import { directive, .. }, _) if !new_binding.span.is_dummy() => Some((directive, new_binding.span)), (_, NameBindingKind::Import { directive, .. }) if !old_binding.span.is_dummy() => Some((directive, old_binding.span)), _ => None, }; if let Some((directive, binding_span)) = directive { let suggested_name = if name.as_str().chars().next().unwrap().is_uppercase() { format!("Other{}", name) </ins> } else { <del> old_binding </del> <ins> format!("other_{}", name) </ins> }; <del> let cm = self.session.source_map(); let rename_msg = "you can use `as` to change the binding name of the import"; if let ( Ok(snippet), NameBindingKind::Import { directive, ..}, _dummy @ false, ) = ( cm.span_to_snippet(binding.span), binding.kind.clone(), binding.span.is_dummy(), ) { let suggested_name = if name.as_str().chars().next().unwrap().is_uppercase() { format!("Other{}", name) } else { format!("other_{}", name) }; </del> <ins> let mut suggestion = None; match directive.subclass { ImportDirectiveSubclass::SingleImport { type_ns_only: true, .. } => suggestion = Some(format!("self as {}", suggested_name)), ImportDirectiveSubclass::SingleImport { source, .. } => { if let Some(pos) = source.span.hi().0.checked_sub(binding_span.lo().0) .map(|pos| pos as usize) { if let Ok(snippet) = self.session.source_map() .span_to_snippet(binding_span) { if pos <= snippet.len() { suggestion = Some(format!( "{} as {}{}", &snippet[..pos], suggested_name, if snippet.ends_with(";") { ";" } else { "" } )) } } } } ImportDirectiveSubclass::ExternCrate { source, target, .. } => suggestion = Some(format!( "extern crate {} as {};", source.unwrap_or(target.name), suggested_name, )), _ => unreachable!(), } let rename_msg = "you can use `as` to change the binding name of the import"; if let Some(suggestion) = suggestion { </ins> err.span_suggestion_with_applicability( <del> binding.span, &rename_msg, match directive.subclass { ImportDirectiveSubclass::SingleImport { type_ns_only: true, .. } => format!("self as {}", suggested_name), ImportDirectiveSubclass::SingleImport { source, .. } => format!( "{} as {}{}", &snippet[..((source.span.hi().0 - binding.span.lo().0) as usize)], suggested_name, if snippet.ends_with(";") { ";" } else { "" } ), ImportDirectiveSubclass::ExternCrate { source, target, .. } => format!( "extern crate {} as {};", source.unwrap_or(target.name), suggested_name, ), _ => unreachable!(), }, </del> <ins> binding_span, rename_msg, suggestion, </ins> Applicability::MaybeIncorrect, ); } else { <del> err.span_label(binding.span, rename_msg); </del> <ins> err.span_label(binding_span, rename_msg); </ins> } }