jiebi/CodeConvo huggingface dataset:
Code change:
fn eof_err(&mut self) -> PErr<'psess> { let msg = "this file contains an unclosed delimiter"; let mut err = self.string_reader.dcx().struct_span_err(self.token.span, msg); <del> for &(_, sp) in &self.diag_info.open_braces { err.span_label(sp, "unclosed delimiter"); </del> <ins> let unclosed_delimiter_show_limit = 5; let len = usize::min(unclosed_delimiter_show_limit, self.diag_info.open_braces.len()); for &(_, span) in &self.diag_info.open_braces[..len] { err.span_label(span, "unclosed delimiter"); </ins> self.diag_info.unmatched_delims.push(UnmatchedDelim { found_delim: None, found_span: self.token.span, <del> unclosed_span: Some(sp), </del> <ins> unclosed_span: Some(span), </ins> candidate_span: None, }); } <ins> if let Some((_, span)) = self.diag_info.open_braces.get(unclosed_delimiter_show_limit) && self.diag_info.open_braces.len() >= unclosed_delimiter_show_limit + 2 { err.span_label( *span, format!( "another {} unclosed delimiters begin from here", self.diag_info.open_braces.len() - unclosed_delimiter_show_limit ), ); } </ins> if let Some((delim, _)) = self.diag_info.open_braces.last() { report_suspicious_mismatch_block( &mut err,

Related discussion:
text: In my Fedora installation ended up being a corrupted file. It took me hours to realize, given that the output does not bring any clarity to it. rustc should really have ratelimit detection or something to detect corrupted file instead and inform about this to the user. !
This indeed seems quite confusing; and counter-productive to try to show this blob of errors. Would you be able to provide us with a reproducible example of the issue? Or if you still have it the corrupted file. labels +T-compiler +A-diagnostics +D-verbose +D-confusing +S-needs-repro -needs-triage
So this a problem because I unfortunately deleted the trashed file before someone told me that I should report this as a bug. I regret that I did not store it :-/ BUT I recalled that it was probably for reason a long string of ANSI escape codes. So I did a test string: This creates somewhat similar output as I got, except probably the string was a bit longer in my case.
OK doubling that starts to be almost perfect match:
! ... I'm considering T-shirt design ;-) Made by me and rustc. EDIT: and rendered by excellent terminal emulator foot
Somehow rustc should be able to detect corrupted file in cargo's source repository (or whatever it is called). It was pretty bizarre sight when I encountered this by accident.
Thanks for the repro. label -S-needs-repro
Yeah I mean it is really a huge corner case but it can happen in the case of data corruption (e.g. power outage in middle of write operation). I'd detect frequency of errors and maybe a threshold parameter when it is interpreted as corruption with a sane default value.
yeah, I believe this error comes out from the phase of lexing, which rustc are trying to find all the mismatched delimiters, maybe a threshold is ok for resolve it.
Code change:
<ins> 1|       |// Verify that the entry point injected by the test harness doesn't cause 2|       |// weird artifacts in the coverage report (e.g. issue #10749). 3|       | 4|       |// compile-flags: --test 5|       | 6|       |#[allow(dead_code)] 7|      0|fn unused() {} 8|       | 9|      1|#[test] 10|      1|fn my_test() {} </ins>

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. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- 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. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!-- <details<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected .
Code change:
<ins> 1|       |// Verify that the entry point injected by the test harness doesn't cause 2|       |// weird artifacts in the coverage report (e.g. issue #10749). 3|       | 4|       |// compile-flags: --test 5|       | 6|       |#[allow(dead_code)] 7|      0|fn unused() {} 8|       | 9|      1|#[test] 10|      1|fn my_test() {} </ins>

Related discussion:
text: However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.
Code change:
sym::coverage => self.check_coverage(hir_id, attr, span, target), sym::non_exhaustive => self.check_non_exhaustive(hir_id, attr, span, target), sym::marker => self.check_marker(hir_id, attr, span, target), <del> sym::target_feature => self.check_target_feature(hir_id, attr, span, target), </del> <ins> sym::target_feature => self.check_target_feature(hir_id, attr, span, target, attrs), </ins> sym::thread_local => self.check_thread_local(attr, span, target), sym::track_caller => { self.check_track_caller(hir_id, attr.span, attrs, span, target)

Related discussion:
text: This works (but it shouldn't): similar to , cc (tracking issue) label T-lang T-compiler C-bug I-unsound F-targetfeature11
cc , author of Note that this is about the nostd panic handler, not about the function. This fails as it should: gives
ugh we really need a way to make sure that every single "this is called by rust" function gets a check... I assume that these functions can't be unsafe, so I guess those checks are a food way to start looking and make sure to deduplicate the logic there?
Yeah sadly we do need to make sure, not just for the constructs that we have now but also it needs to be kept in mind for the future constructs we add or stabilize. A lot thankfully goes through either the trait system (operators or the GlobalAlloc trait used by ) or function pointers (alloc error hook, std panic hook). Functions that you can make callable solely by setting an attribute, those are rare. The best list of lang items I could find was in the , so that would be a great start for such an exhaustive search. Thankfully most of them are unstable, but still it needs to be addressed for each of them before stabilization (if that is a target).
WG-prioritization assigning priority (). label -I-prioritize +P-medium
label +requires-nightly
There is also another table of lang items in the source code, .
Code change:
}; } ast::UnNot => { <del> oprnd_t = structurally_resolved_type(fcx, oprnd.span, oprnd_t); if !(ty::type_is_integral(oprnd_t) || ty::get(oprnd_t).sty == ty::ty_bool) { oprnd_t = check_user_unop(fcx, "!", "not", tcx.lang_items.not_trait(), expr, &**oprnd, oprnd_t); </del> <ins> if !ty::type_is_bot(oprnd_t) { oprnd_t = structurally_resolved_type(fcx, oprnd.span, oprnd_t); if !(ty::type_is_integral(oprnd_t) || ty::get(oprnd_t).sty == ty::ty_bool) { oprnd_t = check_user_unop(fcx, "!", "not", tcx.lang_items.not_trait(), expr, &**oprnd, oprnd_t); } </ins> } } ast::UnNeg => { <del> oprnd_t = structurally_resolved_type(fcx, oprnd.span, oprnd_t); if !(ty::type_is_integral(oprnd_t) || ty::type_is_fp(oprnd_t)) { oprnd_t = check_user_unop(fcx, "-", "neg", tcx.lang_items.neg_trait(), expr, &**oprnd, oprnd_t); </del> <ins> if !ty::type_is_bot(oprnd_t) { oprnd_t = structurally_resolved_type(fcx, oprnd.span, oprnd_t); if !(ty::type_is_integral(oprnd_t) || ty::type_is_fp(oprnd_t)) { oprnd_t = check_user_unop(fcx, "-", "neg", tcx.lang_items.neg_trait(), expr, &**oprnd, oprnd_t); } </ins> } } }

Related discussion:
text: Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.
Code change:
#[unsafe_destructor] //~^ ERROR `#[unsafe_destructor]` does nothing anymore <del> //~| HELP: add #![feature(unsafe_destructor)] to the crate attributes to enable // (but of couse there is no point in doing so) </del> impl<'a> Drop for D<'a> { fn drop(&mut self) { } }

Related discussion:
text: Steps to reproduce: The output of is: does as suggested by the message, but that fails too (as expected): Proposed fix: in the beta and stable channels (i.e. whenever is forbidden), the message that suggests adding should not be shown. (Clean up the test case with .) CC
Gonna milestone this real quick, as it seems quite important.
I might be able to whip up a quick fix, though I'm not 100% sure about testing it properly ... (I've never actually tried building something for a non-dev release channel before...)
after chatting with it seems like I have a patch, building it now
gonna leave to it
Hello good Rust folks :smile: Before the beta, I used which is in . Is there any way to use this trait during the beta ? I'm not sure how I can get the code to compile. Thanks for any tip / hints you can offer :+1:
Hi Commenting on random unrelated issues is usually not the right thing to do. You should rather open a new issue, or ask on . But to answer your question anyway, that trait only has : … and is stable and can be used on beta. So I’d recommend you copy/paste the trait into your code, or make a function.
Thanks for taking the time to answer. I appreciate it. I don't see how this is unrelated. This is related, since the code I'm talking about used to compile with and the compiler suggests to do that, during the beta period. Thanks for your tip on copying the function :+1: I guess I'll just do that if nothing better is available and change this again when the trait is stable.
This specific issue is about fixing one of the compiler’s error message, not about fixing code that triggers that error. It really helps everyone to keep discussions on topic.
Alright. I understand. I'll make sure to open a new issue or go on StackOverflow next time if appropriate. Thanks again :+1:
This doesn't seem to be properly fixed in the beta channel. I'm still being recommended to add in the errors, and then told it's not available in the beta channel. Rust version: The code I used (snappy example in the docs with the extra addition on the first line:
This happened after Beta release.
Code change:
#[unsafe_destructor] //~^ ERROR `#[unsafe_destructor]` does nothing anymore <del> //~| HELP: add #![feature(unsafe_destructor)] to the crate attributes to enable // (but of couse there is no point in doing so) </del> impl<'a> Drop for D<'a> { fn drop(&mut self) { } }

Related discussion:
text: We'll see the effect of this patch in 1.0 and afterwards Beta, etc.
Whoops, I thought this made it in before beta. Thanks!
are there plans to release updates to the beta channel within a given 6 weeks cycle? Either this one or in the future.
I'm certain there will be updates; see discussion from last night here:
So how does one fix this error? I'm a new user of the rust library and I can't seem to use the collections library during the beta due to this problem. Given this git issue is a top google result, it would be nice if there were a solution here. Edit: Looks like the solution is to switch to the rust nightly. Is the entire collections library off-limits in the beta?
by design, you have access to the parts of that are re-exported from (and are stable).
Code change:
<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. #![feature(reflect_marker)] use std::any::TypeId; use std::marker::Reflect; use std::rc::Rc; type Fp<T> = Rc<T>; struct Engine; trait Component: 'static + Reflect {} impl Component for Engine {} trait Env { fn get_component_type_id(&self, type_id: TypeId) -> Option<Fp<Component>>; } impl<'a> Env+'a { fn get_component<T: Component>(&self) -> Option<Fp<T>> { let x = self.get_component_type_id(TypeId::of::<T>()); None } } trait Figment { fn init(&mut self, env: &Env); } struct MyFigment; impl Figment for MyFigment { fn init(&mut self, env: &Env) { let engine = env.get_component::<Engine>(); } } fn main() {} </ins>

Related discussion:
text: Error: Reproduces with:
cc
I just now noticed that does not actually yet allow unsized . Might be related.
This doesn't compile, but it doesn't ICE.
It looks like no longer exists. Did it get replaced by something else? I imagine there's not much value in adding a regression test with a broken import
from
Code change:
<ins> // issue-52240: Can turn immutable into mut with `ref mut` enum Foo { Bar(i32), } fn main() { let arr = vec!(Foo::Bar(0)); if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { //~^ ERROR cannot borrow field of immutable binding as mutable *val = 9001; } match arr[0] { Foo::Bar(ref s) => println!("{}", s) } } </ins>

Related discussion:
text: I expected just a compiler error . Compiler panicked: Meta
This is fixed in the beta version (1.30).
Code change:
<ins> // issue-52240: Can turn immutable into mut with `ref mut` enum Foo { Bar(i32), } fn main() { let arr = vec!(Foo::Bar(0)); if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { //~^ ERROR cannot borrow field of immutable binding as mutable *val = 9001; } match arr[0] { Foo::Bar(ref s) => println!("{}", s) } } </ins>

Related discussion:
text: This lets you get a mutable reference to an immutable value under a specific case. Code: From what I can tell, the tuple and at least two depths of Enums are necessary, along with an on the right side. There's probably other variations, but that seems to work well enough. Expected output would be a compile error, instead output is This works on both stable and nightly
would fix this as well?
Fixed by . Off: I wonder why we can't ship nll yet. It would solve so many issues right now, because of the match ergonomics sigh Match ergonomics produces roughly 10% of all errors/unsoundness/ICEs atm (at least it feels like this)
Yes correctly fixed this issue.
Code change:
#![feature(nll)] #![feature(set_stdio)] #![feature(test)] <del> #![feature(vec_remove_item)] </del> #![feature(ptr_offset_from)] #![feature(crate_visibility_modifier)] #![feature(const_fn)]

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:
#![feature(nll)] #![feature(set_stdio)] #![feature(test)] <del> #![feature(vec_remove_item)] </del> #![feature(ptr_offset_from)] #![feature(crate_visibility_modifier)] #![feature(const_fn)]

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:
#![feature(nll)] #![feature(set_stdio)] #![feature(test)] <del> #![feature(vec_remove_item)] </del> #![feature(ptr_offset_from)] #![feature(crate_visibility_modifier)] #![feature(const_fn)]

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).