jiebi/CodeConvo huggingface dataset:
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(vec_remove_item)] </del> /// let mut vec = vec![1, 2, 3, 1]; /// /// vec.remove_item(&1); /// /// assert_eq!(vec, vec![2, 3, 1]); /// ``` <del> #[unstable(feature = "vec_remove_item", reason = "recently added", issue = "40062")] </del> <ins> #[stable(feature = "vec_remove_item", since = "1.42.0")] </ins> pub fn remove_item<V>(&mut self, item: &V) -> Option<T> where T: PartialEq<V>,

Related discussion:
text: <delWorse for the last index: ().rev().position( v.len() - i - 1) Contrast to the and in that famous vector called string that (ugly names but at least they convey that a search is involved). I've vary rarely needed this, I don't advocate making linear searches easy, it just seems more useful to try to make searching easier, before making search-and-removing easier.
(so does ). And even if it didn't exist, that has no relevance to whether should exist or not, they're separate features, so they can both exist, it isn't either/or. (I personally have had many cases where would have been useful, it's a common operation in any language.)
Waaait! It's getting stabilized without fixing the confusing name! Please please don't call it , as this is the same name as in other languages that can remove item from an array by presenting an item from the same array. Rust's version can't do that due to borrow checker and it's a trap for users.
I absolutely wouldn't call it a trap.
It seems like many people agree that the name should at least be up for debate again. Really unfortunate how the name discussion was somehow forgotten during FCP. So I guess we should revert stabilization as soon as possible so it won't end up in beta?
Sounds reasonable. Maybe someone wants to volunteer to lead the process about settling on a name for this ?
The next release is scheduled for Jan 30th. So we have about 3 weeks to figure out a new name.
I went through the thread again and it seems like the following names are suggestions for the method as it currently exists: (iterators have "items", Vec has "elements") - Personally, I would absolutely include , as that's an important information and . I have no preference between and . However, from reading the thread again it seems there are plenty of other concerns and suggestions that haven't been resolved yet: Adding similar methods: ? ? Replace the method with:  (although I don't understand that one. Is it just a with flipped predicate? In that case I don't think it's useful. If it just removes the first element, then absolutely needs to be in the name IMO.) Do not stabilize this method at all: ,
mentioned : also raised some more concerns , and I raised some concerns .
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(vec_remove_item)] </del> /// let mut vec = vec![1, 2, 3, 1]; /// /// vec.remove_item(&1); /// /// assert_eq!(vec, vec![2, 3, 1]); /// ``` <del> #[unstable(feature = "vec_remove_item", reason = "recently added", issue = "40062")] </del> <ins> #[stable(feature = "vec_remove_item", since = "1.42.0")] </ins> pub fn remove_item<V>(&mut self, item: &V) -> Option<T> where T: PartialEq<V>,

Related discussion:
text: I don't see where these concerns have been resolved. From re-reading this whole discussion, it isn't clear to me what the goal of adding this method is nor what problem does this method solve or whether this is a problem worth solving. What's more or less clear to me is that there is at least some design work to be done to at least ensure that libstd exposes a consistent API, and that sounds like this would warrant an RFC to me. The current discussion about using a method hints that these APIs might not only want to be consistent for the ordered collections (Vec, VecDeque, List) for which a notion of a "first" element makes sense, but might also want to be consistent with the e.g. and methods of slices. The main arguments for FCPing this appear to be that this has sit on nightly for too long without anybody complaining, and the main argument for stabilizing this has been that this has been in FCP for too long. I think it would be better to just encourage and support those that want to land this feature to write a small RFC for it. If somebody is interested in doing that, I would be able to help and give feedback.
Unless a concern is made with by a relevant team member, then it won't stop FCP. And it won't go into FCP unless the majority of team members have voted for it (and there aren't any formal concerns listed). So the fact it passed FCP means that all relevant team members that they were okay with the current design and did not have any outstanding concerns at the time. Things do not go into FCP simply because it's been "sitting around too long". Of course if any team members do have any concerns, now would be the best time to make them.
Mistakes happen. And to me this thread clearly looks like many concerns were overlooked accidentally and no one explicitly marked them as concerns for rfcbot. Luckily those mistakes were caught.
Reopening because
The current signature is missing a ?Sized bound. Could I ask for a PR to fix the bound and add a test that covers remove_item("...") on a Vec<String? This use case was requested in and
Separately: I am leaning toward removing removeitem.
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(vec_remove_item)] </del> /// let mut vec = vec![1, 2, 3, 1]; /// /// vec.remove_item(&1); /// /// assert_eq!(vec, vec![2, 3, 1]); /// ``` <del> #[unstable(feature = "vec_remove_item", reason = "recently added", issue = "40062")] </del> <ins> #[stable(feature = "vec_remove_item", since = "1.42.0")] </ins> pub fn remove_item<V>(&mut self, item: &V) -> Option<T> where T: PartialEq<V>,

Related discussion:
text: I agree with and The currently design involves: start with a reference to a value not in the vec, use its PartialEq impl to do a linear scan, remove the first found, shift everything after the removed element. To generalize almost all of the discussion above, people are questioning whether the conjunction of all 5 of these decisions is really as common as a name like removeitem would suggest, whether a different permutation of choices might be more widely applicable, and how to adjust naming to leave room for all the other equally or more common permutations: ones where the ref we want to remove is a ref to a vec element, or we want to remove by FnMut instead of PartialEq, or we want a binary search, or we want to remove the last, or all matches, or we want the more efficient swapremove behavior. Fortunately Vec already supports all permutations of these use cases equally well, with nice independent APIs for searching and removing. Many people have voiced opinions equivalent to "removing an item from a vec is so common that there absolutely must be a function for it". I think what they mean is that the union of all permutations of the above 5 choices is common, which is true; they don't necessarily mean the specific choices that go into removeitem as it exists would justify a method specific to those choices. points out that satisfying the set of use cases which all together are common would take a much larger number of new methods.
Per , I think we should go ahead and remove . fcp close
That is not what I meant. When I said that I need in my code, I meant exactly that: that I could take my existing code and replace it with and it would have exactly the same behavior, because I really do need specifically, not the other fancier methods. I'm perfectly fine with changing the name so that we can accommodate other fancier methods in the future, but why would that mean that we shouldn't have at all?
fcp cancel
proposal cancelled.
Per , I think we should go ahead and remove . fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period.
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(vec_remove_item)] </del> /// let mut vec = vec![1, 2, 3, 1]; /// /// vec.remove_item(&1); /// /// assert_eq!(vec, vec![2, 3, 1]); /// ``` <del> #[unstable(feature = "vec_remove_item", reason = "recently added", issue = "40062")] </del> <ins> #[stable(feature = "vec_remove_item", since = "1.42.0")] </ins> pub fn remove_item<V>(&mut self, item: &V) -> Option<T> where T: PartialEq<V>,

Related discussion:
text: If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Checking KodrAus’ checkbox per
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
Since we've merged the deprecation would we like to close this tracking issue now? Or keep it open until the unstable deprecated method is removed entirely?
I think keeping this open until we removed the method is a good idea. How long do we want to wait with that by the way? I guess a couple of cycles is sufficient?
Before closing, it would be great if someone could suggest a "one clean and obvious" way to remove the first/last occurance of an item from a Vector. Irrespective of the arguments made here, a method removing the first/last occurance of an item is provided across all major programming languages, and is to be "expected" Anyone new to rust is bound to google "remove from vec rust" and end up on this discussion which would only leave them more confused.
should answer those questions. But here is a copy of my answer for convenience: You can of course handle the case however you like (panic and ignoring are not the only possibilities). Like the first element, but replace with . Remember that has a runtime of O(n) as all elements after the index need to be shifted. has a runtime of O(1) as it swaps the to-be-removed element with the last one. If the order of elements is not important in your case, use instead of !
It might be worth adding more examples (maybe all of the ones above) to the docs.
I'd like to add those to the docs, should they go along the example that we currently have?
What examples are you referring to? I could imagine those "remove examples" either going on the type (as a new section "Removing elements" or something like that) or directly on the method (below the existing docs). And by the way, feel free to add (parts of) my text/examples verbatim.
Thank you.
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(vec_remove_item)] </del> /// let mut vec = vec![1, 2, 3, 1]; /// /// vec.remove_item(&1); /// /// assert_eq!(vec, vec![2, 3, 1]); /// ``` <del> #[unstable(feature = "vec_remove_item", reason = "recently added", issue = "40062")] </del> <ins> #[stable(feature = "vec_remove_item", since = "1.42.0")] </ins> pub fn remove_item<V>(&mut self, item: &V) -> Option<T> where T: PartialEq<V>,

Related discussion:
text: I was referring to those "remove examples" as to whether I should append them to what we currently have in docs for , put them somewhere else or perhaps modify examples for to include removal of specific element
That sounds fine to me. Feel free to just open a PR and we can still see about the specifics then :)
Code change:
_ => None, } } <ins> fn host_dll_subdir() -> Option<&'static str> { if cfg!(target_arch = "x86_64") { Some("amd64") } else if cfg!(target_arch = "x86") { Some("") } else { None } } </ins> } // If we're not on Windows, then there's no registry to search through and MSVC // wouldn't be able to run, so we just call `link.exe` and hope for the best. #[cfg(not(windows))] <del> pub fn link_exe_cmd(_sess: &Session) -> Command { Command::new("link.exe") </del> <ins> mod platform { use std::path::PathBuf; use std::process::Command; use session::Session; pub fn link_exe_cmd(_sess: &Session) -> Command { Command::new("link.exe") } pub fn host_dll_path() -> Option<PathBuf> { None } </ins> } <ins> pub use self::platform::*; </ins>

Related discussion:
text: On nightly (and beta I believe) the compiler will currently fail when cross compiling from x86_64 to x86 (after ensuring the standard library is in the right location) with the message: I believe this is a regression from and , which were backported, so I believe this is a stable regression. That being said I doubt anyone other than Cargo CI is doing this, so it may not be that big. I also believe that is working on a patch, but this should help track this issue.
I have been doing this with ring and ring-based projects for many months.
Code change:
let len = self.buf.len(); let mut ret = Ok(()); while written < len { <del> match self.inner.as_mut().unwrap().write(&self.buf[written..]) { </del> <ins> self.panicked = true; let r = self.inner.as_mut().unwrap().write(&self.buf[written..]); self.panicked = false; match r { </ins> Ok(0) => { ret = Err(Error::new(ErrorKind::WriteZero, "failed to write the buffered data"));

Related discussion:
text: There is a panic safety issue in : after a call panics, the impl of calls again, which means the buffer contents are potentially written twice. This may cause an application to overwrite parts of a file that it did not mean to overwrite (in a DB engine written in Rust, this could cause unrecoverable data corruption!). Demonstration: The expected output of the demo program is , the actual output is: More generally, we need a story for panic safety in Rust. My takeaway from the related discussions (e.g. , , the trait) was that only code and impls should have to worry about panic safety. The demo app contains none of these, so I'd consider this a bug in . (otherwise all implementations would need to provide the strong exception safety guarantee?) Solution: could use temporarily mark the buffer as empty during the calls; so that the impl doesn't do anything after a panic. However, this doesn't help if the panic occurs during a call...
Note that Rust is normally referring to "memory safety" when talking about safety, so the issue here isn't in conflict with the related discussions. It's definitely a bug in , but I want to point out how specific it is here: the only reason you have odd behaviour is because you have a implementation that will panic after successfully writing the data it is given. I'm all for making more robust, but it's not just "if the call panics", it's "if the call panics after successfully writing data". Panicking before a successful write (or if the write fails), would not have the same issue.
If your impl is panicking in the middle of a write, it seems to me like you're in data corruption land with or without a second write. This is not quite the case - and thread locals expand that surface area. What's specifically the expected behavior here? Is the implementation specifically the thing that needs tweaking, or should the totally poison itself? For reference, Java's class has no special handling for exceptions thrown from the inner : , so adjusting alone seems like a reasonable route to take.
Without the , a panic in the middle of a write (without ) only corrupts the part of the file that the application meant to overwrite. In a DB engine context, that means the resulting corruption can be repaired when the transaction is rolled back.
Code change:
let len = self.buf.len(); let mut ret = Ok(()); while written < len { <del> match self.inner.as_mut().unwrap().write(&self.buf[written..]) { </del> <ins> self.panicked = true; let r = self.inner.as_mut().unwrap().write(&self.buf[written..]); self.panicked = false; match r { </ins> Ok(0) => { ret = Err(Error::new(ErrorKind::WriteZero, "failed to write the buffered data"));

Related discussion:
text: But with , a panic after some data was written might corrupt parts of the file that are not saved in the rollback journal, so recovery not possible. I think we need some guideline like: If a method call panics, it's a bug to call any additional methods on the same object. Thus, the bug is in . may need something similar to a poison-flag so that the impl can detect whether a previous call panicked, but it doesn't need to protect against it's own methods being called after a panic (that would be considered a bug in the caller). The Java has the same problem, but the expectation in the Java world is different: it's trivially possible to catch an exception and continue using the potentially-invalid state; so in Java's case I would argue that all implementations should provide the strong exception safety guarantee to avoid this kind of issue. Essentially, the Rust world needs to decide between a Java/C++-style "strong exception safety guarantee" (=failing method call should not have any side effects) or a new "no-use-after-panic guarantee" (=after a failing method call, no additional method calls should occur). Some types (like BufWriter) can be compatible with at most one of the guarantees -- strong exception safety requires that a panicking call has no side effects; no-use-after-panic requires that a panicking call has the side effect of suppressing the buffer flush in the impl. The trait seems to be roughly equivalent to basic exception safety. Types that do not implement instead live in the world. Generic types implementing need to be careful not to call any functions on the type parameter from within the implementation if a previous call panicked (unless they use a bound).
triage: P-medium is fixing the data corruption in
Code change:
}, value_ns: match self.resolve( path_str, <ins> disambiguator, </ins> ValueNS, &current_item, base_node,

Related discussion:
text: I tried to document this code: I expected to see this happen: charstd::char` points to module page of char type points to char primitive page Instead, this happened: type points to module page of char :
I think the problem is that modules are in the type namespace, so is doing exactly what you are asking it for (the module, since it has higher priority). Since the built-in types scope is the lowest precedence, perhaps there needs to be a way to access it directly? Maybe something like or ? Or maybe should skip over modules, and keep looking deeper in the scope hierarchy? (cc )
Oh hmm I see what you mean. There are : Types, values, and macros. Since modules and types are in the same namespace, it uses the first one it finds. Maybe we could work around this by first resolving in an empty module (so it has nothing in scope), then only falling back to the current scope if we don't find something there?
I'm surprised this hasn't caused trouble before now. Does the root of never use the primitive?
I don't know how it works, but the resolver is smart enough to know that in a type context won't match a module (like , the won't match a module named "char". Maybe it has something to do with late-resolution  which has a to give it some context?
Adding that would be more of area ... I can give it a shot though.
It looks like doesn't even return a resolution and only records it for later use ... I'm going to go with the empty module workaround and we can fix it later if it turns out to cause issues.
The double resolve seems hacky. We could probably make type@ specifically not resolve to a module, perhaps? Also, note that modules are in all namespaces
How would that work? We could skip any module resolutions, but since modules have precedence over types I don't know how we'd get the primitive type to resolve afterwards.
Oh hold on we have a function already. We can look at directly.
This doesn't have anything to do with primitives, this has to do with glob imports vs non-glob imports. You can get the same issue with the following:
This also doesn't have to do with modules being "resolved first" or anything. Things that are non-glob in-scope are resolved first.
Code change:
}, value_ns: match self.resolve( path_str, <ins> disambiguator, </ins> ValueNS, &current_item, base_node,

Related discussion:
text: Actually, my bad: This does have to do with primitives in the sense that primitives are the only thing that still work when shadowed because of some special code in checking the primitive tables. I think when the string matches one of the primitive table entries for TypeNS lookups that were explicitly annotated with type@ and resolve to a module we can hack this in. In the future we might want to tighten up this code so that e.g. can't resolve to an enum, etc.
do you mind if I fix at the same time and resolve primitives even before modules? That seems like the less surprising behavior to me, the module can still be disambiguated with .
I'm a bit wary of doing this because having the char module in scope is not a common situation, and it will get weirder for people who have a different char module. I think we should resolve to whatever is in scope, but if is explicitly mentioned we can then force resolve to the primitive.
Code change:
<ins> // Copyright 2017 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. // Tests the rustdoc --sort-modules-by-appearance option, that allows module declarations to appear // in the order they are declared in the source code, rather than only alphabetically. // compile-flags: -Z unstable-options --sort-modules-by-appearance pub mod module_b {} pub mod module_c {} pub mod module_a {} // @matches 'sort_modules_by_appearance/index.html' '(?s)module_b.*module_c.*module_a' // @matches 'sort_modules_by_appearance/sidebar-items.js' '"module_b".*"module_c".*"module_a"' </ins>

Related discussion:
text: Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.