jiebi/CodeConvo huggingface dataset:
Code change:
<ins> #![allow(bare_trait_objects)] // check-pass pub struct FormatWith<'a, I, F> { sep: &'a str, /// FormatWith uses interior mutability because Display::fmt takes &self. inner: RefCell<Option<(I, F)>>, } use std::cell::RefCell; use std::fmt; struct Layout; pub fn new_format<'a, I, F>(iter: I, separator: &'a str, f: F) -> FormatWith<'a, I, F> where I: Iterator, F: FnMut(I::Item, &mut FnMut(&fmt::Display) -> fmt::Result) -> fmt::Result, { FormatWith { sep: separator, inner: RefCell::new(Some((iter, f))) } } fn main() { let _ = new_format(0..32, " | ", |i, f| f(&format_args!("0x{:x}", i))); } </ins>

Related discussion:
text: ndarray 0.9.1 compiles with rustc 1.61.0 but not with rustc 1.64.0-nightly ( 2022-06-27). Put this into a of a new project: rustc stable <= 1.61.0 compiles the crate fine, rustc nightly gives the following error: modify labels: +regression-from-stable-to-nightly -regression-untriaged
Just adding a note. The issue seems to be an old version of that used to use back in v0.9.1 <details</detailsThe crate from v0.13.0 (released in sept. 2019) compiles fine also on latest Rust nightly
bisection seems to point to commit cc searched nightlies: from nightly-2022-04-01 to nightly-2022-06-28 regressed nightly: nightly-2022-06-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details(unsure if this regression may hit other more recent crates)
I've been suspecting this bug for a few days, but unable to reproduce it. I think I have a patch, will confirm once I manage to MCVE.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
}); tcx.infer_ctxt().ignoring_regions().enter(|ref infcx| { <del> let mut fulfill_ctxt = <dyn TraitEngine<'_>>::new(tcx); fulfill_ctxt.register_predicate_obligations(infcx, predicates_for_trait); !fulfill_ctxt.select_all_or_error(infcx).is_empty() </del> <ins> for obligation in predicates_for_trait { // Ignore overflow error, to be conservative. if let Ok(result) = infcx.evaluate_obligation(&obligation) && !result.may_apply() { return true; } } false </ins> }) }

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: I expected to see this happen: Rustdoc compiles the documentation as for older toolchains (stable, < nightly-2022-08-10) or as it is happening for / Instead, this happened: Rustdoc reports an compiler error <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2022-08-09 : : points to as merge that introduced this regression which is a roll-up PR. and are included there and seems to be rustdoc releated. Pinging and as authors of these PR's. <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the bug is coming from cc EDIT: also, would be quite useful to have a minimum code that we can use as a regression test.
Reducing compiler errors coming from diesel is quite hard and takes a lot of time. Diesel is already part of the rust compiler tests-suite, although in an older version. So it might be easier to just update this version to a current diesel version.
This is due to my PR. claim
is not documented inside the compiler so it wouldn't be very helpful unfortunately. Also, I didn't ask you specifically, just thought it might be useful to say it, so don't worry if you don't have time for it. :wink: Thanks !
The corresponding test code is here: I think it did not catch this issue as it uses an older diesel version (and it does not enable the corresponding feature flag).
I minimized this: And fix PR incoming.
This apparently was not fixed.
I can confirm that this is fixed for . Thank you all for the fast fix :tada:
Code change:
|| self.suggest_into(err, expr, expr_ty, expected) || self.suggest_floating_point_literal(err, expr, expected); if !suggested { <del> self.point_at_expr_source_of_inferred_type(err, expr, expr_ty, expected); </del> <ins> self.point_at_expr_source_of_inferred_type(err, expr, expr_ty, expected, expr.span); </ins> } }

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
let b: Vec<isize> = a.iter().cloned().collect(); assert!(a == b); } <ins> // just tests by whether or not this compiles fn _empty_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::iter::Empty<T>>(); } </ins>

Related discussion:
text: Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.
Code change:
#![feature(const_cstr_unchecked)] #![feature(core_intrinsics)] #![feature(dropck_eyepatch)] <del> #![feature(duration_as_u128)] </del> <ins> #![cfg_attr(stage0, feature(duration_as_u128))] </ins> #![feature(exact_size_is_empty)] #![feature(external_doc)] #![feature(fixed_size_array)]

Related discussion:
text: Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability. CC:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
I think it's about the way you think of . If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative. You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Here is what I take issue with: And....DING! DING! DING! know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
You can use if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error, but, instead return ClockTimeDifference. It could be as simple as:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable?
Code change:
#![feature(const_cstr_unchecked)] #![feature(core_intrinsics)] #![feature(dropck_eyepatch)] <del> #![feature(duration_as_u128)] </del> <ins> #![cfg_attr(stage0, feature(duration_as_u128))] </ins> #![feature(exact_size_is_empty)] #![feature(external_doc)] #![feature(fixed_size_array)]

Related discussion:
text: For my usecase, I probably don't need more than a , and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have a , but I'm just not sure what to do here for my code which I'm trying to keep as close to fully stable as possible (I want it to be as portable and safe as I can make it). I know (I think?) I can use , but I'd rather not lose the precision and I think I can always use for all my platforms.
is there any reason not to move forward with stabilization on this? correctly observes that it has been unstable for quite a while
The stability of u128 was the blocker previously, but that's now no longer a problem. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] No concerns currently listed. 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.
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
This may be a stupid question, but is available on all platforms that Rust supports?
:bell: This is now entering its final comment period, as per the . :bell:
Yep, it should be available on all platforms.
The final comment period, with a disposition to merge, as per the , is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
Awesome! I've made a PR for stabilization here: Please let me know if it needs any adjustments. I can't wait for this to land! :tada:
Code change:
//~^ ERROR missing code example in this documentation pub fn bar() {} } <ins> // This impl is here to ensure the lint isn't emitted for foreign traits implementations. impl std::ops::Neg for Foo { type Output = Self; fn neg(self) -> Self::Output { Self } } </ins>

Related discussion:
text: The lint seems to be erroneously complaining about missing documentation examples where local types implement foreign traits (both from 3rd party crates and the standard library). The example below should pass all checks as far as I can tell: However, running results in the following warnings: :
cc
I think the current lint behavior is correct. The issue here is on the core lib side. I opened to fix it.
Maybe the lint shouldn't warn when implementing a foreign trait? By the same rationale as
Hmmm... I have shared feelings here: if a trait doesn't provided documentation "by default", doesn't it make sense to complain about it on the implementors?
I guess if you can add docs on the implementation it makes sense - you have a way to fix it.
That's mainly my position yes. :)
Unfortunately, that drags with itself more issues. First of all, I have to implement said examples on all of the implementations I write. Second, I have to copy (and correctly maintain said copy) the original example-less documentation onto every instance so that it's not lost by the language server and/or . While this isn't entirely impossible, it's a huge chore, especially when you implement multiple traits on tens of types at a time. While could get its issues fixed, that hardly helps us with the rest of the crate ecosystem. As of now, I have about 300 warnings, and actually useful information just drowns in that flood.
You can disable the lint on a specific implementation in the worst case. However, the goal is to enforce more documentation through the ecosystem. If users start to complain about it to the crates' maintainers, I'm pretty sure the situation will improve pretty quickly.
I don't really like this approach - it should be fixable by you, not by bugging upstream maintainers. was saying something like that for I think.
You can fix it on your side by adding the examples yourself in your implementation. So on that on point, even if not the best, it's still possible.
I suppose in the worst case, I could fork the upstream project, add examples, and hope that it either gets merged or the developer doesn't cause too many conflicts so I can keep it up-to-date.
Code change:
//~^ ERROR missing code example in this documentation pub fn bar() {} } <ins> // This impl is here to ensure the lint isn't emitted for foreign traits implementations. impl std::ops::Neg for Foo { type Output = Self; fn neg(self) -> Self::Output { Self } } </ins>

Related discussion:
text: But even then, it takes a lot of back-and-forth, a lot of time and effort on both ends to get from my linter complaining about missing examples to a new crate release that fixes it - even if everything goes quick and smooth. There should at least be a way for me to temporarily ignore warnings coming from (or rather because of) 3rd party and standard library crates, so that - at the minimum - I can fix my own linting issues without having to comb through thousands of lines of all too similar lines of warnings every time I generate documentation for testing purposes.
on the implementation?
Like I said, you can ignore the lint on the implementations, or directly on a module if it only contains such cases. Adding a doesn't seem to be such a burden...
Let it be known that I was today days old when I learned that you can apply to a single block. I suppose that will have to suffice for now.
I strongly feel that we should not warn on foreign trait implementations here. Firstly, as said, a lint should be fixable by you. Yes, you can add examples yourself, but that isn't actually the real fix here in most cases. In most cases trait implementations are lightweight and you rarely document them, so you're not actually giving the user a "fix", you're asking them to do something they don't actually want to shut the lint up. That's not good, that is not the actual fix, the actual fix is asking people to fix it upstream, and we should not lint that downstream. "The lint can be ignored" is not good enough for normal situations -- if it was some weird confluence of situations, then, sure, but a foreign trait impl is an extremely normal thing to do.
Coming back on this after a while and I now agree with this issue: we shouldn't lint on foreign trait implementations. I'll send a fix in the following days.
I just tried locally and it seems like this issue has already been fixed. Closing it then.
we should still test that it behaves properly
I'll send a test if there isn't already one then.
Code change:
}), } } else { <del> self.instantiate_canonical_var(cause.span, info, |u| { universe_map[u.as_usize()] }) </del> <ins> // For placeholders which were already part of the input, we simply map this // universal bound variable back the placeholder of the input. opt_values[BoundVar::new(index)].expect( "expected placeholder to be unified with itself during response", ) </ins> } }), ),

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Code change:
/// Here's an example of how a collection might make use of needs_drop: /// /// ``` <del> /// #![feature(needs_drop)] </del> /// use std::{mem, ptr}; /// /// pub struct MyCollection<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:
if !parser.errors.is_empty() { let err = parser.errors.remove(0); <del> let err_sp = template_span.from_inner(InnerSpan::new(err.span.start, err.span.end)); </del> <ins> let err_sp = if template_is_mac_call { // If the template is a macro call we can't reliably point to the error's // span so just use the template's span as the error span (fixes #129503) template_span } else { template_span.from_inner(InnerSpan::new(err.span.start, err.span.end)) }; </ins> let msg = format!("invalid asm template string: {}", err.description); let mut e = ecx.dcx().struct_span_err(err_sp, msg); e.span_label(err_sp, err.label + " in asm template string");

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to
Code change:
<ins> // check-pass struct Indexable; impl Indexable { fn boo(&mut self) {} } impl std::ops::Index<&str> for Indexable { type Output = Indexable; fn index(&self, field: &str) -> &Indexable { self } } impl std::ops::IndexMut<&str> for Indexable { fn index_mut(&mut self, field: &str) -> &mut Indexable { self } } fn main() { let mut v = Indexable; let field = "hello".to_string(); v[field.as_str()].boo(); v[&field].boo(); // < This should work } </ins>

Related discussion:
text: We've run into an issue where we have a type that implements both and . Passing an index value of causes rustc to choose instead of , even if a mutable reference is required. If we first call and use that as the index, is chosen, as expected. Example repro by (see ): I expected to see this happen: should invoke on since expects a mutable reference. Instead, this happened: invoked and complained that isn't implemented even though it is: <!-- 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. --This is reproducible on stable Rust 1.41.0 and 1.43.0 and . cc:
I have a hacky solution to this in . Looking this code up in godbolt I can reproduce it all the way to 1.0, earlier versions giving a type error ( vs ), then an ICE in the 1.2x (that I was causing during my experiments to fix this: ) and finally the current error. The problem is caused (somehow) in slightly differing from , but haven't figured how to fix that underlying difference.
In case this helps to find the root problem, gives a similar error: " is not implemented" even though it really is.
It seems closely related but sadly doesn't change the behavior on that ticket. I'll take a look at it though.
Code change:
} } <ins> fn trace_macros_note(cx: &mut ExtCtxt, sp: Span, message: String) { let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(message); } </ins> /// Given `lhses` and `rhses`, this is the new macro we create fn generic_extension<'cx>(cx: &'cx mut ExtCtxt, sp: Span,

Related discussion:
text: Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.
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. // #29924 #![feature(const_fn, associated_consts)] trait Trait { const N: usize; } impl Trait { //~^ ERROR the trait `Trait` cannot be made into an object [E0038] const fn n() -> usize { Self::N } } fn main() {} </ins>

Related discussion:
text: I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently