jiebi/CodeConvo huggingface dataset:
Change:
The issue title says it all really. std::mem::needs_drop is a function that doesn't change from call to call once monomorphized, so it should be a const function. EDIT: This has been implemented and it is waiting for stabilization now.
blocked on
is this still blocked? If not I would like to help out with it. :+1:
Should be fine to add behind a feature gate. The steps are basically the same as and (but you can do them in a single PR)
It might be nice to keeps this issue open until is stabilized.
I know it's only been a few months since this was implemented, but I'm curious what the road to stabilization is. I've been using this in my objrs crate and it's been working great. At what point should I send a stabilization PR?
I've nominated this for libs team to take a look at and decide whether or not to propose FCP for stabilization.
I've T-lang since they'd better know if this bit of const-fn-ness is ready to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
Seems unobjectionable (assuming the implementation is up to snuff...? cc
Yea, the impl has baked in miri since long before it was in const eval. I also rechecked it and I see no reason not to stabilize.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

Discussion:
/// ``` #[inline] #[stable(feature = "needs_drop", since = "1.21.0")] <del> #[rustc_const_unstable(feature = "const_needs_drop")] </del> pub const fn needs_drop<T>() -> bool { intrinsics::needs_drop::<T>() }

<del> #![feature(const_needs_drop)] </del> use std::mem; struct Trivial(u8, f32);
Change:
The and traits contain convenience methods and wrapping and . This issue tracks addition of similar methods to trait's and . This is implemented in .
if this is a tracking issue, maybe it should have the label
We should eventually add similar methods to .
I know nothing about developing on Windows so I can't do it myself but I guess a PR would be accepted. Can we stabilize this? Is there anything that still needs to be done?
Seems reasonable to me! 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] [ ] 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.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
What's the next step? Should I make a PR to stabilize? Sorry but I don't fully understand how things work yet.
indeed that should be all that's necessary! If you'd like to make the PR you're also more than welcome to do so!

Discussion:
/// # Examples /// /// ```no_run <del> /// #![feature(rw_exact_all_at)] </del> /// use std::io; /// use std::fs::File; /// use std::os::unix::prelude::FileExt;

///     Ok(()) /// } /// ``` <del> #[unstable(feature = "rw_exact_all_at", issue = "51984")] </del> <ins> #[stable(feature = "rw_exact_all_at", since = "1.33.0")] </ins> fn read_exact_at(&self, mut buf: &mut [u8], mut offset: u64) -> io::Result<()> { while !buf.is_empty() { match self.read_at(buf, offset) {

/// # Examples /// /// ```no_run <del> /// #![feature(rw_exact_all_at)] </del> /// use std::fs::File; /// use std::io; /// use std::os::unix::prelude::FileExt;

///     Ok(()) /// } /// ``` <del> #[unstable(feature = "rw_exact_all_at", issue = "51984")] </del> <ins> #[stable(feature = "rw_exact_all_at", since = "1.33.0")] </ins> fn write_all_at(&self, mut buf: &[u8], mut offset: u64) -> io::Result<()> { while !buf.is_empty() { match self.write_at(buf, offset) {
Change:
I've reported an for this but I want to track it on our side as well to track pulling in the fix. The gist of the issue is that this code: will execute successfully when compiled at O0: And it should certainly panic! I'm currently hoping we can fix this upstream in LLVM before we need to work around it in rustc!

Discussion:
<del> Subproject commit 1c817c7a0c828b8fc8e8e462afbe5db41c7052d1 </del> <ins> Subproject commit 509f29ac17874394acf4d49d6bae3cd93c652aa1 </ins>
Change:
suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.

Discussion:
let node_id = scope.node_id(self.tcx, &self.region_scope_tree); match self.tcx.hir.find(node_id) { Some(hir_map::NodeStmt(_)) => { <del> db.note("consider using a `let` binding to increase its lifetime"); </del> <ins> if *sub_scope != ty::ReStatic { db.note("consider using a `let` binding to increase its lifetime"); } </ins> } _ => {} }

<ins> error[E0597]: borrowed value does not live long enough --> $DIR/issue-52049.rs:16:10 | LL |     foo(&unpromotable(5u32)); |          ^^^^^^^^^^^^^^^^^^ temporary value does not live long enough LL | } | - temporary value only lives until here | = note: borrowed value must be valid for the static lifetime... error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

<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. fn foo(_: &'static u32) {} fn unpromotable<T>(t: T) -> T { t } fn main() { foo(&unpromotable(5u32)); } //~^^ ERROR borrowed value does not live long enough </ins>

<ins> error[E0597]: borrowed value does not live long enough --> $DIR/issue-52049.rs:16:10 | LL |     foo(&unpromotable(5u32)); |          ^^^^^^^^^^^^^^^^^^ - temporary value only lives until here |          | |          temporary value does not live long enough | = note: borrowed value must be valid for the static lifetime... error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>
Change:
since , Rust failed to package properly when LLVM is configured as external dependency (with explicit in ) the error is because buildrust tries to copy: to . But as LLVM was external, the directory is empty. I think there is two possibilities: doesn't package llvm-tools componment if LLVM is external package it, but uses the right directory I will make a PR if someone told me the direction to take.
I think we should probably package it, cc
I'd personally err on the side of skipping it, if we try to package it we're gonna have to deal with a whole array of local installs and filenames, and it's not actually used anyway

Discussion:
let target = self.target; assert!(builder.config.extended); <ins> /* run only if llvm-config isn't used */ if let Some(config) = builder.config.target_config.get(&target) { if let Some(ref _s) = config.llvm_config { builder.info(&format!("Skipping LlvmTools stage{} ({}): external LLVM", stage, target)); return None; } } </ins> builder.info(&format!("Dist LlvmTools stage{} ({})", stage, target)); let src = builder.src.join("src/llvm"); let name = pkgname(builder, "llvm-tools");
Change:
Works on beta, but not on nightly. This breaks miri.
That was probably me. I'll have a look

Discussion:
fn ty(&mut self) -> &mut Self { let ty = self.ev.tcx.type_of(self.item_def_id); <del> self.walk_ty(ty) } fn walk_ty(&mut self, ty: Ty<'tcx>) -> &mut Self { </del> ty.visit_with(self); if let ty::TyFnDef(def_id, _) = ty.sty { if def_id == self.item_def_id {

// where `X` is the `impl Iterator<Item=T>` itself, // stored in `predicates_of`, not in the `Ty` itself. <del> self.check(item.id, self.inner_visibility).predicates(); </del> <ins> self.check(item.id, item_visibility).predicates(); </ins> } // Subitems of these items have inherited publicity hir::ItemConst(..) | hir::ItemStatic(..) | hir::ItemFn(..) |

1 } <ins> fn other_internal_fn() -> u32 { 1 } </ins> // See #40839 pub fn return_closure_accessing_internal_fn() -> impl Fn() -> u32 { || {

} pub fn return_internal_fn() -> impl Fn() -> u32 { <del> some_internal_fn </del> <ins> other_internal_fn </ins> }

<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. // compile-pass #![deny(warnings)] use std::collections::BTreeMap; pub struct RangeMap { map: BTreeMap<Range, u8>, } #[derive(Eq, PartialEq, Ord, PartialOrd)] struct Range; impl RangeMap { fn iter_with_range<'a>(&'a self) -> impl Iterator<Item = (&'a Range, &'a u8)> + 'a { self.map.range(Range..Range) } pub fn iter<'a>(&'a self) -> impl Iterator<Item = &'a u8> + 'a { self.iter_with_range().map(|(_, data)| data) } } fn main() {} </ins>
Change:
Consider the following program. When compiled with with the 6 July nightly, we get this error message: But if we take the suggestion literally (and continue using the 2018 edition), is : A pull request is forthcoming.

Discussion:
if ident.name == lookup_name && ns == namespace { if filter_fn(name_binding.def()) { // create the path <del> let mut segms = path_segments.clone(); </del> <ins> let mut segms = if self.session.rust_2018() && !in_module_is_extern { // crate-local absolute paths start with `crate::` in edition 2018 // FIXME: may also be stabilized for Rust 2015 (Issues #45477, #44660) let mut full_segms = vec![ ast::PathSegment::from_ident(keywords::Crate.ident()) ]; full_segms.extend(path_segments.clone()); full_segms } else { path_segments.clone() }; </ins> segms.push(ast::PathSegment::from_ident(ident)); let path = Path { span: name_binding.span,

<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. // compile-flags: --edition 2018 // The local `use` suggestion should start with `crate::` (but the // standard-library suggestions should not, obviously). mod plumbing { pub struct Drain; } fn main() { let _d = Drain {}; //~^ ERROR cannot find struct, variant or union type `Drain` in this scope } </ins>

<ins> error[E0422]: cannot find struct, variant or union type `Drain` in this scope --> $DIR/issue-52202-use-suggestions.rs:21:14 | LL |     let _d = Drain {}; |              ^^^^^ not found in this scope help: possible candidates are found in other modules, you can import them into scope | LL | use crate::plumbing::Drain; | LL | use std::collections::binary_heap::Drain; | LL | use std::collections::hash_map::Drain; | LL | use std::collections::hash_set::Drain; | and 3 other candidates error: aborting due to previous error For more information about this error, try `rustc --explain E0422`. </ins>
Change:
This lets you get a mutable reference to an immutable value under a specific case. Code: From what I can tell, the tuple and at least two depths of Enums are necessary, along with an on the right side. There's probably other variations, but that seems to work well enough. Expected output would be a compile error, instead output is This works on both stable and nightly
would fix this as well?
Fixed by . Off: I wonder why we can't ship nll yet. It would solve so many issues right now, because of the match ergonomics sigh Match ergonomics produces roughly 10% of all errors/unsoundness/ICEs atm (at least it feels like this)
Yes correctly fixed this issue.

Discussion:
<ins> error[E0596]: cannot borrow data in a `&` reference as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

<ins> // issue-52240: Can turn immutable into mut with `ref mut` enum Foo { Bar(i32), } fn main() { let arr = vec!(Foo::Bar(0)); if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { //~^ ERROR cannot borrow field of immutable binding as mutable *val = 9001; } match arr[0] { Foo::Bar(ref s) => println!("{}", s) } } </ins>

<ins> error[E0596]: cannot borrow field of immutable binding as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot mutably borrow field of immutable binding error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

<ins> // issue-54966: ICE returning an unknown type with impl FnMut fn generate_duration() -> Oper<impl FnMut()> {} //~^ ERROR cannot find type `Oper` in this scope fn main() {} </ins>

<ins> error[E0412]: cannot find type `Oper` in this scope --> $DIR/issue-54966.rs:3:27 | LL | fn generate_duration() -> Oper<impl FnMut()> {} |                           ^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>
Change:
Since the check no longer panics on failure. It is obvious in the commit that the invocation is removed from the check, and no other changes are made in the function to remedy it. It can be verified by adding a new pretty test case like: The resulting pretty printed file is slightly different, the comparison fails and the message is logged, but the test continues into the type check, which fails for a different reason and then panics. If you fix the type check (by adding the module and fn main) then the whole test passes and the error message is swallowed even though the source comparison is still not matching.

Discussion:
#[prelude_import] use std::prelude::v1::*; #[macro_use] <del> extern crate std as std; </del> <ins> extern crate std; </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.

macro_rules! negative(( $ e : expr ) => { $ e < 0 }); fn main() { (1 as i32) < 0; }

#[prelude_import] use std::prelude::v1::*; #[macro_use] <del> extern crate std as std; </del> <ins> extern crate std; </ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT.

fn compare_source(&self, expected: &str, actual: &str) { if expected != actual { <del> self.error("pretty-printed source does not match expected source"); println!( "n </del> <ins> self.fatal(&format!( "pretty-printed source does not match expected sourcen </ins> expected:n ------------------------------------------n {}n

{}n ------------------------------------------n n", <del> expected, actual </del> <ins> expected, actual) </ins> ); } }
Change:
In particular, we should specify and document what exactly zip does when its first child terminates. Currently, as soon as returns None, it short-circuits execution without calling . This could lead to some potential surprising behavior: To be clear, I'm not saying this behavior is bad; just that it should be more explicitly documented. This will allow developers to more confidently build abstractions on top of Zip, knowing exactly what it does with the underlying iterator.
In this case, I would even day that the documentation is misleading.
This was addressed in , which will hit stable Rust on August 2nd.
That's close, but I'd propose a further change, to emphasize that zip always does , and that if returns None, it short circuits and returns None immediately, without calling
Opened a pull request for this:

Discussion:
/// /// In other words, it zips two iterators together, into a single one. /// <del> /// If either iterator returns [`None`], [`next`] will return [`None`]. </del> <ins> /// If either iterator returns [`None`], [`next`] from the zipped iterator /// will return [`None`]. If the first iterator returns [`None`], `zip` will /// short-circuit and `next` will not be called on the second iterator. </ins> /// /// # Examples ///
Change:
I'm getting when trying to compile on rustc 1.29.0-nightly ( 2018-07-10) - . This seems to happen when I a reference type and don't specify the exact type in .
We don't generate an error message for the region here and panic instead. Here is the message that should be printed with a placeholder: Should be allowed for impl Trait? cc
Why are we capturing here?
There isn't any in the type. There's some which replaces regions with which is closure related. I'm not sure what is going on there, but perhaps generators should be treated the same? cc
Oh, all of that code is for exporting concrete types from inference results, which needs to "connect up" lifetimes inside the inferred concrete type with lifetime parameters.
I think the problem is that the of the generator ends up being , because nothing is constraining it to be anything else. I wonder why this isn't occurring with closures.
This doesn't occur with closures because regionck forces the return type of the closure to outlive the closure's call scope, which prevents from being inferred.
I think that the correct way to fix it would be to that goes in the wrong direction.
The requirement we want is that that "implicit" makes sense. That requires that the projections in that impl are alive as long as is alive (we don't consider that as a "well-formed" requirement, but the "projection outlives" rules assume that). That does not hold if regions in the projections can be inferred to - we need to be checking that.
I think that in closures, (from the fix to ) is serving that rule with lexical lifetimes - not sure what is checking that with NLL.
This can, in fact, be used as a soundness hole (assuming you can call ):
Note: the version above is fixed by NLL. need to check whether fix is tight.
any ideas on how to check whether the "fix is tight"? Otherwise perhaps this issue can be closed?

Discussion:
<ins> // check-pass #![feature(generators, generator_trait)] use std::ops::Generator; pub fn example() -> impl Generator { || yield &1 } fn main() {} </ins>
Change:
Stack trace: Examples:
In we build with LLVM assertions enabled, but there is no messages from the log, meaning the segfault is not caused by broken assertions.
When setting opt-level=3 I believe that also changes the C/C++ code's optimization level, so this may be a but in clang's O3 optimization passes as well (and may in theory be fixable by compiling C++ code with O2)
I inspected generated CMake files and LLVM is built with nowadays but Rust is still using . How can I see if reapplying works without possibly breaking CI?
mentions LLVM7.0. Rust recently . So is this still an issue?

Discussion:
"obj", ] <del> # Curiously, LLVM 7.0 will segfault if compiled with opt-level=3 # See issue https://github.com/rust-lang/rust/issues/52378 [profile.release] opt-level = 2 [profile.bench] opt-level = 2 </del> # These options are controlled from our rustc wrapper script, so turn them off # here and have them controlled elsewhere. [profile.dev]

/// Returns `true` as long as there are more things to do. /// /// This is used by [priroda](https://github.com/oli-obk/priroda) <ins> /// /// This is marked `#inline(always)` to work around adverserial codegen when `opt-level = 3` #[inline(always)] </ins> pub fn step(&mut self) -> InterpResult<'tcx, bool> { if self.stack.is_empty() { return Ok(false);

all: $(RUSTC) foo.rs -C lto -O --target wasm32-unknown-unknown wc -c < $(TMPDIR)/foo.wasm <del> [ "`wc -c < $(TMPDIR)/foo.wasm`" -lt "20500" ] </del> <ins> [ "`wc -c < $(TMPDIR)/foo.wasm`" -lt "25000" ] </ins> else all: endif
Change:
Consider this test: (note the ) when this fails, you get This is because it triggers . can we make this better somehow? is not super helpful at learning why this test failed.
Hmm, the trait is super-unstable, so maybe it's be worth adding a purpose-built method for this? Like But then the impl could override it to show something better...
What if it printed something like this? Or simply EDIT: Nevermind the first suggestion, that seems like it couldn't work because sort of couples printing the message with returning a code.

Discussion:
/// test is considered a failure. By default, invokes `report()` /// and checks for a `0` result. pub fn assert_test_result<T: Termination>(result: T) { <del> assert_eq!(result.report(), 0); </del> <ins> let code = result.report(); assert_eq!( code, 0, "the test returned a termination value with a non-zero status code ({})  which indicates a failure", code ); </ins> } #[derive(Copy, Clone, Debug)]