jiebi/CodeConvo huggingface dataset:
Change:
While trying to port the bug case from forward to more modern Rust syntax, I hit the following ICE:
Reproduced with ; nominating for milestone 5, production-ready
accepted for production-ready milestone
(still a bug. assigning to self for investigation as part of grokking the type/borrow check code.)
Probably a subbug of .
This is an updated code for this issue. With the following code, it is not possible to reproduce this issue: Can we close this issue?
A test should be checked in to close the issue.
+1, I'll submit a PR with the same example used here

Discussion:
<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. // // 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. pub trait OpInt<'a> { fn call<'a>(&'a self, int, int) -> int; } impl<'a> OpInt<'a> for 'a |int, int| -> int { fn call(&self, a:int, b:int) -> int { (*self)(a, b) } } fn squarei<'a>(x: int, op: &'a OpInt) -> int { op.call(x, x) } fn muli(x:int, y:int) -> int { x * y } pub fn main() { let f = |x,y| muli(x,y); { let g = &f; let h = g as &OpInt; squarei(3, h); } } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I'll make an update pr once the two prs currently in the clippy ci queue are merged
triage: P-medium. Removing nomination tag.

Discussion:
<del> Subproject commit 20da8f45c601d0eec8af8c0897abd536ad57951f </del> <ins> Subproject commit 71be6f62fa920c0bd10cdf3a29aeb8c6719a8075 </ins>
Change:
Originally stumbled upon through the eval IRC bot: Here's the smallest reproduction I could get, Removing either the block or the borrow displays only a normal compiler error (not an ICE) trace
triage: P-high, assigned to ; removing I-nominated label

Discussion:
offsets[usize::try_from(field).unwrap()], layout::FieldPlacement::Array { stride, .. } => { let len = base.len(self)?; <del> assert!(field < len, "Tried to access element {} of array/slice with length {}", field, len); </del> <ins> if field >= len { // This can be violated because this runs during promotion on code where the // type system has not yet ensured that such things don't happen. debug!("Tried to access element {} of array/slice with length {}", field, len); return err!(BoundsCheck { len, index: field }); } </ins> stride * field } layout::FieldPlacement::Union(count) => {

<ins> fn main() { &{[1, 2, 3][4]}; //~^ ERROR index out of bounds //~| ERROR reaching this expression at runtime will panic or abort //~| ERROR this expression will panic at runtime } </ins>

<ins> error: index out of bounds: the len is 3 but the index is 4 --> $DIR/array-literal-index-oob.rs:2:7 | LL |     &{[1, 2, 3][4]}; |       ^^^^^^^^^^^^ | = note: #[deny(const_err)] on by default error: this expression will panic at runtime --> $DIR/array-literal-index-oob.rs:2:5 | LL |     &{[1, 2, 3][4]}; |     ^^^^^^^^^^^^^^^ index out of bounds: the len is 3 but the index is 4 error: reaching this expression at runtime will panic or abort --> $DIR/array-literal-index-oob.rs:2:7 | LL |     &{[1, 2, 3][4]}; |     --^^^^^^^^^^^^- |       | |       index out of bounds: the len is 3 but the index is 4 error: aborting due to 3 previous errors </ins>
Change:
ICE on both and code <details<summarybacktrace: cargo run +stable build --verbose</summary</details
Likely dupe of cc

Discussion:
(Reservation(WriteKind::MutableBorrow(bk)), BorrowKind::Shallow) | (Reservation(WriteKind::MutableBorrow(bk)), BorrowKind::Shared) if { <del> tcx.migrate_borrowck() </del> <ins> tcx.migrate_borrowck() && this.borrow_set.location_map.contains_key(&location) </ins> } => { let bi = this.borrow_set.location_map[&location]; debug!(

<ins> fn f1<'a>(_: &'a mut ()) {} fn f2<P>(_: P, _: ()) {} fn f3<'a>(x: &'a ((), &'a mut ())) { f2(|| x.0, f1(x.1)) //~^ ERROR cannot borrow `*x.1` as mutable, as it is behind a `&` reference //~| ERROR cannot borrow `*x.1` as mutable because it is also borrowed as immutable } fn main() {} </ins>

<ins> error[E0596]: cannot borrow `*x.1` as mutable, as it is behind a `&` reference --> $DIR/issue-61623.rs:6:19 | LL | fn f3<'a>(x: &'a ((), &'a mut ())) { |              -------------------- help: consider changing this to be a mutable reference: `&'a mut ((), &'a mut ())` LL |     f2(|| x.0, f1(x.1)) |                   ^^^ `x` is a `&` reference, so the data it refers to cannot be borrowed as mutable error[E0502]: cannot borrow `*x.1` as mutable because it is also borrowed as immutable --> $DIR/issue-61623.rs:6:19 | LL |     f2(|| x.0, f1(x.1)) |     -- -- -       ^^^ mutable borrow occurs here |     |  |  | |     |  |  first borrow occurs due to use of `x` in closure |     |  immutable borrow occurs here |     immutable borrow later used by call error: aborting due to 2 previous errors Some errors have detailed explanations: E0502, E0596. For more information about an error, try `rustc --explain E0502`. </ins>
Change:
I tried this code: I expected to see this happen: no build warn Instead, this happened: :
We . The likely cause is that parts of the await desugaring are being linted against. We can likely check the span to see if the code that is being linted against is part of the desugaring, but we do want to be careful to ensure that still gets a lint warning.
Marking as deferred as this doesn't seem like a problem that needs to block stabilization.
cc who has done some work on the inhabited logic stuff.
I'm now getting this warning even for functions that loop but eventually return. It worked fine with nightly-2019-08-21, but the latest nightly (2019-09-17) is broken. For example, this code generates a warning: with the warning repeated twice:
Can confirm. I believe this regressed somewhere after nightly 09-09-2019.
I think I have this in my code here: Can somebody confirm this? If not I'll file another bug report.
yeah that's the same, the function can "never" return from the unconditional loop.

Discussion:
// which diverges, that we are about to lint on. This gives suboptimal diagnostics. // Instead, stop here so that the `if`- or `while`-expression's block is linted instead. if !span.is_desugaring(DesugaringKind::CondTemporary) && <del> !span.is_desugaring(DesugaringKind::Async) </del> <ins> !span.is_desugaring(DesugaringKind::Async) && !orig_span.is_desugaring(DesugaringKind::Await) </ins> { self.diverges.set(Diverges::WarnedAlways);

<ins> // edition:2018 #![deny(unreachable_code)] async fn foo() { return; bar().await; //~^ ERROR unreachable statement } async fn bar() { } fn main() { } </ins>

<ins> error: unreachable statement --> $DIR/unreachable-lint-1.rs:5:13 | LL |     return; bar().await; |     ------  ^^^^^^^^^^^^ unreachable statement |     | |     any code following this expression is unreachable | note: lint level defined here --> $DIR/unreachable-lint-1.rs:2:9 | LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

<ins> // check-pass // edition:2018 #![deny(unreachable_code)] async fn foo() { endless().await; } async fn endless() -> ! { loop {} } fn main() { } </ins>
Change:
The following, which I expect to work, fails to infer the type of : In HIR, should correspond to: However, if we change the snippet to: it all works out fine. I also tested changing to a tuple variant and that works also. cc cc
It might be a good idea to trace the difference between and because they look relatively similar and yet they behave differently in terms of inference.
Value (/) and type () namespaces execute very different logic for type inference (/ vs ). It's quite possible that there are intended and unintended observable differences (not necessarily specific to ). checkpatpath and checkpattuplestruct Rather and . ( is the same "value" case as .)

Discussion:
debug!("check_pat_walk(pat={:?},expected={:?},def_bm={:?})", pat, expected, def_bm); <ins> let mut path_resolution = None; </ins> let is_non_ref_pat = match pat.node { PatKind::Struct(..) | PatKind::TupleStruct(..) |

} } PatKind::Path(ref qpath) => { <del> let (def, _, _) = self.resolve_ty_and_res_ufcs(qpath, pat.hir_id, pat.span); match def { </del> <ins> let resolution = self.resolve_ty_and_res_ufcs(qpath, pat.hir_id, pat.span); path_resolution = Some(resolution); match resolution.0 { </ins> Res::Def(DefKind::Const, _) | Res::Def(DefKind::AssocConst, _) => false, _ => true, }

) } PatKind::Path(ref qpath) => { <del> self.check_pat_path(pat, qpath, expected) </del> <ins> self.check_pat_path(pat, path_resolution.unwrap(), qpath, expected) </ins> } PatKind::Struct(ref qpath, ref fields, etc) => { self.check_pat_struct(pat, qpath, fields, etc, expected, def_bm, discrim_span)

fn check_pat_path( &self, pat: &hir::Pat, <ins> path_resolution: (Res, Option<Ty<'tcx>>, &'b [hir::PathSegment]), </ins> qpath: &hir::QPath, expected: Ty<'tcx>, ) -> Ty<'tcx> { let tcx = self.tcx; <del> // Resolve the path and check the definition for errors. let (res, opt_ty, segments) = self.resolve_ty_and_res_ufcs(qpath, pat.hir_id, pat.span); </del> <ins> // We have already resolved the path. let (res, opt_ty, segments) = path_resolution; </ins> match res { Res::Err => { self.set_tainted_by_errors();

<ins> // In this regression test we check that a path pattern referring to a unit variant // through a type alias is successful in inferring the generic argument. // compile-pass #![feature(type_alias_enum_variants)] enum Opt<T> { N, S(T), } type OptAlias<T> = Opt<T>; fn f1(x: OptAlias<u8>) { match x { OptAlias::N // We previously failed to infer `T` to `u8`. => (), _ => (), } match x { < OptAlias<_> // And we failed to infer this type also. >::N => (), _ => (), } } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.

Discussion:
<del> Subproject commit 965160d4d7976ddead182b4a65b73f59818537de </del> <ins> Subproject commit fd0dccd4b12169e0aac42aff8addbb26b6d72197 </ins>
Change:
I tried this code: first outputs some error messages and then hangs up trying to allocate a large amount of memory. :
modify labels: regression-from-stable-to-nightly
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
Rust 1.34.0 and before is OK:
triage: P-medium. Removing nomination. Assigning to self and for initial investigation.
I'm seeing the same behavior on the following programs: and These were found with the help of .
Another program that I also observe to make run out of memory:
The original report is caused due to growing unbounded in a bad parser code path, in part due to it being a and not a (which it can't be at the moment). Now that I have a clue at what causes the behavior, I'll dig deeper for the trigger.

Discussion:
fn parse_block_tail(&mut self, lo: Span, s: BlockCheckMode) -> PResult<'a, P<Block>> { let mut stmts = vec![]; while !self.eat(&token::CloseDelim(token::Brace)) { <ins> if self.token == token::Eof { break; } </ins> let stmt = match self.parse_full_stmt(false) { Err(mut err) => { err.emit();

}; if let Some(stmt) = stmt { stmts.push(stmt); <del> } else if self.token == token::Eof { break; </del> } else { // Found only `;` or `}`. continue;

<ins> fn main() { (if foobar) //~ ERROR expected `{`, found `)` } </ins>

<ins> error: expected `{`, found `)` --> $DIR/issue-61858.rs:2:15 | LL |     (if foobar) |      --       ^ expected `{` |      | |      this `if` statement has a condition, but no block error: aborting due to previous error </ins>
Change:
I believe this happened after
triage: P-high because it blocks presumed stabilization of (). Removing nomination tag.
you can have parameterization in scope that's not part of monomorphization (like the above). For name mangling (with the new scheme) we produce something that demangles to in that case. We could use in this case too.
I'm working on a fix that uses .

Discussion:
Ok(self) } <del> fn print_type(self, ty: Ty<'tcx>) -> Result<Self::Type, Self::Error> { </del> <ins> fn print_type(mut self, ty: Ty<'tcx>) -> Result<Self::Type, Self::Error> { </ins> match ty.sty { <del> // types without identity </del> <ins> // Types without identity. </ins> | ty::Bool | ty::Char | ty::Int(_)

| ty::Never | ty::Tuple(_) | ty::Dynamic(_, _) <del> | ty::Adt(..) | ty::Foreign(_) // should be unreachable, but there's no hurt in printing it (and better than ICEing) | ty::Error </del> => self.pretty_print_type(ty), <del> | ty::Infer(_) | ty::Bound(_, _) </del> <ins> // Placeholders (all printed as `_` to uniformize them). </ins> | ty::Param(_) <ins> | ty::Bound(..) </ins> | ty::Placeholder(_) <del> | ty::Projection(_) | ty::UnnormalizedProjection(_) | ty::GeneratorWitness(_) => bug!( "{:#?} in `type_name` should not happen because we are always monomorphized", ty, ), // types with identity (print the module path instead) | ty::FnDef(did, substs) | ty::Opaque(did, substs) => self.print_def_path(did, substs), ty::Closure(did, substs) => self.print_def_path(did, substs.substs), ty::Generator(did, substs, _) => self.print_def_path(did, substs.substs), </del> <ins> | ty::Infer(_) | ty::Error => { write!(self, "_")?; Ok(self) } // Types with identity (print the module path). | ty::Adt(&ty::AdtDef { did: def_id, .. }, substs) | ty::FnDef(def_id, substs) | ty::Opaque(def_id, substs) | ty::Projection(ty::ProjectionTy { item_def_id: def_id, substs }) | ty::UnnormalizedProjection(ty::ProjectionTy { item_def_id: def_id, substs }) | ty::Closure(def_id, ty::ClosureSubsts { substs }) | ty::Generator(def_id, ty::GeneratorSubsts { substs }, _) => self.print_def_path(def_id, substs), ty::Foreign(def_id) => self.print_def_path(def_id, &[]), ty::GeneratorWitness(_) => { bug!("type_name: unexpected `GeneratorWitness`") } </ins> } }

<ins> #![feature(core_intrinsics)] use std::intrinsics::type_name; struct Bar<M>(M); impl<M> Bar<M> { fn foo(&self) -> &'static str { fn f() {} fn type_name_of<T>(_: T) -> &'static str { unsafe { type_name::<T>() } } type_name_of(f) } } fn main() { assert_eq!(Bar(()).foo(), "issue_61894::Bar<_>::foo::f"); } </ins>
Change:
I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened

Discussion:
/// If a file already exists in the source_map with the same id, that file is returned /// unmodified pub fn new_source_file(&self, filename: FileName, src: String) -> Lrc<SourceFile> { <ins> self.try_new_source_file(filename, src) .unwrap_or_else(|OffsetOverflowError| { eprintln!("fatal error: rustc does not support files larger than 4GB"); errors::FatalError.raise() }) } fn try_new_source_file( &self, filename: FileName, src: String ) -> Result<Lrc<SourceFile>, OffsetOverflowError> { </ins> let start_pos = self.next_start_pos(); // The path is used to determine the directory for loading submodules and

was_remapped, Some(&unmapped_path)); <del> return match self.source_file_by_stable_id(file_id) { </del> <ins> let lrc_sf = match self.source_file_by_stable_id(file_id) { </ins> Some(lrc_sf) => lrc_sf, None => { let source_file = Lrc::new(SourceFile::new(

unmapped_path, src, Pos::from_usize(start_pos), <del> )); </del> <ins> )?); </ins> let mut files = self.files.borrow_mut();

source_file } <del> } </del> <ins> }; Ok(lrc_sf) </ins> } /// Allocates a new SourceFile representing a source file from an external

} } <ins> #[derive(Debug)] pub struct OffsetOverflowError; </ins> /// A single source in the `SourceMap`. #[derive(Clone)] pub struct SourceFile {

name_was_remapped: bool, unmapped_path: FileName, mut src: String, <del> start_pos: BytePos) -> SourceFile { </del> <ins> start_pos: BytePos) -> Result<SourceFile, OffsetOverflowError> { </ins> remove_bom(&mut src); let src_hash = {

hasher.finish() }; let end_pos = start_pos.to_usize() + src.len(); <ins> if end_pos > u32::max_value() as usize { return Err(OffsetOverflowError); } </ins> let (lines, multibyte_chars, non_narrow_chars) = analyze_source_file::analyze_source_file(&src[..], start_pos); <del> SourceFile { </del> <ins> Ok(SourceFile { </ins> name, name_was_remapped, unmapped_path: Some(unmapped_path),

multibyte_chars, non_narrow_chars, name_hash, <del> } </del> <ins> }) </ins> } /// Returns the `BytePos` of the beginning of the current line.
Change:
Trying to build rustc with Visual Studio 2019 Build Tools results in the following error: I've tried version versions 16.1.1 and 16.1.3 on different machines with the same result. Visual Studio 2017 Build Tools work fine. Is there some magic incantation I'm missing?
I get this as well. I've been hacking around it with I think this was introduced in , so cc
I don't think that anything is being missed here. This is probably a bug with either: An upstream compiler-rt bug that needs to be fixed A bug with how we build compiler-rt since we're not using the standard build system The former may already even be fixed upstream, the latter is probably some missing flag we're not passing and would require inspecting the source. In both cases the source needs to be inspected likely :)
was applied to our fork, but it was lost somehow, breaking VS 2019 builds.

Discussion:
<del> Subproject commit 788592fb2740d560d0614a77035b319b9d07aa38 </del> <ins> Subproject commit 1bbe0b3e1d756116cbf1fcf049555066ef929008 </ins>
Change:
Attempting to shim futures-preview Stream to a tokio futures 0.1 Stream results in ICE when done this way. Most minimal example I can give
Minimized:
The ICE goes away if you assign (or whatever type you create in the loop body) to a variable. Looking at the generated MIR, it seems that we never emit / statements for the temporary created by the statement, leading later analysis to incorrectly conclude that it lives across a yield point.
I believe this will be fixed by
This is indeed fixed-- I've opened with a regression test.

Discussion:
<ins> // compile-pass // edition:2018 // // Tests that we properly handle StorageDead/StorageLives for temporaries // created in async loop bodies. #![feature(async_await)] async fn bar() -> Option<()> { Some(()) } async fn listen() { while let Some(_) = bar().await { String::new(); } } fn main() { listen(); } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I think fixes this so I opened . Feel free to close it if it's invalid.

Discussion:
<del> Subproject commit c65fbc49d7b9269b277b7207f1044ee851f16b16 </del> <ins> Subproject commit 945f007c0d305c3ec069b5e5d911ef783f6d70e7 </ins>
Change:
Unconstrained lifetime parameters are actually allowed: Unlike what's described here: For comparison, unconstrained type parameters do generate error:
I would like to address this. What should be error message for E0207?
Maybe just don't mention lifetime parameter?
I think this has been fixed already. Can you please try again?
I don't think it has been: still mentions lifetime parameter.
Sorry My bad. I missed checking this file. Let me fix and raise PR.
Thanks :+1:

Discussion:
<del> A type or lifetime parameter that is specified for `impl` is not constrained. </del> <ins> A type parameter that is specified for `impl` is not constrained. </ins> Erroneous code example:

} ``` <del> Any type parameter or lifetime parameter of an `impl` must meet at least one of </del> <ins> Any type parameter parameter of an `impl` must meet at least one of </ins> the following criteria: - it appears in the _implementing type_ of the impl, e.g. `impl<T> Foo<T>`
Change:
The following code results in an ICE on stable, beta, and nightly () Errors:
thanks to for providing a ICE appears to have been injected between 1.32.0 and 1.33.0. We could obviously use further bisection.
triage: P-high, removing nomination, marking needs-bisect, and assigning to self.
ICE was injected between nightly-2019-01-03 ( 2019-01-02) and nightly-2019-01-04 ( 2019-01-03). We did not have many PR's merged in that time frame, just these: Based on past experience, I'm guessing this is due to the Universes PR .
I'm going to take a shot at just turning the current call into a and see where that gets us.

Discussion:
} } <del> span_bug!( </del> <ins> // Errors in earlier passes can yield error variables without // resolution errors here; delay ICE in favor of those errors. self.tcx().sess.delay_span_bug( </ins> self.var_infos[node_idx].origin.span(), <del> "collect_error_for_expanding_node() could not find  error for var {:?} in universe {:?}, lower_bounds={:#?},  upper_bounds={:#?}", node_idx, node_universe, lower_bounds, upper_bounds ); </del> <ins> &format!("collect_error_for_expanding_node() could not find  error for var {:?} in universe {:?}, lower_bounds={:#?},  upper_bounds={:#?}", node_idx, node_universe, lower_bounds, upper_bounds)); </ins> } fn collect_concrete_regions(

<ins> trait T0<'a, A> { type O; } struct L<T> { f: T, } // explicitly named variants of what one would normally denote by the // unit type `()`. Why do this? So that we can differentiate them in // the diagnostic output. struct Unit1; struct Unit2; struct Unit3; struct Unit4; impl<'a, A, T> T0<'a, A> for L<T> where T: FnMut(A) -> Unit3, { type O = T::Output; } trait T1: for<'r> Ty<'r> { fn m<'a, B: Ty<'a>, F>(&self, f: F) -> Unit1 where F: for<'r> T0<'r, (<Self as Ty<'r>>::V,), O = <B as Ty<'r>>::V>, { unimplemented!(); } } trait Ty<'a> { type V; } fn main() { let v = Unit2.m( //~^ ERROR type mismatch //~| ERROR type mismatch L { f : |x| { drop(x); Unit4 } }); } impl<'a> Ty<'a> for Unit2 { type V = &'a u8; } impl T1 for Unit2 {} </ins>

<ins> error[E0271]: type mismatch resolving `for<'r> <L<[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:39]> as T0<'r, (<Unit2 as Ty<'r>>::V,)>>::O == <_ as Ty<'r>>::V` --> $DIR/issue-62203-hrtb-ice.rs:38:19 | LL |     let v = Unit2.m( |                   ^ expected struct `Unit4`, found associated type | = note: expected type `Unit4` found type `<_ as Ty<'_>>::V` error[E0271]: type mismatch resolving `<[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:39] as std::ops::FnOnce<((&u8,),)>>::Output == Unit3` --> $DIR/issue-62203-hrtb-ice.rs:38:19 | LL |     let v = Unit2.m( |                   ^ expected struct `Unit4`, found struct `Unit3` | = note: expected type `Unit4` found type `Unit3` = note: required because of the requirements on the impl of `for<'r> T0<'r, (<Unit2 as Ty<'r>>::V,)>` for `L<[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:39]>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>