jiebi/CodeConvo huggingface dataset:
Change:
debug!("generator_interior: attempting to record type {:?} {:?} {:?} {:?}", ty, scope, expr, source_span); let live_across_yield = scope.map(|s| { self.region_scope_tree.yield_in_scope(s).and_then(|yield_data| { // If we are recording an expression that is the last yield

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)
Change:
.any(|predicate| { match predicate { ty::Predicate::Trait(ref trait_pred) if trait_pred.def_id() == sized_def_id => { <del> is_self(trait_pred.0.self_ty()) </del> <ins> trait_pred.0.self_ty().is_self() </ins> } ty::Predicate::Projection(..) | ty::Predicate::Trait(..) |

Discussion:
Attempting to compile the following with my  crate yields an ICE: Output from
Reduced:
I'm able to reproduce this exact same error on stable and nightly today using this 8 line example:
Change:
} visit::walk_expr(v, e); } <del> struct CheckItemRecursionVisitor<'a, 'ast: 'a> { root_it: &'a Item, sess: &'a Session, ast_map: &'a ast_map::Map<'ast>, def_map: &'a resolve::DefMap, idstack: Vec<NodeId> } // Make sure a const item doesn't recursively refer to itself // FIXME: Should use the dependency graph when it's available (#1356) pub fn check_item_recursion<'a>(sess: &'a Session, ast_map: &'a ast_map::Map, def_map: &'a resolve::DefMap, it: &'a Item) { let mut visitor = CheckItemRecursionVisitor { root_it: it, sess: sess, ast_map: ast_map, def_map: def_map, idstack: Vec::new() }; visitor.visit_item(it); } impl<'a, 'ast, 'v> Visitor<'v> for CheckItemRecursionVisitor<'a, 'ast> { fn visit_item(&mut self, it: &Item) { if self.idstack.iter().any(|x| x == &(it.id)) { self.sess.span_fatal(self.root_it.span, "recursive constant"); } self.idstack.push(it.id); visit::walk_item(self, it); self.idstack.pop(); } fn visit_expr(&mut self, e: &Expr) { match e.node { ExprPath(..) => { match self.def_map.borrow().find(&e.id) { Some(&DefStatic(def_id, _)) if ast_util::is_local(def_id) => { self.visit_item(&*self.ast_map.expect_item(def_id.node)); } _ => () } }, _ => () } visit::walk_expr(self, e); } } </del>

Discussion:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.
Change:
} } <del> fn walk_callee(&mut self, call: &hir::Expr<'_>, callee: &hir::Expr<'_>) { let callee_ty = return_if_err!(self.mc.expr_ty_adjusted(callee)); debug!("walk_callee: callee={:?} callee_ty={:?}", callee, callee_ty); match callee_ty.kind { ty::FnDef(..) | ty::FnPtr(_) => { self.consume_expr(callee); } ty::Error => {} _ => { if let Some(def_id) = self.mc.tables.type_dependent_def_id(call.hir_id) { match OverloadedCallType::from_method_id(self.tcx(), def_id) { FnMutOverloadedCall => { self.borrow_expr(callee, ty::MutBorrow); } FnOverloadedCall => { self.borrow_expr(callee, ty::ImmBorrow); } FnOnceOverloadedCall => self.consume_expr(callee), } } else { self.tcx() .sess .delay_span_bug(call.span, "no type-dependent def for overloaded call"); } } } } </del> fn walk_stmt(&mut self, stmt: &hir::Stmt<'_>) { match stmt.kind { hir::StmtKind::Local(ref local) => {

Discussion:
Problematic code: Minimal reproduction: This ICE happens on both nightly and stable. rustc 1.42.0-nightly ( 2020-01-06) binary: rustc commit-hash: commit-date: 2020-01-06 host: x86_64-unknown-linux-gnu release: 1.42.0-nightly LLVM version: 9.0 Backtrace:
I'm not sure how to reproduce the ICE given the two snippets at the top. Can you clarify the minimal reproduction: how do I reproduce it in the playground?
Simplified:
The failure occurs here: I guess we can add to first arm (), is it safe?
triage: P-high. Removing I-nominated label.
Change:
//! //! where `&.T` and `*T` are references of either mutability, //! and where unsize_kind(`T`) is the kind of the unsize info <del> //! in `T` - a vtable or a length (or `()` if `T: Sized`). </del> <ins> //! in `T` - the vtable for a trait definition (e.g. `fmt::Display` or //! `Iterator`, not `Iterator<Item=u8>`) or a length (or `()` if `T: Sized`). //! //! Note that lengths are not adjusted when casting raw slices - //! `T: *const [u16] as *const [u8]` creates a slice that only includes //! half of the original memory. </ins> //! //! Casting is not transitive, that is, even if `e as U1 as U2` is a valid //! expression, `e as U2` is not necessarily so (in fact it will only be valid if

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
let lval = Lvalue::new("expr::trans_def"); DatumBlock::new(bcx, Datum::new(val, const_ty, LvalueExpr(lval))) } <del> Def::Const(_) => { </del> <ins> Def::Const(_) | Def::AssociatedConst(_) => { </ins> bcx.sess().span_bug(ref_expr.span, "constant expression should not reach expr::trans_def") }

Discussion:
The following code produces an internal compiler error when compiled with rustc 1.8.0-nightly (2016-01-27) through the Rust playground: Here's a sample of the error output from the playground: The error occurs regardless of the type of the array's elements. The error seems to be related to the type of array constructor used, since the following code compiles just fine: The error does not occur when associated constants are not involved: Now with backtrace!
Change:
Some(Style::HeaderMsg), ); <del> // Render the replacements for each suggestion let suggestions = suggestion.splice_lines(&**sm); </del> let mut row_num = 2; let mut notice_capitalization = false; for (complete, parts, only_capitalization) in suggestions.iter().take(MAX_SUGGESTIONS) {

Discussion:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.
Change:
}, false, ); <del> } </del> } <del> }); </del> <ins> } }); </ins> if ctxt.may_break { // If we can break from the block, then the block's exit is always reachable

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
impl Drop for TtyWatcher { fn drop(&mut self) { <del> let _m = self.fire_homing_missile(); self.close_async_(); </del> <ins> if !self.tty.is_null() { let _m = self.fire_homing_missile(); self.close_async_(); } </ins> } }

Discussion:
I'm on OSX 10.8.4, x8664, latest Rust on master. And to head off any concerns about my file handle limits: I ran into this when stress-testing my web sockets library. After just a couple hundred connections, some connections were being refused at random. The only thing I could see was some output with saying . I've come up with a smaller test case that brings this out with some spectacular errors: Fails less often with 100-200 connections. The errors are different every time I run this with . Here's the end of one run: Another: Another: And lastly:
cc
Oh dear that's bad, thanks for the small issue! I will definitely investigate.
What is the result of though? Just calling is only the maximum file size (unless OSX is different).
you're right! So I set it to a higher value and things seem fine now. Sorry about that. Though, It's still a surprising way for the runtime to fail, and clearly something is still wrong there.
Despite OSX having small file descriptor limits, this is a serious bug that I'd like to address with the runtime. Something funny is going on.
With applied, I am unable to reproduce this on OSX. I am not convinced that it fixes anything, but I'm no longer seeing any scary assertions.
I take that back, I was using , not (silly me)
I attempted to debug this issue on linux, and I quickly ran into two problems. The first is an assertion fixed by , and the other is filed as Sadly none of this seems related to the assertions on OSX, so I'll continue to investigate there. If only OSX still had valgrind...
Change:
{ PartitionState::Crates } else { <del> PartitionState::Other </del> <ins> // First we check if the previous attribute was "complete"... if !mod_attr_pending.is_empty() { // If not, then we append the new line into the pending attribute to check // if this time it's complete... mod_attr_pending.push_str(line); if !trimline.is_empty() && check_if_attr_is_complete(line, edition) { // If it's complete, then we can clear the pending content. mod_attr_pending.clear(); } // In any case, this is considered as `PartitionState::Attrs` so it's // prepended before rustdoc's inserts. PartitionState::Attrs } else { PartitionState::Other } </ins> }; } PartitionState::Crates => {

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
} Err(err) => return Err(err), }; let ty = if self.eat(&token::Semi) { <del> TyKind::Array(elt_ty, self.parse_anon_const_expr()?) </del> <ins> let mut length = self.parse_anon_const_expr()?; if let Err(e) = self.expect(&token::CloseDelim(token::Bracket)) { // Try to recover from `X<Y, ...>` when `X::<Y, ...>` works self.check_mistyped_turbofish_with_multiple_type_params(e, &mut length.value)?; self.expect(&token::CloseDelim(token::Bracket))?; } TyKind::Array(elt_ty, length) </ins> } else { <ins> self.expect(&token::CloseDelim(token::Bracket))?; </ins> TyKind::Slice(elt_ty) }; <del> self.expect(&token::CloseDelim(token::Bracket))?; </del> Ok(ty) }

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should mention that the user needs to use a turbofish here: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the help message seems to only be missing if there are 2 const arguments: using type parameters or just one const param causes a useful help message
claim
It turns out 's repro is different than the original repro. My PR fixes 's examples but not the original one. I'll update it to fix the original one too.
All fixed.
Change:
<del> Subproject commit c807fbc8ba41432388b6f590668ba81314c07c32 </del> <ins> Subproject commit d9e38f57c125c5ac50397ec8a006fe49f17cd96c </ins>

Discussion:
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.
Change:
<ins> error[E0277]: the size for values of type `(dyn Trait + 'static)` cannot be known at compilation time --> $DIR/assoc_type_bounds_implicit_sized.rs:8:17 | LL |     type Item = dyn Trait; |                 ^^^^^^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `(dyn Trait + 'static)` note: required by a bound in `TraitWithAType::Item` --> $DIR/assoc_type_bounds_implicit_sized.rs:3:5 | LL |     type Item; |     ^^^^^^^^^^ required by this bound in `TraitWithAType::Item` help: consider relaxing the implicit `Sized` restriction | LL |     type Item: ?Sized; |              ++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: A similar error message with an unsized generic type argument does mention the implicit bound. Unfortunately, it also doesn't explain the implicit bound up front in the "required by this bound" text. (It mentions it when suggesting to relax the implicit bound, but I think it would be better to mention it up front as well.) Both error messages could benefit from changing the "required by this bound" text to "required by an implicit bound". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-associated-items +A-traits +A-typesystem +D-papercut +D-terse
I'm working on a pull request for this issue. claim
Oh! Very sorry, if you spent too much time on this already, but I have done some work around this already in If you want, you can take over it and bring it to completion, there are some cases, like that still need to be addressed and I haven't yet figured out. Alternatively, if you can find a way to accomplish the same result without touching the and instead deal only with a new , that would be preferable to my approach.
I've pushed what I have so far to , sorry if it conflicts with stuff you've already done. If you'd like to take a look at it, that would be great. I'll take a look at what you have as well. There are some issues to be worked out with conflicting suggestions for associated types for vs the existing suggestion for adding an explicit to a trait's bounds, in test cases such as within a trait declaration.
Change:
let _ = write!(self.out, "{bits:x}_"); } <ins> // Handle `str` as partial support for unsized constants ty::Str => { let tcx = self.tcx(); // HACK(jaic1): hide the `str` type behind a reference // for the following transformation from valtree to raw bytes let ref_ty = Ty::new_imm_ref(tcx, tcx.lifetimes.re_static, ct_ty); let slice = valtree.try_to_raw_bytes(tcx, ref_ty).unwrap_or_else(|| { bug!("expected to get raw bytes from valtree {:?} for type {:}", valtree, ct_ty) }); let s = std::str::from_utf8(slice).expect("non utf8 str from MIR interpreter"); // "e" for str as a basic type self.push("e"); // FIXME(eddyb) use a specialized hex-encoding loop. for byte in s.bytes() { let _ = write!(self.out, "{byte:02x}"); } self.push("_"); } </ins> // FIXME(valtrees): Remove the special case for `str` // here and fully support unsized constants. <del> ty::Ref(_, inner_ty, mutbl) => { </del> <ins> ty::Ref(_, _, mutbl) => { </ins> self.push(match mutbl { hir::Mutability::Not => "R", hir::Mutability::Mut => "Q", }); <del> match inner_ty.kind() { ty::Str if mutbl.is_not() => { let slice = valtree.try_to_raw_bytes(self.tcx(), ct_ty).unwrap_or_else(|| { bug!( "expected to get raw bytes from valtree {:?} for type {:}", valtree, ct_ty ) }); let s = std::str::from_utf8(slice).expect("non utf8 str from MIR interpreter"); self.push("e"); // FIXME(eddyb) use a specialized hex-encoding loop. for byte in s.bytes() { let _ = write!(self.out, "{byte:02x}"); } self.push("_"); } _ => { let pointee_ty = ct_ty .builtin_deref(true) .expect("tried to dereference on non-ptr type"); let dereferenced_const = ty::Const::new_value(self.tcx, valtree, pointee_ty); dereferenced_const.print(self)?; } } </del> <ins> let pointee_ty = ct_ty.builtin_deref(true).expect("tried to dereference on non-ptr type"); let dereferenced_const = ty::Const::new_value(self.tcx, valtree, pointee_ty); dereferenced_const.print(self)?; </ins> } ty::Array(..) | ty::Tuple(..) | ty::Adt(..) | ty::Slice(_) => {

Discussion:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2023-05-04 Regression in Regression in
I tracked this down to the fact that implicitly sets : I can reproduce with just on its own, without . Conversely, if I modify the wrapper function to pretend that coverage is always off, then the problem still occurs. So I believe this is actually an incompatibility between and v0 symbol mangling.
claim
With , the original code causing the ICE should be updated as:
Also the label for this issue should be replaced with . Cc
Change:
demand::eqtype(fcx, self.call_expr.span, self_arg_ty, method_arg_ty); } <ins> let nilty = ty::mk_nil(fcx.tcx()); </ins> demand::eqtype(fcx, self.call_expr.span, <del> method_sig.output.unwrap(), self.fn_sig.output.unwrap()); </del> <ins> method_sig.output.unwrap_or(nilty), self.fn_sig.output.unwrap_or(nilty)); </ins> write_overloaded_call_method_map(fcx, self.call_expr, method_callee); }

Discussion:
Compiler panics, when closure marked as diverging. I tried this code: I expected to see this happen: Instead, this happened: : Backtrace:
Change:
<ins> error[E0747]: type provided when a constant was expected --> $DIR/kind_mismatch.rs:11:38 | LL | impl<K> ContainsKey<K> for KeyHolder<K> {} |      -                               ^ |      | |      help: consider changing this type parameter to a const parameter: `const K: u8` error[E0747]: type provided when a constant was expected --> $DIR/kind_mismatch.rs:11:21 | LL | impl<K> ContainsKey<K> for KeyHolder<K> {} |      -              ^ |      | |      help: consider changing this type parameter to a const parameter: `const K: u8` error[E0277]: the trait bound `KeyHolder<0>: SubsetExcept<_>` is not satisfied --> $DIR/kind_mismatch.rs:22:45 | LL |     let map: KeyHolder<0> = remove_key::<_, _>(); |                                             ^ the trait `ContainsKey<0>` is not implemented for `KeyHolder<0>`, which is required by `KeyHolder<0>: SubsetExcept<_>` | note: required for `KeyHolder<0>` to implement `SubsetExcept<_>` --> $DIR/kind_mismatch.rs:15:28 | LL | impl<P, T: ContainsKey<0>> SubsetExcept<P> for T {} |            --------------  ^^^^^^^^^^^^^^^     ^ |            | |            unsatisfied trait bound introduced here note: required by a bound in `remove_key` --> $DIR/kind_mismatch.rs:17:25 | LL | pub fn remove_key<K, S: SubsetExcept<K>>() -> S { |                         ^^^^^^^^^^^^^^^ required by this bound in `remove_key` error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0747. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil', 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to
Minimized further:
Is related? Current ICE-loc: Issue-'s ICE-loc:
cc PR author
Change:
.starts_with(&original_method_ident.name.to_string()) }) .map(|ident| format!("{}()", ident)) <ins> .peekable() </ins> }); <del> if let Some(suggestions) = opt_suggestions { err.span_suggestions( path_segment.ident.span, &format!("use mutable method"), suggestions, Applicability::MaybeIncorrect, ); </del> <ins> if let Some(mut suggestions) = opt_suggestions { if suggestions.peek().is_some() { err.span_suggestions( path_segment.ident.span, &format!("use mutable method"), suggestions, Applicability::MaybeIncorrect, ); } </ins> } } };

Discussion:
Code that generated this error is available here: I am happy to spend some time trying to create a smaller repro but it will take me a few days. This error is reproducible on my machine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FYI, with this code compiled.
Minimized: Similar error was reported in . The issue is in code that attempts to suggest a different method, that might potentially return items. In that particular case there are no other suggestions to make, but code will attempt to emit diagnostic anyway, eventually failing the assertion: label: +E-easy
claim
label +regression-from-stable-to-beta
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium