jiebi/CodeConvo huggingface dataset:
Code change:
let x = self.parse_seq_to_before_end( &token::Gt, SeqSep::trailing_allowed(token::Comma), <del> |p| p.parse_generic_arg(None), </del> <ins> |p| match p.parse_generic_arg(None)? { Some(arg) => Ok(arg), // If we didn't eat a generic arg, then we should error. None => p.unexpected_any(), }, </ins> ); match x { Ok((_, _, Recovered::No)) => {

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: on stable 1.78.0, this checks in 0.02 seconds. on beta 1.79.0-beta.3, this hangs somewhere in , I killed it after 5 minutes of no progress.
cc
Sharing the stack would be useful
:thinking: that doesn't really seem to be it
You need to switch to like thread 2 or 3 if you're doing this in gdb
it's not particularly deep, but it looks downstream of so I guess this must be it
Minimal:
Code change:
let mut diag = cx.tcx.struct_span_lint_hir( lint::builtin::PRIVATE_DOC_TESTS, hir_id, <del> span_of_attrs(&item.attrs), </del> <ins> span_of_attrs(&item.attrs).unwrap_or(item.source.span()), </ins> "Documentation test in private item"); diag.emit(); } } /// Returns a span encompassing all the given attributes. <del> crate fn span_of_attrs(attrs: &clean::Attributes) -> Span { </del> <ins> crate fn span_of_attrs(attrs: &clean::Attributes) -> Option<Span> { </ins> if attrs.doc_strings.is_empty() { <del> return DUMMY_SP; </del> <ins> return None; </ins> } let start = attrs.doc_strings[0].span(); <ins> if start == DUMMY_SP { return None; } </ins> let end = attrs.doc_strings.last().expect("No doc strings provided").span(); <del> start.to(end) </del> <ins> Some(start.to(end)) </ins> } /// Attempts to match a range of bytes from parsed markdown to a `Span` in the source code.

Related discussion:
text: crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.
Code change:
.collect(), _ => Vec::new(), }; <del> candidates.retain(|candidate| *candidate != self.tcx.parent(result.callee.def_id)); </del> return Err(IllegalSizedBound(candidates, needs_mut, span)); }

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.
Code change:
.collect(), _ => Vec::new(), }; <del> candidates.retain(|candidate| *candidate != self.tcx.parent(result.callee.def_id)); </del> return Err(IllegalSizedBound(candidates, needs_mut, span)); }

Related discussion:
text: (cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.
Code change:
"ban_nonexisting_field: field={:?}, base={:?}, expr={:?}, expr_ty={:?}", field, base, expr, expr_t ); <del> let mut err = self.no_such_field_err(field.span, field, expr_t); </del> <ins> let mut err = self.no_such_field_err(field, expr_t); </ins> match *expr_t.peel_refs().kind() { ty::Array(_, len) => {

Related discussion:
text: I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
Thank you.
Code change:
<ins> error: expected one of `extern` or `fn`, found `WhereIsFerris` --> $DIR/issue-68062-const-extern-fns-dont-need-fn-specifier-2.rs:5:18 | LL |     const unsafe WhereIsFerris Now() {} |                  ^^^^^^^^^^^^^ expected one of `extern` or `fn` error: aborting due to previous error </ins>

Related discussion:
text: The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in
Code change:
// the MIR body will be constructed well. let coroutine_ty = body.local_decls[ty::CAPTURE_STRUCT_LOCAL].ty; <del> let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!("{body:#?}") }; </del> <ins> let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!("tried to create by-move body of non-coroutine receiver"); }; </ins> let args = args.as_coroutine(); let coroutine_kind = args.kind_ty().to_opt_closure_kind().unwrap();

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [coroutinebymovebodydefid] looking up the coroutine by-move body for [analysis] running analysis passes on this crate -- label +F-asyncclosure
As a step of reducing your code examples, could you please ensure that is necessary to reproduce this ICE before mentioning it in the issue? This ICE reproduces on edition 2021, which is the current stable edition.
My project fails on nightly also while using edition 2021.
Yep, a fix is already up and it's waiting for approval. I recommend downgrading to a slightly older nightly until this is fixed.
Code change:
use rustc_infer::infer::{self, InferOk}; use rustc_middle::traits::ObligationCause; use rustc_middle::ty::subst::{InternalSubsts, SubstsRef}; <del> use rustc_middle::ty::{self, DefIdTree, GenericParamDefKind, Ty, TypeVisitable}; </del> <ins> use rustc_middle::ty::{self, GenericParamDefKind, Ty, TypeVisitable}; </ins> use rustc_span::symbol::Ident; use rustc_span::Span; use rustc_trait_selection::traits;

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.
Code change:
use rustc_infer::infer::{self, InferOk}; use rustc_middle::traits::ObligationCause; use rustc_middle::ty::subst::{InternalSubsts, SubstsRef}; <del> use rustc_middle::ty::{self, DefIdTree, GenericParamDefKind, Ty, TypeVisitable}; </del> <ins> use rustc_middle::ty::{self, GenericParamDefKind, Ty, TypeVisitable}; </ins> use rustc_span::symbol::Ident; use rustc_span::Span; use rustc_trait_selection::traits;

Related discussion:
text: (cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.
Code change:
return None; }; <del> if new_ty.references_error() { return None; } </del> self.state.steps.push((self.state.cur_ty, kind)); debug!( "autoderef stage #{:?} is {:?} from {:?}",

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc
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: Implemented in rust impl<T: PartialEqVec<T{ pub fn remove_item(&mut self, item: &T) -Option<T{ /…/ } }
PR moved to due to reasons
Comments from original thread: think that we should add this method to too. desired?
for you can simply do
I meant specifically a method that searches for the item from the end of the vec instead of the beginning
What do you think about adding ? Just as reduces the runtime complexity from O(n) to O(1) compared to , would reduce it from O(n + (n-m)) to O(n).
I like .
It would be nice if this was more generic. let v: Vec<String= Vec::new(); v.removeitem("s"); <-- fails because &str is not a &String we really want the removeitem "item: &T" to be "something that we can compare equality with the type in the container". This would let remove_item() walk the T items, compare equality, and remove if equal.
Seems reasonable to change the signature to
Reviewing the naming used in method names and the docs, it would seem that iterators yield items while vecs contain elements. Considering that we then we should also remove elements and the method should be called . That name is a bit long so I'd propose simply . However I wonder if we should favor a more general , or have both.
Any plan to stabilize this?
This has been in nightly for a year with no issue reported on the method itself. There are proposals for additional methods, but that shouldn’t block this one. Please submit separate PRs or RFCs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [x] Concerns: resolved by Once a majority of reviewers approve (and none object), this will enter its final comment period. 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.
Are we switching to a bound?
Oops, sorry I missed that. Yes, let’s.
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: Again here, as a maintainer of collections that offer the Vec and VecDeque APIs I'd like at least a summary comment explaining what this method does, why this design was followed, alternatives, and addressing the issues mentioned here that have received zero replies: should this method be to ? : naming issue: why s instead of elements? why instead of , etc.
concern rationale-and-vecdeque Just gonna formally register concern above
Not an issue with the method per se, but it may need to be very clearly documented that the reference is not supposed to be to an item that is in the already, as it creates impossible borrow-checker conundrum. Users coming from the C world of pointers but no proper equality comparison, may be confused by this method, e.g. The name mentioned previously would help.
as the proposer for FCP, do you have thoughts on concern?
My thinking is that the suggested by would sidestep most of the issues here.
cc re.
I don’t have a strong desire for this particular feature myself, I proposed FCP as an effort to reduce the number of features in "unstable limbo". That said: Regarding , sure, I don’t see a reason not to add it there as well. as proposed in sounds good to me. It is more general, and goes with precedent of also taking a boolean callable predicate rather than relying on . (Even further, the precedent of not having a method like that would rely on .)
I notice two things: are a lot of methods similar to this we could add, and its not obvious to me which set of those methods is the ideal set. has sat in FCP concern limbo for 8 months without anyone complaining. I think we should not stabilize this just because it exists, but instead someone should come up with a well justified explanation of exactly what the best "find and remove" set of methods of vec-likes would be.
Good points. (which is stable) and also fit the "find and remove" description, and we had a similar concern about the combinations of filtering v.s. non-filtering and self-exhausting on drop () v.s. not.
resolve rationale-and-vecdeque I don't want to personally be on the hook for blocking this any more
:bell: This is now entering its final comment period, as per the .
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: :bell:
The final comment period, with a disposition to merge, 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. The RFC will be merged soon.
I still think this should be called instead of .
My problem with that name is that it only removes the first matching item, not all that are (though I haven't read the relevant RFC to know whether the name has been hashed out already; I assume it has been).
I don't think the naming issue has been resolved. The implementation is still using the name. then?
Can someone clarify what the status of this is wrt. the conversation above?
An example: I'm writing a proc macro attribute, and amongst the tokens, I expect other attribute to be there. This would be useful to add:
Until we sort this out, you can use
Ping. What's the status of this? Could we stabilize something?
? Given we already have drainfilter for accepting a predicate, it would be nice to have a method that removed a single object from the vector (if there). Removing something from a vec is exceedingly common code. Getting the position and then removing that position is longwinded for such a common operation. (Btw, I think bit of naming is excellent as it highlights that there may be others still in the vec - a method name that prompts one to think is a good thing.)
I use for this, and haven't found it too cumbersome. It differs in that it removes all copies of a given item, but is very easy for many purposes.
Retain everything but the object? As work-arounds go that's shorter, but it's not ideal for expressing intent. Still keen on and .
Just to bring up a different opinion: how about removing this method instead of stabilizing it? While yes, it would be convenient to have, it might not be worth it. For one, is not a good name, as many already said. The name doesn't imply that the first item from the start is removed. is better in that regard, but still doesn't feel completely right. More importantly, if we have , we should certainly also have . Having one but not the other feels arbitrary to me and makes for a surprising API (that's bad).
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: Similarly, we would also want to add the variant of both of those methods. Potentially, we also want to add a variant that removes all items equal to the given . And as also already mentioned, we can also add all those methods to . And why not (without the versions)? Consequently, we would have to add 10 or 15 new methods. Adding fewer would make the API inconsistent IMO. All the functionality can be implemented with very little extra code with iterators.
How do you propose this be implemented with iterators? How about this signature: This uses to make it clear exactly what is removed. The argument and the return type makes it clear that we remove many items. The user has the option of how many to remove ( means all). The returned iterator can be implemented efficiently by shifting the items and then pulling a similar trick (using ) to to yield the removed items.
already mentioned this : I think that one is too complex. Especially when considering the call site, I think it's fairly hard to understand. And the name still does not imply that the search begins at the beginning, which is a big nono for me.
Removing an item from a vec is a very common codepath. Somehow it needs to be a one liner. Having swapremovefirst() and not having removefirst() would be nudging people in the direction of great performance. That seems quite rustic to me. swapremovelast is interesting as there maybe no swap needed if it happens to be the last item - cute. Just have those two functions. That’s the 80% case covered. People who wish to maintain order will just have to have slightly more code. On Fri, 15 Nov 2019 at 19:20, Lukas Kalbertodt <:
I don't understand the focus on removing here. Vec has a lot more members taking an index than and , and only a few to get hold of an index value ( variants and , sort of). Most of the complication in the "workaround" for this remove_item is finding the first index of something: v.iter().position( n == 2) Not too bad, the reminds you it's a linear search, but could be easier.