jiebi/CodeConvo huggingface dataset:
Code change:
issued_borrow.borrowed_place, &issued_spans, ); <ins> self.explain_iterator_advancement_in_for_loop_if_applicable( &mut err, span, &issued_spans, ); </ins> err }

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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: or similar. The note and/or help are both subject to changes, this is just a basic idea. We could also conceivably rewrite the error message to expand on what the note says, like so: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It's hard to get 'c' in line 3 during the context where the compiler errors out the second mutable borrow message, because the mutable borrow happens between
I don't think it's critical to mention in the diagnostic. We shouldn't let the difficulty of doing that stop us from trying to improve the message. label +D-newcomer-roadblock
I'd love to try to fix this, but sadly I'm not familiar with the internals of rustc. If someone could point me towards the section where this error is, I could give it a try.
Hi ! Whenever I try to dive into fixing a problem with rustc, I usually start with a search through the codebase. In this case, I'd search for strings that come from the error message: , , or : <img width="528" alt="image" src="https://user-"And that leads me to here: So then I'd use rust-analyzer to try to find all the usages of that method.
Code change:
issued_borrow.borrowed_place, &issued_spans, ); <ins> self.explain_iterator_advancement_in_for_loop_if_applicable( &mut err, span, &issued_spans, ); </ins> err }

Related discussion:
text: In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.
Code change:
<ins> // This test certify that we can mix attribute macros from Rust and external proc-macros. // For instance, `#[derive(Default)]` uses `#[default]` and `#[derive(SmartPointer)]` uses // `#[pointee]`. // The scoping rule should allow the use of the said two attributes when external proc-macros // are in scope. //@ check-pass //@ aux-build: another-proc-macro.rs //@ compile-flags: -Zunpretty=expanded #![feature(derive_smart_pointer)] #[macro_use] extern crate another_proc_macro; #[pointee] fn f() {} #[default] fn g() {} </ins>

Related discussion:
text: https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
/// This function should maybe change to /// `new_const<const MSG: &'static str>(kind: ErrorKind)` /// in the future, when const generics allow that. <ins> #[inline] </ins> pub(crate) const fn new_const(kind: ErrorKind, message: &'static &'static str) -> Error { Self { repr: Repr::SimpleMessage(kind, message) } }

Related discussion:
text: I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.
Code change:
} } <ins> pub mod signal { use libc::types::os::arch::c95::c_int; use libc::types::os::common::posix01::sighandler_t; #[cfg(not(target_os = "android"))] extern { pub fn signal(signum: c_int, handler: sighandler_t) -> sighandler_t; } #[cfg(target_os = "android")] extern { #[link_name = "bsd_signal"] pub fn signal(signum: c_int, handler: sighandler_t) -> sighandler_t; } } </ins> pub mod wait { use libc::types::os::arch::c95::{c_int}; use libc::types::os::arch::posix88::{pid_t};

Related discussion:
text: Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from
Code change:
<ins> // Regression test for #54779, checks if the diagnostics are confusing. #![feature(nll)] trait DebugWith<Cx: ?Sized> { fn debug_with<'me>(&'me self, cx: &'me Cx) -> DebugCxPair<'me, Self, Cx> { DebugCxPair { value: self, cx } } fn fmt_with(&self, cx: &Cx, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result; } struct DebugCxPair<'me, Value: ?Sized, Cx: ?Sized> where Value: DebugWith<Cx>, { value: &'me Value, cx: &'me Cx, } trait DebugContext {} struct Foo { bar: Bar, } impl DebugWith<dyn DebugContext> for Foo { fn fmt_with( &self, cx: &dyn DebugContext, fmt: &mut std::fmt::Formatter<'_>, ) -> std::fmt::Result { let Foo { bar } = self; bar.debug_with(cx); //~ ERROR: lifetime may not live long enough Ok(()) } } struct Bar {} impl DebugWith<dyn DebugContext> for Bar { fn fmt_with( &self, cx: &dyn DebugContext, fmt: &mut std::fmt::Formatter<'_>, ) -> std::fmt::Result { Ok(()) } } fn main() {} </ins>

Related discussion:
text: This example: gives this error: It took me some time to puzzle out what was happening here: expands to the default from the impl however is the impl method is accepted because it is more general than the trait definition but it fails to recursively invoke The error message without NLL, of course, is also not very illuminating.
Assigning myself to bookmark.
This seems to be a persistent ergonomics wart where traits get evaluated to (happens as well with returning and others I can't remember now) where it isn't expected. It is a bit sad, and we can improve the diagnostic errors, but I'm worried we'll be unable to preempt all the cases from being caught by accurate diagnostics, pushing people away from deeply nested structures. Maybe that is for the best, though.
I just want to note that the use of is, I think, a red herring in terms of the complaint about the diagnostic here. That is, I get the exact same diagnostic even if I add an explicit binder to the method, and then one can remove the . This is relevant because it means that if that feature is a red herring, then this bug may be relevant to the 2018 edition.
discussed with . We agreed this is not a blocker for 2018 edition. Tagging with NLL-deferred so it does not clog up our triage process.
I forgot to actual test how migration-mode (enabled for the 2018 edition) compares to . <detailsCurrent (nightly) 2018 edition output (): Current (nightly) output with (): </details
As for this week's triage, tagging this as P-medium priority.
I recently landed some changes ( and ) that are tangentially related to this but a similar strategy to them could be applied to this case.
Since feature has been removed, can this issue be closed as obsolete?
The example without : The error message isn't the same as migrate mode, but is on-par in terms of information (pointing out that the anonymous lifetime doesn't live as long as ). This issue can be closed by adding the above as a test.
Code change:
<ins> // aux-build:issue-99221-aux.rs // build-aux-docs // ignore-cross-compile #![crate_name = "foo"] #[macro_use] extern crate issue_99221_aux; pub use issue_99221_aux::*; // @count foo/index.html '//a[@class="macro"]' 1 mod inner { #[macro_export] macro_rules! print { () => () } } </ins>

Related discussion:
text: I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- 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
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.
Code change:
map.insert("required-associated-consts".into(), 1); map.insert("required-methods".into(), 1); map.insert("provided-methods".into(), 1); <ins> map.insert("object-safety".into(), 1); </ins> map.insert("implementors".into(), 1); map.insert("synthetic-implementors".into(), 1); map.insert("implementations-list".into(), 1);

Related discussion:
text: So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".
Code change:
map.insert("required-associated-consts".into(), 1); map.insert("required-methods".into(), 1); map.insert("provided-methods".into(), 1); <ins> map.insert("object-safety".into(), 1); </ins> map.insert("implementors".into(), 1); map.insert("synthetic-implementors".into(), 1); map.insert("implementations-list".into(), 1);

Related discussion:
text: My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.
Code change:
}) { let (child_field_idx, child_capture) = child_captures.next().unwrap(); <ins> // This analysis only makes sense if the parent capture is a // prefix of the child capture. assert!( child_capture.place.projections.len() >= parent_capture.place.projections.len(), "parent capture ({parent_capture:#?}) expected to be prefix of  child capture ({child_capture:#?})" ); </ins> // Store this set of additional projections (fields and derefs). // We need to re-apply them later. let child_precise_captures =

Related discussion:
text: This bug only happens when calling a method on two different referenced variables inside an async closure. For some reason, this bug will not happen if the lines are flipped (calling it on test first then temp). It also will not happen if test isn't cloned outside the closure first. This will error: This will not: Neither will: Nor will: But if both the order is flipped and the line order is flipped it will crash (variable name changed to make sure shadowing wasn't the issue): This setup for the bug was found entirely through trial and error. The original issue was found in a nightly build of a project I'm working on (). This bug was introduced in the latest version of nightly (2024-04-08). It was not present in 2024-04-07. rustc 1.79.0-nightly ( 2024-04-08) binary: rustc commit-hash: commit-date: 2024-04-08 host: x8664-pc-windows-msvc release: 1.79.0-nightly LLVM version: 18.1.3 ICE txt file:
thank you for producing these examples; they're very helpful. i will have a fix out tomorrow, sorry for the inconvenience and hope it doesn't discourage you from testing async closures more.
Wow, that was quick! Thanks, I'll make sure to report any more I come across, I plan on implementing more async closures into the project with my next big refactor because of how helpful they are.
Code change:
/// } /// ``` #[inline] <del> #[unstable(feature = "needs_drop", issue = "41890")] </del> <ins> #[stable(feature = "needs_drop", since = "1.22.0")] </ins> pub fn needs_drop<T>() -> bool { unsafe { intrinsics::needs_drop::<T>() } }

Related discussion:
text: About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Code change:
let tcx = self.infcx.tcx; let generics = tcx.generics_of(self.mir_def_id); let param = generics.type_param(&param_ty, tcx); <del> if let Some(generics) = tcx.hir().get_generics(self.mir_def_id) { </del> <ins> if let Some(generics) = tcx.hir().get_generics(tcx.closure_base_def_id(self.mir_def_id)) { </ins> suggest_constraining_type_param( generics, &mut err,

Related discussion:
text: I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be
Code change:
//////////////////////////////////////////////////////////////////////////////// #[macro_use] mod local; <del> #[macro_use] mod scoped; </del> <ins> #[macro_use] mod scoped_tls; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::local::{LocalKey, LocalKeyState};

Related discussion:
text: I have no idea what's causing this, but on the current nightly, this fails: with "use of unstable library feature 'threadlocalinternals'." Enabling the feature works, but this should be a stable function. Interestingly, tweaking the works: I wonder if it's because there is a (private) sub-module called which has a module-wide marker. Version info:
This change was introduced just recently: I reproduced the problem without using anything thread-related: Commands: Output: If I remove the attribute from the module, the code gives me the error. I mark as stable, then the code compiles. If I instead remove the function, I get the bar error. cc
With merged, is this fixed?
The exact issue at hand has been resolved, but the underlying issue remains. Specifically a module and free-function of the same name but different stability level will cause problems.
Also hit by this; still affecting the nightly for osx right now, but hopefully the next build will include the fix.
Stability is an internal detail. This is unlikely to impact out-of-tree code.
Code change:
<ins> error[E0277]: expected a `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` --> $DIR/issue-100690.rs:37:23 | LL |         real_dispatch(f) |         ------------- ^ expected an `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` |         | |         required by a bound introduced by this call | = note: expected a closure with arguments `(&mut UIView<'a, T>,)` found a closure with arguments `(&mut UIView<'_, T>,)` note: required by a bound in `real_dispatch` --> $DIR/issue-100690.rs:9:8 | LL | fn real_dispatch<T, F>(f: F) -> Result<(), io::Error> |    ------------- required by a bound in this ... LL |     F: FnOnce(&mut UIView<T>) -> Result<(), io::Error> + Send + 'static, |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `real_dispatch` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: Sorry, this is not necessarily the smallest possible example. Please let me know if this is unhelpful and I'll come up with something more concise. Given the following code: The output in current stable (1.63.0) is: (Please note the "expected closure with ... found closure with ..." hint.) From 1.64 onwards, the expected/found hint is omitted: To me the 1.63 behaviour is preferable to that from 1.64+ as it can often be non-obvious where the differences lie.
searched nightlies: from nightly-2022-06-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Looks like it was caused by , which is pretty big diagnostics PR in that rollup. cc
Of course I caused it.
label -E-needs-bisection
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
<ins> error: unexpected closing delimiter: `}` --> $DIR/issue-98601-delimiter-error-1.rs:7:1 | LL | fn foo() { |          - this delimiter might not be properly closed... LL |     match 0 { LL |       _ => {} |            -- block is empty, you might have not meant to close it ... LL |     } |     - ...as it matches this but it has different indentation LL | } | ^ unexpected closing delimiter error: aborting due to previous error </ins>

Related discussion:
text: See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).