jiebi/CodeConvo huggingface dataset:
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: Ok(()) } <ins> fn document_short(w: &mut fmt::Formatter, item: &clean::Item, link: AssocItemLink) -> fmt::Result { if let Some(s) = item.doc_value() { let markdown = if s.contains('n') { format!("{} [Read more]({})", &plain_summary_line(Some(s)), naive_assoc_href(item, link)) } else { format!("{}", &plain_summary_line(Some(s))) }; write!(w, "<div class='docblock'>{}</div>", Markdown(&markdown))?; } Ok(()) } </ins> fn item_module(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item, items: &[clean::Item]) -> fmt::Result { document(w, cx, item)?;
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: } fn doctraititem(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item, <del> link: AssocItemLink, render_static: bool, is_default_item: bool, outer_version: Option<&str>) -> fmt::Result { </del> <ins> link: AssocItemLink, render_static: bool, is_default_item: bool, outer_version: Option<&str>, trait_: Option<&clean::Trait>) -> fmt::Result { </ins> let shortty = shortty(item); let name = item.name.as_ref().unwrap();
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: _ => panic!("can't make docs for trait item with name {:?}", item.name) } <del> if !is_default_item && (!is_static || render_static) { document(w, cx, item) } else { Ok(()) </del> <ins> if !is_static || render_static { if !is_default_item { if item.doc_value().is_some() { document(w, cx, item)?; } else { // In case the item isn't documented, // provide short documentation from the trait if let Some(t) = trait_ { if let Some(it) = t.items.iter() .find(|i| i.name == item.name) { document_short(w, it, link)?; } } } } else { document_short(w, item, link)?; } </ins> } <ins> Ok(()) </ins> } <ins> let traits = &cache().traits; let trait_ = i.trait_did().and_then(|did| traits.get(&did)); </ins> write!(w, "<div class='impl-items'>")?; for trait_item in &i.inner_impl().items { <del> doctraititem(w, cx, trait_item, link, render_header, false, outer_version)?; </del> <ins> doctraititem(w, cx, trait_item, link, render_header, false, outer_version, trait_)?; </ins> } fn render_default_items(w: &mut fmt::Formatter,
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: let assoc_link = AssocItemLink::GotoSource(did, &i.provided_trait_methods); doctraititem(w, cx, trait_item, assoc_link, render_static, true, <del> outer_version)?; </del> <ins> outer_version, None)?; </ins> } Ok(()) } // If we've implemented a trait, then also emit documentation for all // default items which weren't overridden in the implementation block. <del> if let Some(did) = i.trait_did() { if let Some(t) = cache().traits.get(&did) { render_default_items(w, cx, t, &i.inner_impl(), render_header, outer_version)?; } </del> <ins> if let Some(t) = trait_ { render_default_items(w, cx, t, &i.inner_impl(), render_header, outer_version)?; </ins> } write!(w, "</div>")?; Ok(())
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: fn b_method(&self) -> usize { self.a_method() } <ins> /// Docs associated with the trait c_method definition. /// /// There is another line fn c_method(&self) -> usize { self.a_method() } </ins> } // @has manual_impl/struct.S1.html '//*[@class="trait"]' 'T' // @has  - '//*[@class="docblock"]' 'Docs associated with the S1 trait implementation.' // @has  - '//*[@class="docblock"]' 'Docs associated with the S1 trait a_method implementation.' // @!has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' <del> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' </del> <ins> // @has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' // @has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' // @has - '//*[@class="docblock"]' 'Docs associated with the trait c_method definition.' // @!has - '//*[@class="docblock"]' 'There is another line' // @has - '//*[@class="docblock"]' 'Read more' </ins> pub struct S1(usize); /// Docs associated with the S1 trait implementation.
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: // @has manual_impl/struct.S2.html '//*[@class="trait"]' 'T' // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait implementation.' // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait a_method implementation.' <del> // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait b_method implementation.' </del> <ins> // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait c_method implementation.' </ins> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' <del> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' </del> <ins> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait c_method definition.' // @has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' // @!has - '//*[@class="docblock"]' 'Read more' </ins> pub struct S2(usize); /// Docs associated with the S2 trait implementation.
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: self.0 } <del> /// Docs associated with the S2 trait b_method implementation. fn b_method(&self) -> usize { </del> <ins> /// Docs associated with the S2 trait c_method implementation. fn c_method(&self) -> usize { </ins> 5 } }
Code change:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Related discussion:
text: // @has manual_impl/struct.S3.html '//*[@class="trait"]' 'T' // @has  - '//*[@class="docblock"]' 'Docs associated with the S3 trait implementation.' // @has  - '//*[@class="docblock"]' 'Docs associated with the S3 trait b_method implementation.' <del> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' </del> <ins> // @has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' </ins> pub struct S3(usize); /// Docs associated with the S3 trait implementation.
Code change:
The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

Related discussion:
text: use super::FnCtxt; use hir::def_id::DefId; <del> use rustc::ty::{Ty, TypeFoldable, PreferMutLvalue}; </del> <ins> use rustc::ty::{Ty, TypeFoldable, PreferMutLvalue, TypeVariants}; </ins> use rustc::infer::type_variable::TypeVariableOrigin; use syntax::ast; use syntax::symbol::Symbol;
Code change:
The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

Related discussion:
text: "binary operation `{}` cannot be applied to type `{}`", op.node.as_str(), lhs_ty); <ins> if let TypeVariants::TyRef(_, ref ty_mut) = lhs_ty.sty { if !self.infcx.type_moves_by_default(ty_mut.ty, lhs_expr.span) && self.lookup_op_method(expr, ty_mut.ty, vec![rhs_ty_var], Symbol::intern(name), trait_def_id, lhs_expr).is_ok() { err.span_note( lhs_expr.span, &format!( "this is a reference of type that `{}` can be applied to,  you need to dereference this variable once for this  operation to work", op.node.as_str())); } } </ins> let missing_trait = match op.node { hir::BiAdd    => Some("std::ops::Add"), hir::BiSub    => Some("std::ops::Sub"),
Code change:
The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

Related discussion:
text: <ins> // Copyright 2012-2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let v = vec![1, 2, 3, 4, 5, 6, 7, 8, 9]; let vr = v.iter().filter(|x| { x % 2 == 0 //~^ ERROR binary operation `%` cannot be applied to type `&&{integer}` //~| NOTE this is a reference of type that `%` can be applied to //~| NOTE an implementation of `std::ops::Rem` might be missing for `&&{integer}` }); println!("{:?}", vr); } </ins>
Code change:
The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

Related discussion:
text: <ins> // Copyright 2012-2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a: &String = &"1".to_owned(); let b: &str = &"2"; let c = a + b; //~^ ERROR binary operation `+` cannot be applied to type `&std::string::String` //~| NOTE an implementation of `std::ops::Add` might be missing for `&std::string::String` println!("{:?}", c); } </ins>
Code change:
Check out in mode : This succeeds (when compiled with optimizations) despite having both a and a . is safe from this because at it believes it's mutably borrowed and panics. There's a line in which would catch this with debug assertions enabled, I believe it should be an ( is unstable and likely not performance critical anyway). cc

Related discussion:
text: // Since this Ref exists, we know the borrow flag // is not set to WRITING. let borrow = self.borrow.get(); <del> debug_assert!(borrow != WRITING && borrow != UNUSED); </del> <ins> debug_assert!(borrow != UNUSED); // Prevent the borrow counter from overflowing. assert!(borrow != WRITING); </ins> self.borrow.set(borrow + 1); BorrowRef { borrow: self.borrow } }
Code change:
. It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?

Related discussion:
text: the compiler. They are accessible via the `--explain` flag. Each explanation comes with an example of how to trigger it and advice on how to fix it. <ins> Please read [RFC 1567](https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md) for details on how to format and write long error codes. </ins> * All of them are accessible [online](http://doc.rust-lang.org/error-index.html), which are auto-generated from rustc source code in different places: [librustc](https://github.com/rust-lang/rust/blob/master/src/librustc/diagnostics.rs), <ins> [libsyntax](https://github.com/rust-lang/rust/blob/master/src/libsyntax/diagnostics.rs), </ins> [librustc_borrowck](https://github.com/rust-lang/rust/blob/master/src/librustc_borrowck/diagnostics.rs), [librustc_const_eval](https://github.com/rust-lang/rust/blob/master/src/librustc_const_eval/diagnostics.rs), <del> [librustc_lint](https://github.com/rust-lang/rust/blob/master/src/librustc_lint/types.rs), </del> [librustc_metadata](https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/diagnostics.rs), [librustc_mir](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/diagnostics.rs), [librustc_passes](https://github.com/rust-lang/rust/blob/master/src/librustc_passes/diagnostics.rs), [librustc_privacy](https://github.com/rust-lang/rust/blob/master/src/librustc_privacy/diagnostics.rs), [librustc_resolve](https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/diagnostics.rs), [librustc_trans](https://github.com/rust-lang/rust/blob/master/src/librustc_trans/diagnostics.rs), <ins> [librustc_plugin](https://github.com/rust-lang/rust/blob/master/src/librustc_plugin/diagnostics.rs), </ins> [librustc_typeck](https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/diagnostics.rs). * Explanations have full markdown support. Use it, especially to highlight code with backticks.
Code change:
. It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?

Related discussion:
text: * Flags should be orthogonal to each other. For example, if we'd have a json-emitting variant of multiple actions `foo` and `bar`, an additional --json flag is better than adding `--foo-json` and `--bar-json`. <del> * Always give options a long descriptive name, if only for better </del> <ins> * Always give options a long descriptive name, if only for more </ins> understandable compiler scripts. * The `--verbose` flag is for adding verbose information to `rustc` output when not compiling a program. For example, using it with the `--version` flag
Code change:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

Related discussion:
text: let mut base = self; let mut acc = 1; <del> let mut prev_base = self; let mut base_oflo = false; while exp > 0 { </del> <ins> while exp > 1 { </ins> if (exp & 1) == 1 { <del> if base_oflo { // ensure overflow occurs in the same manner it // would have otherwise (i.e. signal any exception // it would have otherwise). acc = acc * (prev_base * prev_base); } else { acc = acc * base; } </del> <ins> acc = acc * base; </ins> } <del> prev_base = base; let (new_base, new_base_oflo) = base.overflowing_mul(base); base = new_base; base_oflo = new_base_oflo; </del> exp /= 2; <ins> base = base * base; </ins> } <ins> // Deal with the final bit of the exponent separately, since // squaring the base afterwards is not necessary and may cause a // needless overflow. if exp == 1 { acc = acc * base; } </ins> acc }
Code change:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2i32.pow(1024); } </ins>