jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: expected `;`, found `5.0` --> $DIR/issue-103425.rs:2:6 | LL |     3 |      ^ help: add `;` here LL | LL |     5.0 |     --- unexpected token error: expected `;`, found `3_i8` --> $DIR/issue-103425.rs:8:10 | LL |     2_u32 |          ^ help: add `;` here LL | LL |     3_i8 |     ---- unexpected token error: expected `;`, found `5.0` --> $DIR/issue-103425.rs:10:9 | LL |     3_i8 |         ^ help: add `;` here LL | LL |     5.0 |     --- unexpected token error: aborting due to 3 previous errors </ins>

Discussion:
Given the following code (): The current output is: What is this second error trying to tell me? What did it expect to be unit type and why? Does it make sense for this error to be emitted despite the first error correctly identifying my problem? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's trying to tell you nothing in particular. This is a bug, due to the fact that we eat the token and replace it with , so the "fixed" body ends up being:
That theory doesn't seem right to me, for two reasons: I would expect eating the to result in a type error like "expected because of return type", but the actual error involves integer and unit. Repeating the missing-semi error results in repeating the type error as well, even though it's all within one function. : gives two missing-semi errors and two type errors:
The error is reported at this point Then it's considered as recovered, and the are reported at type anlysising phase. Should we treat it as unrecovered, or make the dummy so that type anlysising won't report error messages?
claim
please first understand what the AST doing on the semicolon recovery path, then once that's done, you can probably try to make it recover like: properly so it type-checks correctly.
Change:
let helper = |rhs: &Rvalue<'tcx>, place: &Place<'tcx>, variant_index: &VariantIdx, <ins> switch_value: u128, </ins> side_to_choose| { let place_type = place.ty(self.body, self.tcx).ty; let adt = match *place_type.kind() { ty::Adt(adt, _) if adt.is_enum() => adt, _ => return StatementEquality::NotEqual, }; <ins> // We need to make sure that the switch value that targets the bb with // SetDiscriminant is the same as the variant discriminant. let variant_discr = adt.discriminant_for_variant(self.tcx, *variant_index).val; if variant_discr != switch_value { trace!( "NO: variant discriminant {} does not equal switch value {}", variant_discr, switch_value ); return StatementEquality::NotEqual; } </ins> let variant_is_fieldless = adt.variants[*variant_index].fields.is_empty(); if !variant_is_fieldless { trace!("NO: variant {:?} was not fieldless", variant_index);

Discussion:
Originally found by when experimenting with discriminants starting from 1 in modify labels: +regression-from-stable-to-stable +I-unsound
After a quick it appears that the regression appear with Rust 1.48.0
A bisection seems to lead to , nightly 2020-09-26 from to
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Looks like it is mostly likely caused by which is supposed to cc
Change:
/// Basic usage: /// /// ``` <del> /// # #![feature(slice_iter_mut_as_slice)] </del> /// let mut slice: &mut [usize] = &mut [1, 2, 3]; /// /// // First, we get the iterator:

Discussion:
This issue tracks stabilization for 2 methods in : -
If this feature is accepted, they should implement as well.
Good point, I didn't notice that already implements . Another candidate that could is , and maybe there are more to consider for completeness.
I actually didn't notice either until I went digging in for a totally separate issue. Will have a PR for that separately, although I won't include because it'd be instantly stable, and I'm not sure whether we want to guarantee that.
Is there a reason to not add asslicemut for these? Particularly IterMut, where it makes the iteration over mutable pairs nicer.
Only is sound, and that's offered at the moment. Otherwise, you can have multiple mutable borrows to the same spot in memory.
should be just as sound as here. It could not be , but that's true for & as well.
Yes, as long as it borrows from the itself, not its parameterized lifetime, should be fine. I guess for mutable pairs, you mean something like this?
Yeah, exactly that.
What is the status of this? Is anything required for stabilization other than someone to propose stabilization, make a stabilization PR, and FCP? In rowan, rust-analyzer's syntax tree backend, to remove unneeded allocations from syntax node cache hits. A simple patch that just does so via an arrayvec already sees a 5% improvement on rust-analyzer's main integration benchmark (not rowan's, and not purely parsing!), but being able to use the fact that already has a non-destructively-iterable array backing would make even that collect/copy unnecessary.
One of thse (vec::Drain::as_slice) is already stabilized. As for the other one: we discussed this tracking issue in the libs meeting, and would be happy to see a stabilization PR.
Change:
"slice" => Some(PrimitiveType::Slice), "tuple" => Some(PrimitiveType::Tuple), "pointer" => Some(PrimitiveType::RawPointer), <ins> "reference" => Some(PrimitiveType::Reference), </ins> _ => None, } }

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
<ins> error[E0423]: expected value, found struct `X` --> $DIR/issue-61226.rs:3:10 | LL |     vec![X]; //… |          ^ did you mean `X { /* fields */ }`? error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>

Discussion:
When I used the character in comment, combined with some (invalid) code preceding it, the compiler panicked. I tried this code: I expected to see this happen: rustc compiles this code. Instead, this happened: rustc panicked with the following output : Backtrace:
Regressed in 1.34.0. Used to be:
cc
Miminized: Probably some span handcrafting?
Probably some span handcrafting? +1
I was idly curious, so I took a brief look at this. The diagnostic that triggers this was introduced in , but I don't think it is responsible for the error (it's just stepping through characters looking for a closing brace). There is some strange math in  (introduced in ). It oscillates between zero-length and 1+ length spans as it is stepping over characters. When it hits a multi-byte character, it returns an invalid span. Example: Starting with a span of (0,1), using would result in (1,1), then (1,2), then (2,2), then (2,4). That last one slices into the middle of the multi-byte character (because of , where width is 3), causing a panic. I'm not familiar enough with this stuff to say how it should behave. It seems like is being used for two different purposes (getting the next zero-length span, and getting the "next" character), and it's not clear to me what the behavior should be since it is used in a variety of places. I don't think it can be changed to always return zero-length spans, and it can't be changed to always return non-zero length spans. Perhaps there should be two different functions?
triage: P-medium, removing nomination; the ICE to me appears to include enough information for a user to identify the offending character and work-around the problem (namely by getting rid of the character). I do agree with that there should probably be two distinct functions corresponding to the two distinct purposes that they identified for the current callers of .
More test cases have been brought up in
I guess this is the same bug, but the examples I've seen here concern non-ASCII characters in comments. I'm getting a similar rustc panic from an erroneous code without comments: Compilation attempt:
Please file a new issue and reference this one.
I think it's fixed, try .
confirmed fixed by .
Change:
assert_eq!(string.clone().into_boxed_slice().into_string(), string); } <ins> #[test] fn test_box_slice_clone() { let data = String::from("hello HELLO hello HELLO yes YES 5 中ä华!!!"); let data2 = data.clone().into_boxed_slice().clone().into_string(); assert_eq!(data, data2); } </ins> mod pattern { use std::str::pattern::Pattern; use std::str::pattern::{Searcher, ReverseSearcher};

Discussion:
Just like , Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple ptr::copy of the data. Follow up after
Change:
use std::mem; <del> use crate::clean::{cfg::Cfg, AttributesExt, NestedAttributesExt}; </del> <ins> use crate::clean::{cfg::Cfg, AttributesExt, NestedAttributesExt, OneLevelVisitor}; </ins> use crate::core; /// This module is used to store stuff from Rust's AST in a more convenient

Discussion:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.
Change:
<ins> // compile-flags: -Zvalidate-mir // check-pass // Check that we don't cause cycle errors when validating pre-`Reveal::All` MIR // that assigns opaques through normalized projections. #![feature(impl_trait_in_assoc_type)] struct Bar; trait Trait { type Assoc; fn foo() -> Foo; } impl Trait for Bar { type Assoc = impl std::fmt::Debug; fn foo() -> Foo where Self::Assoc:, { let x: <Bar as Trait>::Assoc = (); Foo { field: () } } } struct Foo { field: <Bar as Trait>::Assoc, } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
&lt;!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This ices since by but I dont see any of the error messages which is weird
ICE happens before any of those error messages would be fired. I'll fix it later.
Change:
//! then mean that all later passes would have to check for these figments //! and report an error, and it just seems like more mess in the end.) <del> use super::writeback::Resolver; </del> use super::FnCtxt; use crate::expr_use_visitor as euv;

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. --Removing allows the code to compile successfully. <!-- 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 --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
self.tcx.sess.span_err(self.span, &msg); return true; } <del> // `Self` here is the same `TyAnon`, so skip it to avoid infinite recursion for subst in trait_ref.substs.iter().skip(1) { </del> <ins> for subst in trait_ref.substs.iter() { // Skip repeated `TyAnon`s to avoid infinite recursion. if let UnpackedKind::Type(ty) = subst.unpack() { if let ty::TyAnon(def_id, ..) = ty.sty { if !self.visited_anon_tys.insert(def_id) { continue; } } } </ins> if subst.visit_with(self) { return true; }

Discussion:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.
Change:
pub fn variant_range(&self, def_id: DefId, tcx: TyCtxt<'tcx>) -> Range<VariantIdx> { // FIXME requires optimized MIR let num_variants = tcx.generator_layout(def_id).variant_fields.len(); <del> (VariantIdx::new(0)..VariantIdx::new(num_variants)) </del> <ins> VariantIdx::new(0)..VariantIdx::new(num_variants) </ins> } /// The discriminant for the given variant. Panics if the `variant_index` is

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
match ty.kind { TyKind::BareFn(ref bfty) => { self.check_fn_decl(&bfty.decl, SelfSemantic::No); <del> Self::check_decl_no_pat(&bfty.decl, |span, _| { </del> <ins> Self::check_decl_no_pat(&bfty.decl, |span, _, _| { </ins> struct_span_err!( self.session, span,

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
// that the discriminant has been initialized. self.walk_expr(discr); } <ins> Ok(()) </ins> } fn walk_local<F>(

Discussion:
<details</summary</details<!-- 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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
// aux-build:nounwind.rs // compile-flags: -C no-prepopulate-passes -C panic=abort -C metadata=a // ignore-windows <ins> // ignore-android </ins> #![crate_type = "lib"]

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
if let hir::ExprKind::Index(ref base, ref index) = e.kind { let mut tables = self.fcx.tables.borrow_mut(); <del> // All valid indexing looks like this; might encounter non-valid indexes at this point if let ty::Ref(_, base_ty, _) = tables.expr_ty_adjusted(&base).kind { let index_ty = tables.expr_ty_adjusted(&index); </del> <ins> // All valid indexing looks like this; might encounter non-valid indexes at this point. let base_ty = tables.expr_ty_adjusted_opt(&base).map(|t| &t.kind); if base_ty.is_none() { // When encountering `return [0][0]` outside of a `fn` body we can encounter a base // that isn't in the type table. We assume more relevant errors have already been // emitted, so we delay an ICE if none have. (#64638) self.tcx().sess.delay_span_bug(e.span, &format!("bad base: `{:?}`", base)); } if let Some(ty::Ref(_, base_ty, _)) = base_ty { let index_ty = tables.expr_ty_adjusted_opt(&index).unwrap_or_else(|| { // When encountering `return [0][0]` outside of a `fn` body we would attempt // to access an unexistend index. We assume that more relevant errors will // already have been emitted, so we only gate on this with an ICE if no // error has been emitted. (#64638) self.tcx().sess.delay_span_bug( e.span, &format!("bad index {:?} for base: `{:?}`", index, base), ); self.fcx.tcx.types.err }); </ins> let index_ty = self.fcx.resolve_vars_if_possible(&index_ty); if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize {

Discussion:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.
Change:
// (*) ok to skip binders, because wf code is prepared for it match *predicate { ty::Predicate::Trait(ref t) => { <del> wf.compute_trait_ref(&t.skip_binder().trait_ref); // (*) </del> <ins> wf.compute_trait_ref(&t.skip_binder().trait_ref, Elaborate::None); // (*) </ins> } ty::Predicate::Equate(ref t) => { wf.compute(t.skip_binder().0);

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
// except according to those terms. <del> use driver::session::Session; </del> use middle::def::*; <del> use middle::resolve; </del> use middle::ty; use middle::typeck; use util::ppaux; use syntax::ast::*; <del> use syntax::{ast_util, ast_map}; </del> <ins> use syntax::ast_util; </ins> use syntax::visit::Visitor; use syntax::visit;

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.