jiebi/CodeConvo huggingface dataset:
Change:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? 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] [ ] 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.
: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.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.

Discussion:
#![feature(unboxed_closures)] #![feature(generator_trait)] #![feature(fn_traits)] <del> #![feature(int_bits_const)] </del> #![feature(min_specialization)] #![feature(auto_traits)] #![feature(nll)]

#![feature(min_specialization)] #![feature(vec_spare_capacity)] #![feature(core_intrinsics)] <del> #![feature(int_bits_const)] </del> #![feature(maybe_uninit_slice)] #![feature(new_uninit)] #![cfg_attr(test, feature(test))]

<del> #![feature(int_bits_const)] </del> #![feature(maybe_uninit_slice)] #![feature(maybe_uninit_uninit_array)]

#![feature(fn_traits)] #![feature(fundamental)] #![feature(inplace_iteration)] <del> #![feature(int_bits_const)] </del> #![feature(lang_items)] #![feature(layout_for_ptr)] #![feature(maybe_uninit_ref)]

#![feature(binary_heap_retain)] #![feature(inplace_iteration)] #![feature(iter_map_while)] <del> #![feature(int_bits_const)] </del> #![feature(vecdeque_binary_search)] #![feature(slice_group_by)]

/// # Examples /// /// ``` <del> /// #![feature(int_bits_const)] </del> #[doc = concat!("assert_eq!(", stringify!($SelfT), "::BITS, ", stringify!($BITS), ");")] /// ``` <del> #[unstable(feature = "int_bits_const", issue = "76904")] </del> <ins> #[stable(feature = "int_bits_const", since = "1.51.0")] </ins> pub const BITS: u32 = $BITS; /// Converts a string slice in a given base to an integer.

#![feature(partition_point)] #![feature(once_cell)] #![feature(unsafe_block_in_unsafe_fn)] <del> #![feature(int_bits_const)] </del> #![feature(nonzero_leading_trailing_zeros)] #![feature(const_option)] #![feature(integer_atomics)]

issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/" )] #![feature(core_intrinsics)] <del> #![feature(int_bits_const)] </del> #![feature(lang_items)] #![feature(nll)] #![feature(panic_unwind)]
Change:
Tracking Issue for as introduced by Api: - The first one is now gated behind . The other two are not available yet, as trait implementations cannot be unstable. These should be (uncommented) when this feature is stabilized.
Seems there's no blocker, could I ask you to kick off FCP to stabilize it?
cc If it's reasonable, it'd be great if someone starts FCP :)
Do we have any confirmation of usage in the ecosystem? I don't see any problem with the method as designed, but can we confirm that it's being used?
Oh sorry, I don't have the real world use case, unfortunately. I just thought this is straightforward and makes the conversion around easier. And we cannot make any use that requires because it's hidden until we stabilize the feature.
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] 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.
: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:
/// # Examples /// /// ``` <del> /// #![feature(string_drain_as_str)] </del> /// let mut s = String::from("abc"); /// let mut drain = s.drain(..); /// assert_eq!(drain.as_str(), "abc"); /// let _ = drain.next().unwrap(); /// assert_eq!(drain.as_str(), "bc"); /// ``` <del> #[unstable(feature = "string_drain_as_str", issue = "76905")] // Note: uncomment AsRef impls below when stabilizing. </del> <ins> #[stable(feature = "string_drain_as_str", since = "1.55.0")] </ins> pub fn as_str(&self) -> &str { self.iter.as_str() } } <del> // Uncomment when stabilizing `string_drain_as_str`. // #[unstable(feature = "string_drain_as_str", issue = "76905")] // impl<'a> AsRef<str> for Drain<'a> { //     fn as_ref(&self) -> &str { //         self.as_str() //     } // } // // #[unstable(feature = "string_drain_as_str", issue = "76905")] // impl<'a> AsRef<[u8]> for Drain<'a> { //     fn as_ref(&self) -> &[u8] { //         self.as_str().as_bytes() //     } // } </del> <ins> #[stable(feature = "string_drain_as_str", since = "1.55.0")] impl<'a> AsRef<str> for Drain<'a> { fn as_ref(&self) -> &str { self.as_str() } } #[stable(feature = "string_drain_as_str", since = "1.55.0")] impl<'a> AsRef<[u8]> for Drain<'a> { fn as_ref(&self) -> &[u8] { self.as_str().as_bytes() } } </ins> #[stable(feature = "drain", since = "1.6.0")] impl Iterator for Drain<'_> {
Change:
<!-- 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. --This code compiles correctly: However, this code does not: The only change was effectively replacing with . My understanding is that these are supposed to be equivalent as it is . The exact compile error is as follows: The error also occurs on the Nightly compiler.
We currently do not normalize projections if they contain unbound variables (stuff which is introduced using a qualifier, in your example). This means that we never actually see that is equal to . cc but I don't think we can do much about cases like this for now.
Is this the same underlying issue as and possibly
I think has a similar cause. is caused by something different, probably related to
Using trait objects instead of has the same issue
Came up with another interesting version. This will fail to typecheck: Replacing the header of foo with this will successfully typecheck: Might be useful for diffing.
Fixed by . Not going to close this because this is a simple example that didn't ICE, but still failed to compile.

Discussion:
<ins> // check-pass fn foo<T>(t: T) -> usize where for<'a> &'a T: IntoIterator, for<'a> <&'a T as IntoIterator>::IntoIter: ExactSizeIterator, { t.into_iter().len() } fn main() { foo::<Vec<u32>>(vec![]); } </ins>

<ins> // check-pass use std::ops::Deref; struct Data { boxed: Box<&'static i32> } impl Data { fn use_data(&self, user: impl for <'a> FnOnce(<Box<&'a i32> as Deref>::Target)) { user(*self.boxed) } } fn main() {} </ins>
Change:
The feature gate for the issue is . It makes usable in const contexts. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implemented in [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --<!-- Include a list of all the PRs that were involved in implementing the feature. --
Do you want to stabilize the feature? I was asked to use in const context here:
WG-const-eval has confirmed that this is fine: Feel free to send in a PR flipping the stability attribute. It's an unstable intrinsic so we aren't really committing to anything.

Discussion:
/// own, or if it does not enable any significant optimizations. /// /// This intrinsic does not have a stable counterpart. <del> #[rustc_const_unstable(feature = "const_assume", issue = "76972")] </del> <ins> #[rustc_const_stable(feature = "const_assume", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_nounwind] pub fn assume(b: bool);

#![feature(const_arguments_as_str)] #![feature(const_array_from_ref)] #![feature(const_array_into_iter_constructors)] <del> #![feature(const_assume)] </del> #![feature(const_bigint_helper_methods)] #![feature(const_black_box)] #![feature(const_caller_location)]

#![feature(bigint_helper_methods)] #![feature(cell_update)] #![feature(const_align_offset)] <del> #![feature(const_assume)] </del> #![feature(const_align_of_val_raw)] #![feature(const_black_box)] #![feature(const_caller_location)]
Change:
It seems like this lint should fire if you have an declaration without docs on it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-lint T-compiler C-bug
I think I know what causes this and will write a more general fix here this week. claim
the fix wasn't more general but it's a fix none the less

Discussion:
); } <ins> fn check_foreign_item(&mut self, cx: &LateContext<'_>, foreign_item: &hir::ForeignItem<'_>) { let def_id = cx.tcx.hir().local_def_id(foreign_item.hir_id); let (article, desc) = cx.tcx.article_and_description(def_id.to_def_id()); self.check_missing_docs_attrs( cx, Some(foreign_item.hir_id), &foreign_item.attrs, foreign_item.span, article, desc, ); } </ins> fn check_struct_field(&mut self, cx: &LateContext<'_>, sf: &hir::StructField<'_>) { if !sf.is_positional() { self.check_missing_docs_attrs(

// injected intrinsics by the compiler. #![deny(missing_docs)] #![allow(dead_code)] <del> #![feature(associated_type_defaults)] </del> <ins> #![feature(associated_type_defaults, extern_types)] </ins> //! Some garbage docs for the crate here #![doc="More garbage"]

pub use internal_impl::globbed::*; } <ins> extern "C" { /// dox pub fn extern_fn_documented(f: f32) -> f32; pub fn extern_fn_undocumented(f: f32) -> f32; //~^ ERROR: missing documentation for a function /// dox pub static EXTERN_STATIC_DOCUMENTED: u8; pub static EXTERN_STATIC_UNDOCUMENTED: u8; //~^ ERROR: missing documentation for a static /// dox pub type ExternTyDocumented; pub type ExternTyUndocumented; //~^ ERROR: missing documentation for a foreign type } </ins> fn main() {}

LL |         pub fn also_undocumented1() {} |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 19 previous errors </del> <ins> error: missing documentation for a function --> $DIR/lint-missing-doc.rs:189:5 | LL |     pub fn extern_fn_undocumented(f: f32) -> f32; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: missing documentation for a static --> $DIR/lint-missing-doc.rs:194:5 | LL |     pub static EXTERN_STATIC_UNDOCUMENTED: u8; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: missing documentation for a foreign type --> $DIR/lint-missing-doc.rs:199:5 | LL |     pub type ExternTyUndocumented; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 22 previous errors </ins>
Change:
The PR CI runner currently does not seem to run clippy tests. Would be nice if it would. :) Cc
This had some unintended side-effects: in a rollup like that touches a clippy file, PR CI runs the "tools" builder, including Miri -- and then PR CI could fail because Miri is broken, even though the PR would land just fine as it is okay for Miri to be broken. (The PR did not update the Miri submodule.)

Discussion:
# Submodules pseudo-files inside git have the 160000 permissions, so when # those files are present in the diff a submodule was updated. echo "Executing the job since submodules are updated" <ins> elif git diff --name-only HEAD^ | grep --quiet src/tools/clippy; then # There is not an easy blanket search for subtrees. For now, manually list # clippy. echo "Executing the job since clippy subtree was updated" </ins> else echo "Not executing this job since no submodules were updated" ciCommandSetEnv SKIP_JOB 1
Change:
<!-- 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. --I tried this code: I expected to see this happen: code compiles in a reasonable amount of times or the slice gets elided entirely. Instead, this happened: code takes multiple minutes to compile/gets killed by the playground. <!-- 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. --: Also tested on playground stable and nightly.
The code compiled in about 6 seconds in Rust 1.29 and 1.30 : . Before that it had capacity error. After that it exceeded 15 seconds limit of godbolt. This is a but I cannot tag it.
It looks like this also works correctly on 1.31 stable as well:
Decided on as in the prioritization working group procedure.
Cc
Fixed in .

Discussion:
<ins> // build-pass fn main() { let _ = &[(); usize::MAX]; } </ins>
Change:
The following code compiles fine with nightly-2020-09-22 (and stable rustc since 1.10.0) but not nightly-2020-09-23. This is minimized from Mentioning , ,
Whoops, I didn't realize the trait itself was stable. Probably the PR should either be reverted or add a default implementation for .
Assigning P-critical as as part of the Prioritization Working Group procedure and removing I-prioritize.
is now broken on nightly as well:
I was under the impression that the traits were not intended to be implemented outside of which means this is really an issue with which shouldn't have implemented at all.  for example has had several methods to it since 1.0. Is there something different with or is this just that it was implemented by a popular crate?
The trait likely should have been , but I think sealed traits were not invented until after 1.0.0.
Can we retroactively seal ? It seems like we should, if we keep adding methods like in
Wouldn't that be a breaking change?
Yes, just like adding more methods to it (which has been done several times)
We could do a crater run to see if sealing it would break anything.
Well clearly it would - it would break async-std the same way broke async std. We need to get them not to use before we can change anything here.
My comment was in reference to sealing , not .

Discussion:
/// ``` #[stable(feature = "open_options_ext", since = "1.10.0")] fn custom_flags(&mut self, flags: i32) -> &mut Self; <del> /// Get the flags as [`libc::c_int`]. /// /// This method allows the reuse of the OpenOptions as flags argument for [`libc::open`]. /// /// [`libc::c_int`]: https://docs.rs/libc/*/libc/type.c_int.html /// [`libc::open`]: https://docs.rs/libc/*/libc/fn.open.html /// /// # Examples /// /// ```no_run /// # #![feature(rustc_private)] /// #![feature(open_options_ext_as_flags)] /// extern crate libc; /// use std::ffi::CString; /// use std::fs::OpenOptions; /// use std::os::unix::fs::OpenOptionsExt; /// /// let mut options = OpenOptions::new(); /// options.write(true).read(true); /// let file_name = CString::new("foo.txt").unwrap(); /// let file = unsafe { libc::open(file_name.as_c_str().as_ptr(), options.as_flags().unwrap()) }; /// ``` #[unstable(feature = "open_options_ext_as_flags", issue = "76801")] fn as_flags(&self) -> io::Result<libc::c_int>; </del> } #[stable(feature = "fs_ext", since = "1.1.0")]

self.as_inner_mut().custom_flags(flags); self } <del> fn as_flags(&self) -> io::Result<libc::c_int> { self.as_inner().as_flags() } </del> } /// Unix-specific extensions to [`fs::Metadata`].

self.mode = mode as mode_t; } <del> pub fn as_flags(&self) -> io::Result<c_int> { let access_mode = self.get_access_mode()?; let creation_mode = self.get_creation_mode()?; Ok(creation_mode | access_mode | self.custom_flags) } </del> fn get_access_mode(&self) -> io::Result<c_int> { match (self.read, self.write, self.append) { (true, false, false) => Ok(libc::O_RDONLY),
Change:
Assertion failed: ((NumParams == FTy-getNumParams() (FTy-isVarArg() && NumParams FTy-getNumParams())) && "Calling a function with bad signature!"), function init, file , line 187.
Should be rejected by the typechecker.

Discussion:
<del> Subproject commit fc96aa036884183ddc68d2659f4633e6f138b4e0 </del> <ins> Subproject commit 341c96afd331195beeb001436535c1feb479ff9d </ins>
Change:
Tracking issue for which adds the following methods [x] Implementation: [ ] FCP [ ] Stabilization PR
Nvm, it's a typo in the issue description, the actual method is named . What is blocking stabilization, it seems like there aren't any open questions/controversies. Shall I make a stabilization PR?
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] [ ] 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.
: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.
Has anyone proposed to stabilize these? Could I just open a PR to start that? :)
I've proposed. In fact, they were already stabilized :)
Since and has been stablized, could we now add , and to libcore? These impls should be easy to implement (just one-liners) and ergonomic to use.
Feel free to create a pull request! I would imagine it would be accepted.
Adding could conflict with downstream . Similarly, since and are "fundamental" and behave like their pointee for coherence purposes, downstream impls of etc are also currently allowed, such that adding would also conflict. Adding another candidate for also was pointed out as possibly being .

Discussion:
pub use iter::IntoIter; /// Converts a reference to `T` into a reference to an array of length 1 (without copying). <del> #[unstable(feature = "array_from_ref", issue = "77101")] </del> <ins> #[stable(feature = "array_from_ref", since = "1.53.0")] </ins> pub fn from_ref<T>(s: &T) -> &[T; 1] { // SAFETY: Converting `&T` to `&[T; 1]` is sound. unsafe { &*(s as *const T).cast::<[T; 1]>() } } /// Converts a mutable reference to `T` into a mutable reference to an array of length 1 (without copying). <del> #[unstable(feature = "array_from_ref", issue = "77101")] </del> <ins> #[stable(feature = "array_from_ref", since = "1.53.0")] </ins> pub fn from_mut<T>(s: &mut T) -> &mut [T; 1] { // SAFETY: Converting `&mut T` to `&mut [T; 1]` is sound. unsafe { &mut *(s as *mut T).cast::<[T; 1]>() }

#![feature(alloc_layout_extra)] #![feature(array_chunks)] <del> #![feature(array_from_ref)] </del> #![feature(array_methods)] #![feature(array_map)] #![feature(array_windows)]
Change:
<!-- 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. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
The backtrace suggests that ICE is caused by error formatting machinery. This is a corner case that should be fixed, but my original intention was to provide a concrete type. Sadly, it didn't work out either: results in: Will this be possible one day? My intuition tells me that the snippet above should work. Apologies if this is an improper place for such questions.
The original no longer ICEs since , however the following does Maybe a different ICE?
And the above no longer ICEs since

Discussion:
<ins> // Regression test for #74280. #![feature(type_alias_impl_trait)] type Test = impl Copy; fn test() -> Test { let y = || -> Test { () }; //~^ ERROR: concrete type differs from previous defining opaque type use 7 } fn main() {} </ins>

<ins> error: concrete type differs from previous defining opaque type use --> $DIR/issue-74280.rs:8:13 | LL |     let y = || -> Test { () }; |             ^^^^^^^^^^^^^^^^^ expected `i32`, got `()` | note: previous use here --> $DIR/issue-74280.rs:7:1 | LL | fn test() -> Test { | ^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

<ins> // Regression test for #77179. #![feature(type_alias_impl_trait)] type Pointer<T> = impl std::ops::Deref<Target=T>; fn test() -> Pointer<_> { //~^ ERROR: the type placeholder `_` is not allowed within types Box::new(1) } fn main() { test(); } </ins>

<ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures for return types --> $DIR/issue-77179.rs:7:22 | LL | fn test() -> Pointer<_> { |              --------^- |              |       | |              |       not allowed in type signatures |              help: replace with the correct return type: `Box<i32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </ins>
Change:
<!-- 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. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing as as part of the prioritization working group procedure.
searched nightlies: from nightly-2020-09-16 to nightly-2020-09-29 regressed nightly: nightly-2020-09-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Cc

Discussion:
use rustc_middle::ty::{self, subst::Subst, TyCtxt}; use rustc_span::source_map::Span; use rustc_target::abi::{Abi, LayoutOf}; <del> use std::convert::TryInto; </del> <ins> use std::convert::{TryFrom, TryInto}; </ins> pub fn note_on_undefined_behavior_error() -> &'static str { "The rules on what exactly is undefined behavior aren't clear, 

Scalar::Raw { data, .. } => { assert!(mplace.layout.is_zst()); assert_eq!( <del> data, mplace.layout.align.abi.bytes().into(), "this MPlaceTy must come from `try_as_mplace` being used on a zst, so we know what value this integer address must have", </del> <ins> u64::try_from(data).unwrap() % mplace.layout.align.abi.bytes(), 0, "this MPlaceTy must come from a validated constant, thus we can assume the  alignment is correct", </ins> ); ConstValue::Scalar(Scalar::zst()) }

<ins> // check-pass const FOO: isize = 10; const ZST: &() = unsafe { std::mem::transmute(FOO) }; fn main() { match &() { ZST => 9, }; } </ins>