jiebi/CodeConvo huggingface dataset:
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: /// /// [book]: ../../book/borrow-and-asref.html /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// </ins> /// # Examples /// /// Both `String` and `&str` implement `AsRef<str>`:
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: /// let s = "hello".to_string(); /// is_hello(s); /// ``` <ins> /// /// # Generic Impls /// /// - `AsRef` auto-dereference if the inner type is a reference or a mutable /// reference (eg: `foo.as_ref()` will work the same if `foo` has type `&mut Foo` or `&&mut Foo`) /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsRef<T: ?Sized> { /// Performs the conversion.
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: } /// A cheap, mutable reference-to-mutable reference conversion. <ins> /// /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// /// # Generic Impls /// /// - `AsMut` auto-dereference if the inner type is a reference or a mutable /// reference (eg: `foo.as_ref()` will work the same if `foo` has type `&mut Foo` or `&&mut Foo`) /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsMut<T: ?Sized> { /// Performs the conversion.
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: /// A conversion that consumes `self`, which may or may not be expensive. /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// /// Library writer should not implement directly this trait, but should prefer the implementation /// of the `From` trait, which offer greater flexibility and provide the equivalent `Into` /// implementation for free, thanks to a blanket implementation in the standard library. /// </ins> /// # Examples /// /// `String` implements `Into<Vec<u8>>`:
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: /// let s = "hello".to_string(); /// is_hello(s); /// ``` <ins> /// /// # Generic Impls /// /// - `From<T> for U` implies `Into<U> for T` /// - `into()` is reflexive, which means that `Into<T> for T` is implemented /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Into<T>: Sized { /// Performs the conversion.
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: /// Construct `Self` via a conversion. /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// </ins> /// # Examples /// /// `String` implements `From<&str>`:
Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: /// /// assert_eq!(string, other_string); /// ``` <ins> /// # Generic impls /// /// - `From<T> for U` implies `Into<U> for T` /// - `from()` is reflexive, which means that `From<T> for T` is implemented /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait From<T>: Sized { /// Performs the conversion.
Code change:
We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Related discussion:
text: } } <ins> pub fn get_static_val<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, did: DefId, ty: Ty<'tcx>) -> ValueRef { if let Some(node_id) = ccx.tcx().map.as_local_node_id(did) { base::get_item_val(ccx, node_id) } else { base::get_extern_const(ccx, did, ty) } } </ins>
Code change:
We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Related discussion:
text: use middle::def_id::DefId; use trans::{adt, closure, debuginfo, expr, inline, machine}; use trans::base::{self, push_ctxt}; <ins> use trans::common::{self, type_is_sized, ExprOrMethodCall, node_id_substs, C_nil, const_get_elt}; </ins> use trans::common::{CrateContext, C_integral, C_floating, C_bool, C_str_slice, C_bytes, val_ty}; <del> use trans::common::{type_is_sized, ExprOrMethodCall, node_id_substs, C_nil, const_get_elt}; </del> use trans::common::{C_struct, C_undef, const_to_opt_int, const_to_opt_uint, VariantInfo, C_uint}; use trans::common::{type_is_fat_ptr, Field, C_vector, C_array, C_null, ExprId, MethodCallKey}; use trans::declare;
Code change:
We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Related discussion:
text: } let opt_def = cx.tcx().def_map.borrow().get(&cur.id).map(|d| d.full_def()); if let Some(def::DefStatic(def_id, _)) = opt_def { <del> get_static_val(cx, def_id, ety) </del> <ins> common::get_static_val(cx, def_id, ety) </ins> } else { // If this isn't the address of a static, then keep going through // normal constant evaluation.
Code change:
We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Related discussion:
text: Ok(g) } } <del> fn get_static_val<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, did: DefId, ty: Ty<'tcx>) -> ValueRef { if let Some(node_id) = ccx.tcx().map.as_local_node_id(did) { base::get_item_val(ccx, node_id) } else { base::trans_external_path(ccx, did, ty) } } </del>
Code change:
We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.

Related discussion:
text: DatumBlock::new(bcx, datum.to_expr_datum()) } def::DefStatic(did, _) => { <del> // There are two things that may happen here: //  1) If the static item is defined in this crate, it will be //     translated using `get_item_val`, and we return a pointer to //     the result. //  2) If the static item is defined in another crate then we add //     (or reuse) a declaration of an external global, and return a //     pointer to that. </del> let const_ty = expr_ty(bcx, ref_expr); <del> // For external constants, we don't inline. let val = if let Some(node_id) = bcx.tcx().map.as_local_node_id(did) { // Case 1. // The LLVM global has the type of its initializer, // which may not be equal to the enum's type for // non-C-like enums. let val = base::get_item_val(bcx.ccx(), node_id); let pty = type_of::type_of(bcx.ccx(), const_ty).ptr_to(); PointerCast(bcx, val, pty) } else { // Case 2. base::get_extern_const(bcx.ccx(), did, const_ty) }; </del> <ins> let val = get_static_val(bcx.ccx(), did, const_ty); </ins> let lval = Lvalue::new("expr::trans_def"); DatumBlock::new(bcx, Datum::new(val, const_ty, LvalueExpr(lval))) }