jiebi/CodeConvo huggingface dataset:
Change:
Rust PR: This feature adds the following methods to : -
Anything in particular holding up the stabilization here? The implementation is trivial and docs lgtm.
I would like to add methods that return an exact , but that can wait.
These methods are a little odd, but seem reasonable to me following the example given:
Given how straightforward these methods are, I don't think there's any problem stabilising them?
They're straightforward in implementation, but conceptually tricky at a glance. I think the docs will need some fleshing out before stabilizing but I don't have any other concerns if somebody wants to write a PR!
This needs more testing with various interesting values that could produce interesting floating point numbers, and should not be stabilized without such.
tests were in this PR

Discussion:
/// /// # Examples /// ``` <del> /// #![feature(div_duration)] </del> /// use std::time::Duration; /// /// let dur1 = Duration::new(2, 700_000_000); /// let dur2 = Duration::new(5, 400_000_000); /// assert_eq!(dur1.div_duration_f64(dur2), 0.5); /// ``` <del> #[unstable(feature = "div_duration", issue = "63139")] </del> <ins> #[stable(feature = "div_duration", since = "CURRENT_RUSTC_VERSION")] </ins> #[must_use = "this returns the result of the operation,  without modifying the original"] #[inline] #[rustc_const_unstable(feature = "duration_consts_float", issue = "72440")] pub const fn div_duration_f64(self, rhs: Duration) -> f64 { <del> self.as_secs_f64() / rhs.as_secs_f64() </del> <ins> let self_nanos = (self.secs as f64) * (NANOS_PER_SEC as f64) + (self.nanos.0 as f64); let rhs_nanos = (rhs.secs as f64) * (NANOS_PER_SEC as f64) + (rhs.nanos.0 as f64); self_nanos / rhs_nanos </ins> } /// Divide `Duration` by `Duration` and return `f32`. /// /// # Examples /// ``` <del> /// #![feature(div_duration)] </del> /// use std::time::Duration; /// /// let dur1 = Duration::new(2, 700_000_000); /// let dur2 = Duration::new(5, 400_000_000); /// assert_eq!(dur1.div_duration_f32(dur2), 0.5); /// ``` <del> #[unstable(feature = "div_duration", issue = "63139")] </del> <ins> #[stable(feature = "div_duration", since = "CURRENT_RUSTC_VERSION")] </ins> #[must_use = "this returns the result of the operation,  without modifying the original"] #[inline] #[rustc_const_unstable(feature = "duration_consts_float", issue = "72440")] pub const fn div_duration_f32(self, rhs: Duration) -> f32 { <del> self.as_secs_f32() / rhs.as_secs_f32() </del> <ins> let self_nanos = (self.secs as f32) * (NANOS_PER_SEC as f32) + (self.nanos.0 as f32); let rhs_nanos = (rhs.secs as f32) * (NANOS_PER_SEC as f32) + (rhs.nanos.0 as f32); self_nanos / rhs_nanos </ins> } }

#![feature(core_private_bignum)] #![feature(core_private_diy_float)] #![feature(dec2flt)] <del> #![feature(div_duration)] </del> #![feature(duration_abs_diff)] #![feature(duration_consts_float)] #![feature(duration_constants)]
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
The Miri update to fix this is happening in

Discussion:
<del> Subproject commit e276676f0c0fc16f41e46cc56cb7a9362dc717b0 </del> <ins> Subproject commit 39a524f694e42cfb178639d490d3fdbbaf8569dc </ins>
Change:
() changing into inside will successfully compile
modify labels: A-impl-trait, F-typealiasimpl_trait, C-bug, I-ICE, T-compiler, requires-nightly
Source: <details<summaryStack trace</summary<p</p</detailsregression in nightly-2019-08-04 Auto merge of - Centril:sound-bind-by-move, r=matthewjasper Auto merge of - pietroalbini:move-azure-pipelines, r=Mark-Simulacrum Auto merge of - Centril:rollup-h9t731z, r=Centril Auto merge of - RalfJung:miritypedispatch_first, r=oli-obk Auto merge of - varkor:trait-alias-impl-trait, r=Centril Auto merge of - Centril:rollup-x39p5ga, r=Centril
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Though the error seems incorrect, in I don't see where it is getting the obligation from, nowhere does the code assert that is true.
This example should be disallowed with but is not. I filed to cover that.
I agree with that the behavior here is a bug, I don't think we handle appearing in these sorts of contexts very well, at least within the defining module.
Thanks for triaging, we still should add a regression test to prevent ICE at least, right?
Yep, that's good

Discussion:
<ins> #![feature(min_type_alias_impl_trait)] #![feature(type_alias_impl_trait)] #![allow(incomplete_features)] pub trait Foo {} pub trait Bar { type Foo: Foo; fn foo() -> Self::Foo; } pub trait Baz { type Foo: Foo; type Bar: Bar<Foo = Self::Foo>; fn foo() -> Self::Foo; fn bar() -> Self::Bar; } impl Foo for () {} impl Bar for () { type Foo = FooImpl; fn foo() -> Self::Foo { () } } // FIXME(#86731): The below is illegal use of `min_type_alias_impl_trait` // but the compiler doesn't report it, we should fix it. pub type FooImpl = impl Foo; pub type BarImpl = impl Bar<Foo = FooImpl>; //~^ ERROR: type mismatch resolving `<() as Bar>::Foo == ()` impl Baz for () { type Foo = FooImpl; type Bar = BarImpl; fn foo() -> Self::Foo { () } fn bar() -> Self::Bar { () } } fn main() {} </ins>

<ins> error[E0271]: type mismatch resolving `<() as Bar>::Foo == ()` --> $DIR/issue-63355.rs:34:20 | LL | pub type FooImpl = impl Foo; |                    -------- the found opaque type LL | pub type BarImpl = impl Bar<Foo = FooImpl>; |                    ^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found opaque type | = note: expected unit type `()` found opaque type `impl Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>
Change:
An ICE is observable with this code: Changing to take a rather than makes the ICE go away.
Investigation shows that will trigger the ICE, while will not
Introduced in cc We can probably get away with doing an early return if and no other changes.

Discussion:
// We only want to handle exclusive (`..`) ranges, // which are represented as `ExprKind::Struct`. if let ExprKind::Struct(_, eps, _) = &parent_expr.node { <del> debug_assert_eq!(eps.len(), 2); </del> <ins> if eps.len() != 2 { return false; } </ins> // We can suggest using an inclusive range // (`..=`) instead only if it is the `end` that is // overflowing and only by 1.

<ins> fn part(_: u16) -> u32 { 1 } fn main() { for n in 100_000.. { //~^ ERROR: literal out of range for `u16` let _ = part(n); } } </ins>

<ins> error: literal out of range for `u16` --> $DIR/issue-63364.rs:6:14 | LL |     for n in 100_000.. { |              ^^^^^^^ | = note: `#[deny(overflowing_literals)]` on by default error: aborting due to previous error </ins>
Change:
Follow up of . These two particular cases could not be refactored due to an ambiguity issue: With Result (line numbers are off): With Result (line numbers are off): cc
cc also
Thanks for this report. If you/Centril/someone could produce a MCVE, I would then be happy to investigate further... right now I don't have the time to reduce it though, I'm afraid.
I tried again for an hour or two without success. Unfortunately I don't know enough about the internals to understand how this could happen. I'll look at the associated type bounds PR, maybe that will help.
This is odd; I basically pasted the code in verbatim into the , made it compile, and the made the tweaks above. The issue still won't reproduce but it does reproduce when I . Maybe this is a bootstrapping issue... in which case we'll know in a few hours.

Discussion:
impl<I: DoubleEndedIterator, U, F> DoubleEndedIterator for FlatMap<I, U, F> where F: FnMut(I::Item) -> U, <del> U: IntoIterator, U::IntoIter: DoubleEndedIterator, </del> <ins> U: IntoIterator<IntoIter: DoubleEndedIterator>, </ins> { #[inline] fn next_back(&mut self) -> Option<U::Item> { self.inner.next_back() }

/// [`Iterator`]: trait.Iterator.html #[must_use = "iterators are lazy and do nothing unless consumed"] #[stable(feature = "iterator_flatten", since = "1.29.0")] <del> pub struct Flatten<I: Iterator> where I::Item: IntoIterator, { </del> <ins> pub struct Flatten<I: Iterator<Item: IntoIterator>> { </ins> inner: FlattenCompat<I, <I::Item as IntoIterator>::IntoIter>, }
Change:
This ICEs (see title) because of the call: That's because the definition of errored in 1.34, but doesn't since 1.35: cc (found while working on )
<details<summaryBacktrace</summary</details
Ah, the problem is that this wasn't updated ( now contains a ): Thankfully, at the same time, the ICE was , so calls wouldn't have been possible to such functions.
Good catch

Discussion:
let args: Vec<_> = args.into_iter().filter_map(|x| x).collect(); <del> if c_variadic && args.is_empty() { </del> <ins> if c_variadic && args.len() <= 1 { </ins> self.span_err(sp, "C-variadic function must be declared with at least one named argument"); }

<ins> extern { fn foo(...); //~^ ERROR C-variadic function must be declared with at least one named argument } fn main() {} </ins>

<ins> error: C-variadic function must be declared with at least one named argument --> $DIR/variadic-ffi-no-fixed-args.rs:2:11 | LL |     fn foo(...); |           ^ error: aborting due to previous error </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler team triage: marking as P-high, as miri should build. -- any idea what it takes to fix this?
It's already fixed in the Miri repo. Just takes someone to do the PR for rustc. do you want to do that? Also in the past we treated these as P-medium. Ultimately of course this is up to the compiler team, I personally will always treat it as high priority to keep at least the Miri repo itself working.
OK. I think it ought to be high priority to keep things building, personally, but I'm happy to defer to convention for now, as we have too many P-high bugs ultimately.
claim

Discussion:
<del> Subproject commit c1cb24969e84dfaded2769ab5575effc8d4f5c30 </del> <ins> Subproject commit 4f6f264c305ea30f1de90ad0c2f341e84d972b2e </ins>
Change:
Caused by . To be precise the change. It basically does: Because uses to refer to , it will try to resolve it in , which doen't contain .
cc
This regression affects another project I am working on as well. is there any status on this?
I'm not sure what the details of were, but this feels like a bug to me -- in particular it feels like the behavior here is less hygienic, not more? perhaps you can clarify your view on the situation, that'd be great.
Well, it's more hygienic than before because previously used whatever was closest in scope at the call site, while now it certainly uses from the crate named . (That doesn't make the change less breaking.) What really wants is to use def-site hygiene so that "the crate named " is searched from the 's definition point of view. (Not possible right now due to def-site hygiene for crates not being implemented.) In the meantime the change to can be reverted to fix the regression.
I see -- just not necessarily the core that was in scope at the point of definition. Seems right. Is there a tracking issue to cc or something?
That said, the constructions or (same, but from command line) really require some responsibility since they effectively override and . If you override them you should be able to provide all the necessary services expected from and , since for any third party macro is the only reliable way to refer to the standard library, at least until def-site hygiene is fully implemented and stabilized.
Is there a tracking issue to cc or something? This is supposed to be the tracking issue for the regression?
While most of the changes in 's PR have increased hygiene, the specific change linked by didn't do any increase (or decrease) as both times the macro is being resolved in an unhygienic way. From a pragmatic point of view, lots of people seem to shadow the core crate but few people want to (saying "want to" and not "do" because of selection bias) shadow the macro while wanting to use the builtin one for which is what the change now allows you to do. Furthermore, not breaking downstream users should always be a priority. It's not their fault that the format macro uses something in an unhygienic way. IMO the specific change should be reverted. There is a pattern to use std or any other third party crate in a hygienic way. You define a in and then use to refer to std items in the macro.
Fixed in
check-in from compiler triage: marking as p-high, but has a pending fix already

Discussion:
mod std { pub use core::ops; // RangeFull } <ins> #[doc(hidden)] #[unstable(feature = "liballoc_internals", issue = "0", reason = "implementation detail")] pub mod __export { pub use core::format_args; } </ins>

#[macro_export] #[stable(feature = "rust1", since = "1.0.0")] macro_rules! format { <del> ($($arg:tt)*) => ($crate::fmt::format(::core::format_args!($($arg)*))) </del> <ins> ($($arg:tt)*) => ($crate::fmt::format($crate::__export::format_args!($($arg)*))) </ins> }
Change:
I updated a dependency and the type of a struct field changed from an to a . I am assigning a value to this struct field. Before, I was calling to convert the to an . With the upgrade this is unnecessary since the field and the value are both . The rust compiler suggests this fix: But it should really suggest removing the and using the directly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am using Rust 1.37.0.
cc
Similarly, this code should suggest replacing with .
For the case where we have and an was expected, what should be the correct behavior? I believe simply suggesting is appropriate, if funny looking, because the could_ be coming from outside a macro, and the error be inside of one. Thoughts?
that sounds good to me
claim
Which of these options makes more sense? Check if the new (suggested) conversion is infallible always (doesn't make sense in the 1st case?) only in the 2nd case (if the new conversion is fallible, I presume we fall back to other suggestions and should be suggested, which makes a bit of sense, since it highlights the possible panic?) never (if is detected, always suggest to replace with ) Seems like the user already opted in for panicking if the conversion fails, so conversion was fallible and will stay so:The conversion is infallible but will become fallible if the suggestion is applied:
release-assignment
sorry, didn't see your claim before I pushed my PR :-|

Discussion:
return false; } } <ins> if let hir::ExprKind::Call(path, args) = &expr.node { if let ( hir::ExprKind::Path(hir::QPath::TypeRelative(base_ty, path_segment)), 1, ) = (&path.node, args.len()) { // `expr` is a conversion like `u32::from(val)`, do not suggest anything (#63697). if let ( hir::TyKind::Path(hir::QPath::Resolved(None, base_ty_path)), sym::from, ) = (&base_ty.node, path_segment.ident.name) { if let Some(ident) = &base_ty_path.segments.iter().map(|s| s.ident).next() { match ident.name { sym::i128 | sym::i64 | sym::i32 | sym::i16 | sym::i8 | sym::u128 | sym::u64 | sym::u32 | sym::u16 | sym::u8 | sym::isize | sym::usize if base_ty_path.segments.len() == 1 => { return false; } _ => {} } } } } } </ins> let msg = format!("you can convert an `{}` to `{}`", checked_ty, expected_ty); let cast_msg = format!("you can cast an `{} to `{}`", checked_ty, expected_ty);

<ins> fn main() { let _: u32 = i32::from(0_u8); //~ ERROR mismatched types } </ins>

<ins> error[E0308]: mismatched types --> $DIR/mismatched-types-numeric-from.rs:2:18 | LL |     let _: u32 = i32::from(0_u8); |                  ^^^^^^^^^^^^^^^ expected u32, found i32 error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
When selecting Rust source code with either the latest stable or the latest nightly, the following is seen: e.g. see and try and select some lines Suspect that should be . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
var set_fragment = function(name) { if (browserSupportsHistoryApi()) { history.replaceState(null, null, "#" + name); <del> window.hashchange(); </del> <ins> highlightSourceLines(null); </ins> } else { location.replace("#" + name); }
Change:
Hey Folks, So, I've been fuzz testing nightly using a range of generated programs and am digesting the findings. This one stood out to me: This currently reports an E0505 on the playground and Rust nightly. However, removing the nop and its fine. This feels like a bug to me ... thoughts?
I think this is technically a reborrow () rather than a no-op, because the lhs and rhs are both known to be . Though this might be the first time I've ever seen a reborrow cause fewer programs to compile versus a move! (amusingly, though, the MIR is simply ) Edit: nope, there's more to it than that. If you explicitly write , it compiles!
Ok, have found some more related cases: Above gives and . Above gives and .
Discussed in lang team pre-triage meeting. Maybe you'd be game to investigate and take a look at what's happening here?

Discussion:
debug!("Borrows::statement_effect: stmt={:?}", stmt); match stmt.kind { mir::StatementKind::Assign(ref lhs, ref rhs) => { <del> // Make sure there are no remaining borrows for variables // that are assigned over. self.kill_borrows_on_place(trans, lhs); </del> if let mir::Rvalue::Ref(_, _, ref place) = **rhs { if place.ignore_borrow( self.tcx,

trans.gen(*index); } <ins> // Make sure there are no remaining borrows for variables // that are assigned over. self.kill_borrows_on_place(trans, lhs); </ins> } mir::StatementKind::StorageDead(local) => {

<ins> // Check that `*y` isn't borrowed after `y = y`. // check-pass fn main() { let mut x = 1; { let mut y = &mut x; y = y; y; } x; { let mut y = &mut x; y = y; y = y; y; } x; } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
should fix this

Discussion:
"rustc_interface", "rustc_metadata", "rustc_mir", <ins> "rustc_plugin", </ins> "rustc_plugin_impl", "rustc_save_analysis", "rustc_target",

] [[package]] <ins> name = "rustc_plugin" version = "0.0.0" dependencies = [ "rustc_plugin_impl", ] [[package]] </ins> name = "rustc_plugin_impl" version = "0.0.0" dependencies = [

errors = { path = "../librustc_errors", package = "rustc_errors" } rustc_metadata = { path = "../librustc_metadata" } rustc_mir = { path = "../librustc_mir" } <ins> rustc_plugin = { path = "../librustc_plugin/deprecated" } # To get this in the sysroot </ins> rustc_plugin_impl = { path = "../librustc_plugin" } rustc_save_analysis = { path = "../librustc_save_analysis" } rustc_codegen_utils = { path = "../librustc_codegen_utils" }

#![doc(html_root_url = "https://doc.rust-lang.org/nightly/")] #![feature(staged_api)] <del> #![unstable(feature = "rustc_plugin", issue = "29597")] </del> <ins> #![unstable(feature = "rustc_private", issue = "27812")] </ins> #![rustc_deprecated(since = "1.38.0", reason = " import this through `rustc_driver::plugin` instead to make TLS work correctly.  See https://github.com/rust-lang/rust/issues/62717")]
Change:
This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?

Discussion:
/// Converts a vector of bytes to a `String`. /// <del> /// A string slice ([`&str`]) is made of bytes ([`u8`]), and a vector of bytes </del> <ins> /// A string ([`String`]) is made of bytes ([`u8`]), and a vector of bytes </ins> /// ([`Vec<u8>`]) is made of bytes, so this function converts between the /// two. Not all byte slices are valid `String`s, however: `String` /// requires that it is valid UTF-8. `from_utf8()` checks to ensure that

/// If you need a [`&str`] instead of a `String`, consider /// [`str::from_utf8`]. /// <del> /// The inverse of this method is [`as_bytes`]. </del> <ins> /// The inverse of this method is [`into_bytes`]. </ins> /// /// # Errors ///

/// with this error. /// /// [`from_utf8_unchecked`]: struct.String.html#method.from_utf8_unchecked <del> /// [`&str`]: ../../std/primitive.str.html </del> <ins> /// [`String`]: struct.String.html </ins> /// [`u8`]: ../../std/primitive.u8.html /// [`Vec<u8>`]: ../../std/vec/struct.Vec.html /// [`str::from_utf8`]: ../../std/str/fn.from_utf8.html <del> /// [`as_bytes`]: struct.String.html#method.as_bytes </del> <ins> /// [`into_bytes`]: struct.String.html#method.into_bytes </ins> /// [`FromUtf8Error`]: struct.FromUtf8Error.html /// [`Err`]: ../../std/result/enum.Result.html#variant.Err #[inline]
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Needs a xargo fix, which is on its way at

Discussion:
"compiletest_rs", "directories", "env_logger 0.6.0", <ins> "getrandom", </ins> "hex", "log", "num-traits",

<del> Subproject commit d77fe6c63ca4c50b207a1161def90c9e57368d5b </del> <ins> Subproject commit 69268fb75fdb452296caa9bc4aaeff1674279de2 </ins>