jiebi/CodeConvo huggingface dataset:
Change:
adds methods to and . Unresolved questions:
Can I nominate this for stabilization? It's a straightforward API with no real alternatives possible, and I had a real-world use case for it recently.
CC --^?
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] [ ] 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 /// /// ```no_run <del> /// #![feature(buffered_io_capacity)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

///     Ok(()) /// } /// ``` <del> #[unstable(feature = "buffered_io_capacity", issue = "68833")] </del> <ins> #[stable(feature = "buffered_io_capacity", since = "1.46.0")] </ins> pub fn capacity(&self) -> usize { self.buf.len() }

/// # Examples /// /// ```no_run <del> /// #![feature(buffered_io_capacity)] </del> /// use std::io::BufWriter; /// use std::net::TcpStream; ///

/// // Calculate how many bytes can be written without flushing /// let without_flush = capacity - buf_writer.buffer().len(); /// ``` <del> #[unstable(feature = "buffered_io_capacity", issue = "68833")] </del> <ins> #[stable(feature = "buffered_io_capacity", since = "1.46.0")] </ins> pub fn capacity(&self) -> usize { self.buf.capacity() }
Change:
As , the MIR inliner seems to fail when dealing with opaque return types. Test case: Invocation: <details<summaryICE:</summary</details
I'm not sure how async closures desugar, so this could be way off base, but this looks very similar to the other ICEs tracked in . Does this look like another instance of that issue to you?
The immediate cause of this is the fact that we call during inlining: If we do this, we should also be normalizing the substs we pass to , so that we reveal any opaque types. However, it looks like the opaque type occurs within a binder (due the opaque type appearing in the return type of an fn pointer), so I think lazy normalization may be required to fix this in the general case.
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .

Discussion:
<ins> // edition:2018 // compile-flags: -Z mir-opt-level=2 -Z unsound-mir-opts #[inline(always)] pub fn f(s: bool) -> String { let a = "Hello world!".to_string(); let b = a; let c = b; if s { c } else { String::new() } } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // edition:2018 // build-pass #![feature(async_closure)] use std::future::Future; fn async_closure() -> impl Future<Output = u8> { (async move || -> u8 { 42 })() } fn main() { let _fut = async_closure(); } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>

<ins> // edition:2018 // build-pass // compile-flags: -Z mir-opt-level=2 -L. // aux-build:issue_76375_aux.rs #![crate_type = "lib"] extern crate issue_76375_aux; pub async fn g() { issue_76375_aux::f(true); h().await; } pub async fn h() {} </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // ignore-cloudabi no std::fs // build-pass use std::fs::File; use std::io::{BufRead, BufReader}; fn file_lines() -> impl Iterator<Item = String> { BufReader::new(File::open("").unwrap()) .lines() .map(Result::unwrap) } fn main() { for _ in file_lines() {} } </ins>
Change:
Attempting to build this code generates an ICE (): The error message, on my machine: Looks like it's related to , but the construction that triggers it is different enough that it seems worth posting.
Source: <details<summaryStack trace</summary<p</p</detailsWith regression in nightly-2019-07-31 <details<summaryBisect output</summary<p</p</detailsdddb7fca09d Auto merge of - Xanewok:update-rls, r=Xanewok Auto merge of - alexcrichton:stabilize-pipelined-compilation, r=oli-obk Auto merge of - Centril:rollup-onohtqt, r=Centril
Triage: This is no longer ICE even with the feature flag:

Discussion:
<ins> // check-fail struct DataWrapper<'a> { data: &'a [u8; Self::SIZE], //~ ERROR generic `Self` types are currently not permitted in anonymous constants } impl DataWrapper<'_> { const SIZE: usize = 14; } pub fn main() {} </ins>

<ins> error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/ice-68875.rs:4:20 | LL |     data: &'a [u8; Self::SIZE], |                    ^^^^ 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 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 compiler team prioritization.
triage: P-medium, removing nomination tag.
Already fixed on the Miri side:

Discussion:
<del> Subproject commit 75417e5a660096929aa10f1072a21d6662c9c0dc </del> <ins> Subproject commit e3cfb61ece273d59b62fb959ed17c99c04941d82 </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
triage : P-medium, removing nomination, adding needs-bisect.
(the bisection here would be entirely automatable if were addressed.)
Bisected roughly: ICE occurred from but not panicked, panicked from
in particular looks suspicious. cc
Pre-, we return early with an error here: Post-, in the corresponding code happens in a call to : and the parser "recovers" from the error encountered in , allowing this line to be reached:
I opened , which takes the stance that is no longer appropriate here. It's possible that there's a better fix that changes the way works, but that would require a deeper expertise of how these things are supposed to work than I currently have.

Discussion:
let path = match bounds.remove(0) { GenericBound::Trait(pt, ..) => pt.trait_ref.path, GenericBound::Outlives(..) => { <del> self.span_bug(ty.span, "unexpected lifetime bound") </del> <ins> return Err(self.struct_span_err( ty.span, "expected trait bound, not lifetime bound", )); </ins> } }; self.parse_remaining_bounds(Vec::new(), path, lo, true)

<ins> enum e{A((?'a a+?+l))} //~^ ERROR `?` may only modify trait bounds, not lifetime bounds //~| ERROR expected one of `)`, `+`, or `,` //~| ERROR expected trait bound, not lifetime bound </ins>

<ins> error: `?` may only modify trait bounds, not lifetime bounds --> $DIR/issue-68890.rs:1:11 | LL | enum e{A((?'a a+?+l))} |           ^ error: expected one of `)`, `+`, or `,`, found `a` --> $DIR/issue-68890.rs:1:15 | LL | enum e{A((?'a a+?+l))} |               ^ expected one of `)`, `+`, or `,` error: expected trait bound, not lifetime bound --> $DIR/issue-68890.rs:1:11 | LL | enum e{A((?'a a+?+l))} |           ^^^ error: aborting due to 3 previous errors </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.

Discussion:
<del> Subproject commit ea85b4c7fb9826f72bd4ab743a703a34c75a40f0 </del> <ins> Subproject commit 07f1736390e1d4dd88cf9fae4ab7737ee5e086b7 </ins>
Change:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

Discussion:
<ins> // build-fail // ignore-emscripten no asm! support // Regression test for #69092 #![feature(asm)] fn main() { unsafe { asm!(".ascii "Xen0""); } //~^ ERROR: <inline asm>:1:9: error: expected string in '.ascii' directive } </ins>

<ins> error: <inline asm>:1:9: error: expected string in '.ascii' directive .ascii "Xen ^ --> $DIR/issue-69092.rs:8:14 | LL |     unsafe { asm!(".ascii "Xen0""); } |              ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

<ins> // Regression test for #62504 #![feature(const_generics)] #![allow(incomplete_features)] trait HasSize { const SIZE: usize; } impl<const X: usize> HasSize for ArrayHolder<{ X }> { const SIZE: usize = X; } struct ArrayHolder<const X: usize>([u32; X]); impl<const X: usize> ArrayHolder<{ X }> { pub const fn new() -> Self { ArrayHolder([0; Self::SIZE]) //~^ ERROR: array lengths can't depend on generic parameters } } fn main() { let mut array = ArrayHolder::new(); } </ins>

<ins> error: array lengths can't depend on generic parameters --> $DIR/issue-62504.rs:18:25 | LL |         ArrayHolder([0; Self::SIZE]) |                         ^^^^^^^^^^ error: aborting due to previous error </ins>

<ins> // Regression test for #67739 #![allow(incomplete_features)] #![feature(const_generics)] use std::mem; pub trait Trait { type Associated: Sized; fn associated_size(&self) -> usize { [0u8; mem::size_of::<Self::Associated>()]; //~^ ERROR: array lengths can't depend on generic parameters 0 } } fn main() {} </ins>

<ins> error: array lengths can't depend on generic parameters --> $DIR/issue-67739.rs:12:15 | LL |         [0u8; mem::size_of::<Self::Associated>()]; |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

<ins> // Regression test for #58490 macro_rules! a { ( @1 $i:item ) => { a! { @2 $i } }; ( @2 $i:item ) => { $i }; } mod b { a! { @1 #[macro_export] macro_rules! b { () => () } } #[macro_export] macro_rules! b { () => () } //~^ ERROR: the name `b` is defined multiple times } mod c { #[allow(unused_imports)] use crate::b; } fn main() {} </ins>

<ins> error[E0428]: the name `b` is defined multiple times --> $DIR/issue-58490.rs:18:5 | LL |         macro_rules! b { () => () } |         -------------- previous definition of the macro `b` here ... LL |     macro_rules! b { () => () } |     ^^^^^^^^^^^^^^ `b` redefined here | = note: `b` must be defined only once in the macro namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

<ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #60390, this ICE requires `--emit=mir` flag. fn main() { enum Inner { Member(u32) }; Inner::Member(0); } </ins>
Change:
The ICE only occurs when is used. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Nominating due to impending stabilization, even though stable doesn't ICE yet
Simplified:

Discussion:
let mut slice = None; let mut prev_rest_span = None; <ins> // Lowers `$bm $ident @ ..` to `$bm $ident @ _`. let lower_rest_sub = |this: &mut Self, pat, bm, ident, sub| { let lower_sub = |this: &mut Self| Some(this.pat_wild_with_node_id_of(sub)); let node = this.lower_pat_ident(pat, bm, ident, lower_sub); this.pat_with_node_id_of(pat, node) }; </ins> let mut iter = pats.iter(); // Lower all the patterns until the first occurrence of a sub-slice pattern. for pat in iter.by_ref() {

// Record, lower it to `$binding_mode $ident @ _`, and stop here. PatKind::Ident(ref bm, ident, Some(ref sub)) if sub.is_rest() => { prev_rest_span = Some(sub.span); <del> let lower_sub = |this: &mut Self| Some(this.pat_wild_with_node_id_of(sub)); let node = self.lower_pat_ident(pat, bm, ident, lower_sub); slice = Some(self.pat_with_node_id_of(pat, node)); </del> <ins> slice = Some(lower_rest_sub(self, pat, bm, ident, sub)); </ins> break; } // It was not a subslice pattern so lower it normally.

// There was a previous subslice pattern; make sure we don't allow more. let rest_span = match pat.kind { PatKind::Rest => Some(pat.span), <del> PatKind::Ident(.., Some(ref sub)) if sub.is_rest() => { // The `HirValidator` is merciless; add a `_` pattern to avoid ICEs. after.push(self.pat_wild_with_node_id_of(pat)); </del> <ins> PatKind::Ident(ref bm, ident, Some(ref sub)) if sub.is_rest() => { // #69103: Lower into `binding @ _` as above to avoid ICEs. after.push(lower_rest_sub(self, pat, bm, ident, sub)); </ins> Some(sub.span) } _ => None,

<ins> // We used to not lower the extra `b @ ..` into `b @ _` which meant that no type // was registered for the binding `b` although it passed through resolve. // This resulted in an ICE (#69103). fn main() { let [a @ .., b @ ..] = &mut [1, 2]; //~^ ERROR `..` can only be used once per slice pattern b; let [.., c @ ..] = [1, 2]; //~^ ERROR `..` can only be used once per slice pattern c; // This never ICEd, but let's make sure it won't regress either. let (.., d @ ..) = (1, 2); //~^ ERROR `..` patterns are not allowed here d; } </ins>

<ins> error: `..` can only be used once per slice pattern --> $DIR/issue-69103-extra-binding-subslice.rs:6:22 | LL |     let [a @ .., b @ ..] = &mut [1, 2]; |              --      ^^ can only be used once per slice pattern |              | |              previously used here error: `..` can only be used once per slice pattern --> $DIR/issue-69103-extra-binding-subslice.rs:10:18 | LL |     let [.., c @ ..] = [1, 2]; |          --      ^^ can only be used once per slice pattern |          | |          previously used here error: `..` patterns are not allowed here --> $DIR/issue-69103-extra-binding-subslice.rs:15:18 | LL |     let (.., d @ ..) = (1, 2); |                  ^^ | = note: only allowed in tuple, tuple struct, and slice patterns error: aborting due to 3 previous errors </ins>
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 compiler team prioritization.
Triage meeting: Tagged as P-medium, appears to have PR.

Discussion:
<del> Subproject commit e3cfb61ece273d59b62fb959ed17c99c04941d82 </del> <ins> Subproject commit ded5a52639a78907523b74a9d3ed8e3824c88ca5 </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
Visited from compiler team triage meeting. Categorized as P-medium.
searched nightlies: from nightly-2020-01-01 to nightly-2020-02-10 regressed nightly: nightly-2020-01-22 searched commits: from to regressed commit: source code: <details<summaryICE backtrace</summary<p</p</detailsReproduce bisect report:
Interesting -- the regression report suggests this was caused by , cc
The problem is here: is a character index. It needs to be translated into a byte index before it can be used to slice . I've submitted a

Discussion:
} } if let Some(cur_line) = sf.get_line(cur_lo.line - 1) { <del> let end = std::cmp::min(cur_line.len(), cur_lo.col.to_usize()); </del> <ins> let end = match cur_line.char_indices().nth(cur_lo.col.to_usize()) { Some((i, _)) => i, None => cur_line.len(), }; </ins> buf.push_str(&cur_line[..end]); } }

LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:363:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic

<ins> // Issue 69130: character indexing bug in rustc_errors::CodeSuggestion::splice_lines(). enum F { M (§& u8)} //~^ ERROR unknown start of token //~| missing lifetime specifier fn main() {} </ins>

<ins> error: unknown start of token: u{a7} --> $DIR/issue-69130.rs:4:4 | LL | M (§& u8)} |    ^ error[E0106]: missing lifetime specifier --> $DIR/issue-69130.rs:4:5 | LL | M (§& u8)} |     ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | LL | enum F<'a> { LL | M (§&'a  u8)} | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0106`. </ins>
Change:
This is a follow up on , which now works. The following doesn't (): Error is: however, this lifetime clearly is used and is required.
The variance code in is: It seems to me that this is disregarding the substitutions for if I'm understanding what does here wrt. the substitutions (this pretty poorly documented right now). cc
BTW how long do we need to keep this warning around? I understand that this is basically a given when using nightly features. (It puts me off using it in my normal build path — but presumably that's exactly what is wanted, in order to detect bugs like the one reported here.)
We only use for those that have been ICE-prone in the past or are generally not in a "considered implemented modulo bugs" state. It's quite a small set of features that are incomplete like this. GATs specifically are to my knowledge nowhere near ready to be "implemented modulo bugs".
On this topic, the following builds, but the bound fails with:
Also, the following fails: with: This bound may not make much sense (since there is another lifetime parameter), but I believe it should be valid to specify here.
I'm running into a similar issue which I believe is the same as this:

Discussion:
} } <del> fn add_constraints_from_trait_ref( &mut self, current: &CurrentItem, trait_ref: ty::TraitRef<'tcx>, variance: VarianceTermPtr<'a>, ) { debug!("add_constraints_from_trait_ref: trait_ref={:?} variance={:?}", trait_ref, variance); self.add_constraints_from_invariant_substs(current, trait_ref.substs, variance); } </del> <ins> #[instrument(skip(self, current))] </ins> fn add_constraints_from_invariant_substs( &mut self, current: &CurrentItem, substs: SubstsRef<'tcx>, variance: VarianceTermPtr<'a>, ) { <del> debug!( "add_constraints_from_invariant_substs: substs={:?} variance={:?}", substs, variance ); </del> // Trait are always invariant so we can take advantage of that. let variance_i = self.invariant(variance);

} ty::Projection(ref data) => { <del> let tcx = self.tcx(); self.add_constraints_from_trait_ref(current, data.trait_ref(tcx), variance); </del> <ins> self.add_constraints_from_invariant_substs(current, data.substs, variance); </ins> } ty::Opaque(_, substs) => {

<ins> // check-pass // issue #69184 #![feature(generic_associated_types)] #![allow(incomplete_features)] trait A { type B<'a>; fn make_b<'a>(&'a self) -> Self::B<'a>; } struct S {} impl A for S { type B<'a> = &'a S; fn make_b<'a>(&'a self) -> &'a Self { self } } enum E<'a> { S(<S as A>::B<'a>), } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.

Discussion:
"itertools 0.8.0", "lazy_static 1.4.0", "matches", <del> "pulldown-cmark 0.6.1", </del> <ins> "pulldown-cmark 0.7.0", </ins> "quine-mc_cluskey", "regex-syntax", "semver",

<del> Subproject commit 07f1736390e1d4dd88cf9fae4ab7737ee5e086b7 </del> <ins> Subproject commit b91ae16eb1ab03b996de5ffc44db054244c1d2f6 </ins>
Change:
Example: Results in the following error: of course, is by default unless you say , so the error and the suggestion are clearly wrong. And if you do say explicitly, you get Note being suggested, which is ~not even valid syntax~ apparently valid syntax, but not something you would write. I expected to see this happen: Either this compiles cleanly Or the compiler emits a different error that makes sense <!-- 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. --: (Seems to happen on nightly too.) </details
Duplicate of
Reopening to track the error message, which is not tracked by . is just wrong.

Discussion:
<ins> // https://github.com/rust-lang/rust/issues/69228 // Used to give bogus suggestion about T not being Sized. use std::mem::size_of; fn foo<T>() { let _arr: [u8; size_of::<T>()]; //~^ ERROR generic parameters may not be used in const operations //~| NOTE cannot perform const operation //~| NOTE type parameters may not be used in const expressions } fn main() {} </ins>

<ins> error: generic parameters may not be used in const operations --> $DIR/size-of-t.rs:7:30 | LL |     let _arr: [u8; size_of::<T>()]; |                              ^ cannot perform const operation using `T` | = note: type parameters may not be used in const expressions = help: use `#![feature(generic_const_exprs)]` to allow generic const expressions 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 clippy-driver 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 compiler team prioritization.

Discussion:
<del> Subproject commit b91ae16eb1ab03b996de5ffc44db054244c1d2f6 </del> <ins> Subproject commit 2855b2143972df7102333193aa3c83ddce227e36 </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 compiler team prioritization.
triage: P-medium. Removing nomination.

Discussion:
<del> Subproject commit 10bf331d4d1280d773045e57d65031969c51dec6 </del> <ins> Subproject commit 5fde462d8c53b86840100a927a17c8353bba3e3f </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.
[triagebot]

Discussion:
<del> Subproject commit 2855b2143972df7102333193aa3c83ddce227e36 </del> <ins> Subproject commit 8fbb23f2549e75b89967f09b9293607bd3bb96a6 </ins>