jiebi/CodeConvo huggingface dataset:
Code change:
The following code gives "warning: enum is never used: ": This regressed pretty recently. cc
27.0 does not warn, 1.28.0 does.
triage: P-medium; This seems like a papercut that should be easy to work-around (at least if one isn't using ...).
switched to P-high after prompting from
whoops forgot to tag with T-compiler in time for the meeting...
assigning to
I'm grabbing this, I think I broke it and it should be easy to fix

Related discussion:
text: <ins> // compile-pass #[deny(warnings)] enum Empty { } trait Bar<T> {} impl Bar<Empty> for () {} fn boo() -> impl Bar<Empty> {} fn main() { boo(); } </ins>
Code change:
Regression from 1.26.0 to 1.27.0 and later. See for example See also and

Related discussion:
text: fn build_external_function(cx: &DocContext, did: DefId) -> clean::Function { let sig = cx.tcx.fn_sig(did); <del> let constness = if cx.tcx.is_const_fn(did) { </del> <ins> let constness = if cx.tcx.is_min_const_fn(did) { </ins> hir::Constness::Const } else { hir::Constness::NotConst
Code change:
Regression from 1.26.0 to 1.27.0 and later. See for example See also and

Related discussion:
text: (self.generics.clean(cx), (&self.decl, self.body).clean(cx)) }); <ins> let did = cx.tcx.hir().local_def_id(self.id); let constness = if cx.tcx.is_min_const_fn(did) { hir::Constness::Const } else { hir::Constness::NotConst }; </ins> Item { name: Some(self.name.clean(cx)), attrs: self.attrs.clean(cx),
Code change:
Regression from 1.26.0 to 1.27.0 and later. See for example See also and

Related discussion:
text: visibility: self.vis.clean(cx), stability: self.stab.clean(cx), deprecation: self.depr.clean(cx), <del> def_id: cx.tcx.hir().local_def_id(self.id), </del> <ins> def_id: did, </ins> inner: FunctionItem(Function { decl, generics, <del> header: self.header, </del> <ins> header: hir::FnHeader { constness, ..self.header }, </ins> }), } }
Code change:
Regression from 1.26.0 to 1.27.0 and later. See for example See also and

Related discussion:
text: ty::TraitContainer(_) => self.defaultness.has_value() }; if provided { <del> let constness = if cx.tcx.is_const_fn(self.def_id) { </del> <ins> let constness = if cx.tcx.is_min_const_fn(self.def_id) { </ins> hir::Constness::Const } else { hir::Constness::NotConst
Code change:
Regression from 1.26.0 to 1.27.0 and later. See for example See also and

Related discussion:
text: <ins> // Copyright 2018 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. #![crate_name = "foo"] #![unstable(feature = "humans", reason = "who ever let humans program computers, we're apparently really bad at it", issue = "0")] #![feature(rustc_const_unstable, const_fn, foo, foo2)] #![feature(min_const_unsafe_fn)] #![feature(staged_api)] // @has 'foo/fn.foo.html' '//pre' 'pub unsafe fn foo() -> u32' #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_unstable(feature="foo")] pub const unsafe fn foo() -> u32 { 42 } // @has 'foo/fn.foo2.html' '//pre' 'pub fn foo2() -> u32' #[unstable(feature = "humans", issue="0")] pub const fn foo2() -> u32 { 42 } // @has 'foo/fn.bar2.html' '//pre' 'pub const fn bar2() -> u32' #[stable(feature = "rust1", since = "1.0.0")] pub const fn bar2() -> u32 { 42 } // @has 'foo/fn.foo2_gated.html' '//pre' 'pub unsafe fn foo2_gated() -> u32' #[unstable(feature = "foo2", issue="0")] pub const unsafe fn foo2_gated() -> u32 { 42 } // @has 'foo/fn.bar2_gated.html' '//pre' 'pub const unsafe fn bar2_gated() -> u32' #[stable(feature = "rust1", since = "1.0.0")] pub const unsafe fn bar2_gated() -> u32 { 42 } // @has 'foo/fn.bar_not_gated.html' '//pre' 'pub unsafe fn bar_not_gated() -> u32' pub const unsafe fn bar_not_gated() -> u32 { 42 } </ins>
Code change:
Hi, I noticed a weird internal error using . The smallest example I could make to reproduce the bug is an basic library project () whose contains: , , and all work fine; and as mentioned in the code, the place where is declared seems to matter. Here is the output and trace of : [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit] Have a nice day.
My bad, I appear to have accidentally used a version of rust that wasn't up to date. The bug still occurs in the latest nightly, here's the backtrace: Sorry again about that.
It looks like is only checking for explicit negative impls at the very beginning, and not throughout the process. I should have a fix for this later today.
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0.

Related discussion:
text: ) -> Option<(ty::ParamEnv<'c>, ty::ParamEnv<'c>)> { let tcx = infcx.tcx; <del> let mut select = SelectionContext::new(&infcx); </del> <ins> let mut select = SelectionContext::with_negative(&infcx, true); </ins> let mut already_visited = FxHashSet::default(); let mut predicates = VecDeque::new();
Code change:
Hi, I noticed a weird internal error using . The smallest example I could make to reproduce the bug is an basic library project () whose contains: , , and all work fine; and as mentioned in the code, the place where is declared seems to matter. Here is the output and trace of : [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit] Have a nice day.
My bad, I appear to have accidentally used a version of rust that wasn't up to date. The bug still occurs in the latest nightly, here's the backtrace: Sorry again about that.
It looks like is only checking for explicit negative impls at the very beginning, and not throughout the process. I should have a fix for this later today.
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0.

Related discussion:
text: match &result { &Ok(Some(ref vtable)) => { <ins> // If we see an explicit negative impl (e.g. 'impl !Send for MyStruct'), // we immediately bail out, since it's impossible for us to continue. match vtable { Vtable::VtableImpl(VtableImplData { impl_def_id, .. }) => { // Blame tidy for the weird bracket placement if infcx.tcx.impl_polarity(*impl_def_id) == hir::ImplPolarity::Negative { debug!("evaluate_nested_obligations: Found explicit negative impl {:?}, bailing out", impl_def_id); return None; } }, _ => {} } </ins> let obligations = vtable.clone().nested_obligations().into_iter(); if !self.evaluate_nested_obligations(
Code change:
Hi, I noticed a weird internal error using . The smallest example I could make to reproduce the bug is an basic library project () whose contains: , , and all work fine; and as mentioned in the code, the place where is declared seems to matter. Here is the output and trace of : [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit] Have a nice day.
My bad, I appear to have accidentally used a version of rust that wasn't up to date. The bug still occurs in the latest nightly, here's the backtrace: Sorry again about that.
It looks like is only checking for explicit negative impls at the very beginning, and not throughout the process. I should have a fix for this later today.
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0.

Related discussion:
text: <ins> // Copyright 2018 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(optin_builtin_traits)] // @has issue_55321/struct.A.html // @has - '//*[@id="implementations-list"]/*[@class="impl"]//*/code' "impl !Send for A" // @has - '//*[@id="implementations-list"]/*[@class="impl"]//*/code' "impl !Sync for A" pub struct A(); impl !Send for A {} impl !Sync for A {} // @has issue_55321/struct.B.html // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<T> !Send for  // B<T>" // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<T> !Sync for  // B<T>" pub struct B<T: ?Sized>(A, Box<T>); </ins>
Code change:
We're incorrectly suggesting wrapping with when it won't help: It should be suggesting using using instead.
Duplicate of . Let me commit to submitting a fix for this on (or, less likely, before) Sunday the twenty-eighth (hopefully preserving the -wrapping suggestion in the cases where it is correct, but if we have to scrap the whole suggestion, we will; false-positives are pretty bad)

Related discussion:
text: err.span_label(arm_span, msg); } } <del> hir::MatchSource::TryDesugar => { // Issue #51632 if let Ok(try_snippet) = self.tcx.sess.source_map().span_to_snippet(arm_span) { err.span_suggestion_with_applicability( arm_span, "try wrapping with a success variant", format!("Ok({})", try_snippet), Applicability::MachineApplicable, ); } } </del> <ins> hir::MatchSource::TryDesugar => {} </ins> _ => { let msg = "match arm with an incompatible type"; if self.tcx.sess.source_map().is_multiline(arm_span) {
Code change:
We're incorrectly suggesting wrapping with when it won't help: It should be suggesting using using instead.
Duplicate of . Let me commit to submitting a fix for this on (or, less likely, before) Sunday the twenty-eighth (hopefully preserving the -wrapping suggestion in the cases where it is correct, but if we have to scrap the whole suggestion, we will; false-positives are pretty bad)

Related discussion:
text: <del> // Copyright 2018 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. // run-rustfix #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> { Ok(1) } fn forbidden_narratives() -> Result<isize, ()> { Ok(missing_discourses()?) //~^ ERROR try expression alternatives have incompatible types //~| HELP try wrapping with a success variant } fn main() {} </del>
Code change:
We're incorrectly suggesting wrapping with when it won't help: It should be suggesting using using instead.
Duplicate of . Let me commit to submitting a fix for this on (or, less likely, before) Sunday the twenty-eighth (hopefully preserving the -wrapping suggestion in the cases where it is correct, but if we have to scrap the whole suggestion, we will; false-positives are pretty bad)

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> // run-rustfix </del> #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> {
Code change:
We're incorrectly suggesting wrapping with when it won't help: It should be suggesting using using instead.
Duplicate of . Let me commit to submitting a fix for this on (or, less likely, before) Sunday the twenty-eighth (hopefully preserving the -wrapping suggestion in the cases where it is correct, but if we have to scrap the whole suggestion, we will; false-positives are pretty bad)

Related discussion:
text: fn forbidden_narratives() -> Result<isize, ()> { missing_discourses()? //~^ ERROR try expression alternatives have incompatible types <del> //~| HELP try wrapping with a success variant </del> } fn main() {}
Code change:
We're incorrectly suggesting wrapping with when it won't help: It should be suggesting using using instead.
Duplicate of . Let me commit to submitting a fix for this on (or, less likely, before) Sunday the twenty-eighth (hopefully preserving the -wrapping suggestion in the cases where it is correct, but if we have to scrap the whole suggestion, we will; false-positives are pretty bad)

Related discussion:
text: error[E0308]: try expression alternatives have incompatible types <del> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:20:5 </del> <ins> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:18:5 </ins> | LL |     missing_discourses()? <del> |     ^^^^^^^^^^^^^^^^^^^^^ |     | |     expected enum `std::result::Result`, found isize |     help: try wrapping with a success variant: `Ok(missing_discourses()?)` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found isize </ins> | = note: expected type `std::result::Result<isize, ()>` found type `isize`
Code change:
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out. This example: causes an ICE on rustc 1.31.0-nightly ( 2018-10-25) This is the error I'm getting, backtrace included:
Okay, the good news here is that I only see this ICE with ; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this .
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic. Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code). And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix. But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.

Related discussion:
text: let mir_node_id = tcx.hir.as_local_node_id(mir_def_id).expect("non-local mir"); <del> let (return_span, mir_description) = if let hir::ExprKind::Closure(_, _, _, span, gen_move) = tcx.hir.expect_expr(mir_node_id).node { ( tcx.sess.source_map().end_point(span), if gen_move.is_some() { " of generator" } else { " of closure" }, ) } else { // unreachable? (mir.span, "") }; </del> <ins> let (return_span, mir_description) = match tcx.hir.get(mir_node_id) { hir::Node::Expr(hir::Expr { node: hir::ExprKind::Closure(_, _, _, span, gen_move), .. }) => ( tcx.sess.source_map().end_point(*span), if gen_move.is_some() { " of generator" } else { " of closure" }, ), hir::Node::ImplItem(hir::ImplItem { node: hir::ImplItemKind::Method(method_sig, _), .. }) => (method_sig.decl.output.span(), ""), _ => (mir.span, ""), }; </ins> Some(RegionName { // This counter value will already have been used, so this function will increment it
Code change:
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out. This example: causes an ICE on rustc 1.31.0-nightly ( 2018-10-25) This is the error I'm getting, backtrace included:
Okay, the good news here is that I only see this ICE with ; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this .
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic. Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code). And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix. But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.

Related discussion:
text: <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. #![feature(nll)] struct Bar; struct Foo<'s> { bar: &'s mut Bar, } impl Foo<'_> { fn new(bar: &mut Bar) -> Self { Foo { bar } } } fn main() { } </ins>
Code change:
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out. This example: causes an ICE on rustc 1.31.0-nightly ( 2018-10-25) This is the error I'm getting, backtrace included:
Okay, the good news here is that I only see this ICE with ; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this .
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic. Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code). And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix. But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.

Related discussion:
text: <ins> error: unsatisfied lifetime constraints --> $DIR/issue-55394.rs:21:9 | LL |     fn new(bar: &mut Bar) -> Self { |                 -            ---- return type is Foo<'2> |                 | |                 let's call the lifetime of this reference `'1` LL |         Foo { bar } |         ^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2` error: aborting due to previous error </ins>
Code change:
review comments:
I've looked into this some - NLL misses three errors, all of the form u.yu.x`. In each of the three cases, there is a mutable borrow of some field of the union and then a shared borrow of some other field immediately following. The issue seems to be that the mutable borrow is killed straight away as it isn't used later - therefore not causing a conflict with the shared borrow. I'm inclined to think that this is fine - and that NLL is correct in having less errors here. However, we might want to update the test to use the first mutable borrow for each case in order to make the error happen and demonstrate the diagnostic - if this is the case, I've that we can open a PR for that will update the test. cc
I'm inclined to agree that this is an instance where the test was not robust and that we need to add uses of those first mutable borrows.
I've submitted a PR () that makes the test more robust.

Related discussion:
text: /// implicit closure bindings. It is needed when the closure is /// borrowing or mutating a mutable referent, e.g.: /// <del> ///    let x: &mut isize = ...; ///    let y = || *x += 5; </del> <ins> ///     let x: &mut isize = ...; ///     let y = || *x += 5; </ins> /// /// If we were to try to translate this closure into a more explicit /// form, we'd encounter an error with the code as written: /// <del> ///    struct Env { x: & &mut isize } ///    let x: &mut isize = ...; ///    let y = (&mut Env { &x }, fn_ptr);  // Closure is pair of env and fn ///    fn fn_ptr(env: &mut Env) { **env.x += 5; } </del> <ins> ///     struct Env { x: & &mut isize } ///     let x: &mut isize = ...; ///     let y = (&mut Env { &x }, fn_ptr);  // Closure is pair of env and fn ///     fn fn_ptr(env: &mut Env) { **env.x += 5; } </ins> /// /// This is then illegal because you cannot mutate an `&mut` found /// in an aliasable location. To solve, you'd have to translate with /// an `&mut` borrow: /// <del> ///    struct Env { x: & &mut isize } ///    let x: &mut isize = ...; ///    let y = (&mut Env { &mut x }, fn_ptr); // changed from &x to &mut x ///    fn fn_ptr(env: &mut Env) { **env.x += 5; } </del> <ins> ///     struct Env { x: & &mut isize } ///     let x: &mut isize = ...; ///     let y = (&mut Env { &mut x }, fn_ptr); // changed from &x to &mut x ///     fn fn_ptr(env: &mut Env) { **env.x += 5; } </ins> /// /// Now the assignment to `**env.x` is legal, but creating a /// mutable pointer to `x` is not because `x` is not mutable. We
Code change:
review comments:
I've looked into this some - NLL misses three errors, all of the form u.yu.x`. In each of the three cases, there is a mutable borrow of some field of the union and then a shared borrow of some other field immediately following. The issue seems to be that the mutable borrow is killed straight away as it isn't used later - therefore not causing a conflict with the shared borrow. I'm inclined to think that this is fine - and that NLL is correct in having less errors here. However, we might want to update the test to use the first mutable borrow for each case in order to make the error happen and demonstrate the diagnostic - if this is the case, I've that we can open a PR for that will update the test. cc
I'm inclined to agree that this is an instance where the test was not robust and that we need to add uses of those first mutable borrows.
I've submitted a PR () that makes the test more robust.

Related discussion:
text: y: Box<Vec<u8>>, } <ins> fn use_borrow<T>(_: &T) {} </ins> unsafe fn parent_sibling_borrow() { let mut u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = &mut u.x.0; <del> let a = &u.y; //~ ERROR cannot borrow `u.y` </del> <ins> let b = &u.y; //~ ERROR cannot borrow `u.y` use_borrow(a); </ins> } unsafe fn parent_sibling_move() { let u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = u.x.0; <del> let a = u.y; //~ ERROR use of moved value: `u.y` </del> <ins> let b = u.y; //~ ERROR use of moved value: `u.y` </ins> } unsafe fn grandparent_sibling_borrow() { let mut u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = &mut (u.x.0).0; <del> let a = &u.y; //~ ERROR cannot borrow `u.y` </del> <ins> let b = &u.y; //~ ERROR cannot borrow `u.y` use_borrow(a); </ins> } unsafe fn grandparent_sibling_move() { let u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = (u.x.0).0; <del> let a = u.y; //~ ERROR use of moved value: `u.y` </del> <ins> let b = u.y; //~ ERROR use of moved value: `u.y` </ins> } unsafe fn deref_sibling_borrow() { let mut u = U { y: Box::default() }; let a = &mut *u.y; <del> let a = &u.x; //~ ERROR cannot borrow `u` (via `u.x`) </del> <ins> let b = &u.x; //~ ERROR cannot borrow `u` (via `u.x`) use_borrow(a); </ins> } unsafe fn deref_sibling_move() { let u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = *u.y; <del> let a = u.x; //~ ERROR use of moved value: `u.x` </del> <ins> let b = u.x; //~ ERROR use of moved value: `u.x` </ins> }