jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0727]: `async` generators are not yet supported --> $DIR/async-generator-issue-67158.rs:5:13 | LL |     async { yield print!(":C") }; |             ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0727`. </ins>

Discussion:
This code () produces ICE on current beta and nightly
Tagging as P-medium and "triaged" for async-await. Note that yield is unstable.
the feature is nightly but the ice doesn't require any feature gate to trigger.
searched nightlies: from nightly-2019-01-01 to nightly-2020-02-01 regressed nightly: nightly-2019-09-29 searched commits: from to regressed commit: source code: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
thanks for the bisection! Annoyingly, it regressed in a rollup PR, which means there are many candidates: (Docs: slice elements are equidistant) -- (Include message on tests that should panic but do not) -- (Remove stray references to the old global tcx) -- (Remove unused DepTrackingMap) -- (Account for tail expressions when pointing at return type) -- (hir: Disallow on constants) -- (Fix divduration() marked as stable by mistake) -- (update rtpSpawn's parameters type(It's prototype has been updated in libc)) -- (Thou shallt not ) -- (Stabilize mapgetkeyvalue feature) -- ( fix links to primitives in documentation) -- (Upgrade envlogger to 0.7) -- (Add mailmap entry for Dustin Bensing by request) -- (check_match: improve diagnostics for with ) --
If I had to guess, I would guess (cc triggered this regression, but or are possibilities. I would guess because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE. If indeed I am correct, then this could be fixed by adding a call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).
Change:
let extra_lifetime_params = self.resolver.take_extra_lifetime_params(opaque_ty_node_id); debug!(?extra_lifetime_params); for (ident, outer_node_id, outer_res) in extra_lifetime_params { <del> let outer_def_id = self.local_def_id(outer_node_id); </del> <ins> let outer_def_id = self.orig_local_def_id(outer_node_id); </ins> let inner_node_id = self.next_node_id(); // Add a definition for the in scope lifetime def.

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
} } } <ins> /// If `kind` is a block that looks like `{ let result = $expr; result }` then /// returns $expr. Otherwise returns `kind`. fn look_in_block<'tcx, 'hir>(cx: &LateContext<'tcx>, kind: &'tcx ExprKind<'hir>) -> &'tcx ExprKind<'hir> { if_chain! { if let ExprKind::Block(block, _label @ None) = kind; if let Block { stmts: [Stmt { kind: StmtKind::Local(local), .. }], expr: Some(expr_end_of_block), rules: BlockCheckMode::DefaultBlock, .. } = block; // Find id of the local that expr_end_of_block resolves to if let ExprKind::Path(QPath::Resolved(None, expr_path)) = expr_end_of_block.kind; if let Res::Local(expr_res) = expr_path.res; if let Some(Node::Binding(res_pat)) = cx.tcx.hir().find(expr_res); // Find id of the local we found in the block if let PatKind::Binding(BindingAnnotation::Unannotated, local_hir_id, _ident, None) = local.pat.kind; // If those two are the same hir id if res_pat.hir_id == local_hir_id; if let Some(init) = local.init; then { return &init.kind; } } kind } </ins>

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
<del> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //

Discussion:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.
Change:
use rt::rtio; use c_str::CString; use collections::HashMap; <ins> use hash::Hash; use clone::Clone; #[cfg(windows)] use std::hash::sip::SipState; </ins> /// Signal a process to exit, without forcibly killing it. Corresponds to /// SIGTERM on unix platforms.

Discussion:
The following program demonstrates the problem: When compiled and executed on WIndows, it randomly displays either 'foo' or 'BAR'. This happens because process::Command represents environment block as a HasMap<CString, CString, so it treats "foo" and "FOO" as different variables, whereas Windows considers them to be the same one. When child process is spawned, both get into the environment block, however Windows keeps only the last one.
Change:
) -> DiagnosticBuilder<'tcx> { let arg = self.resolve_vars_if_possible(arg); let arg_data = self.extract_inference_diagnostics_data(arg, None); <del> let kind_str = match arg.unpack() { GenericArgKind::Type(_) => "type", GenericArgKind::Const(_) => "the value", GenericArgKind::Lifetime(_) => bug!("unexpected lifetime"), }; </del> let mut local_visitor = FindHirNodeVisitor::new(&self, arg, span); let ty_to_string = |ty: Ty<'tcx>| -> String {

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
} is_feature_cfg |= best_match == sym::feature; <del> } else if !possibilities.is_empty() { let mut possibilities = possibilities.iter().map(Symbol::as_str).collect::<Vec<_>>(); possibilities.sort(); let possibilities = possibilities.join("`, `"); </del> <ins> } else { if !names_possibilities.is_empty() && names_possibilities.len() <= 3 { names_possibilities.sort(); for cfg_name in names_possibilities.iter() { db.span_suggestion( name_span, "found config with similar value", format!("{cfg_name} = "{name}""), Applicability::MaybeIncorrect, ); } } if !possibilities.is_empty() { let mut possibilities = possibilities.iter().map(Symbol::as_str).collect::<Vec<_>>(); possibilities.sort(); let possibilities = possibilities.join("`, `"); </ins> <del> // The list of expected names can be long (even by default) and // so the diagnostic produced can take a lot of space. To avoid // cloging the user output we only want to print that diagnostic // once. db.help_once(format!("expected names are: `{possibilities}`")); </del> <ins> // The list of expected names can be long (even by default) and // so the diagnostic produced can take a lot of space. To avoid // cloging the user output we only want to print that diagnostic // once. db.help_once(format!("expected names are: `{possibilities}`")); } </ins> } let inst = if let Some((value, _value_span)) = value {

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
RangeEnd::Excluded | RangeEnd::Included(_) => hir::RangeEnd::Included, } } <ins> /// Matches `'-' lit | lit (cf. parser::Parser::parse_literal_maybe_minus)`, /// or paths for ranges. // // FIXME: do we want to allow `expr -> pattern` conversion to create path expressions? // That means making this work: // // ```rust,ignore (FIXME) // struct S; // macro_rules! m { //     ($a:expr) => { //         let $a = S; //     } // } // m!(S); // ``` fn lower_expr_within_pat(&mut self, expr: &Expr, allow_paths: bool) -> &'hir hir::Expr<'hir> { match expr.kind { ExprKind::Lit(..) | ExprKind::ConstBlock(..) | ExprKind::Err => {} ExprKind::Path(..) if allow_paths => {} ExprKind::Unary(UnOp::Neg, ref inner) if matches!(inner.kind, ExprKind::Lit(_)) => {} _ => { self.diagnostic() .span_err(expr.span, "arbitrary expressions aren't allowed in patterns"); return self.arena.alloc(self.expr_err(expr.span)); } } self.lower_expr(expr) } </ins> }

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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
) } else { if overflow { <del> use rustc::mir::interpret::EvalErrorKind; </del> let err = EvalErrorKind::Overflow(op).into(); let _: Option<()> = self.use_ecx(source_info, |_| Err(err)); return None;

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
<ins> // Test that `wrapping_div` only checks divisor once. // This test checks that there is only a single compare agains -1 and -1 is not present as a // switch case (the second check present until rustc 1.12). // This test also verifies that a single panic call is generated (for the division by zero case). // compile-flags: -O #![crate_type = "lib"] // CHECK-LABEL: @f #[no_mangle] pub fn f(x: i32, y: i32) -> i32 { // CHECK-COUNT-1: icmp eq i32 %y, -1 // CHECK-COUNT-1: panic // CHECK-NOT: i32 -1, label x.wrapping_div(y) } </ins>

Discussion:
Gives: Specifically, .LBB07 is unreachable, but LLVM can't quite figure that out. It's probably possible to write wrappingdiv in a way which avoids this problem.
Not sure why LLVM doesn't optimise this more (the duplicated check of against -1 should be easy enough to handle), but the good news is that the MIR-driven code generator produces this ASM instead: Which is what is expected.
Currently generated code looks just fine to me. Fixed.
Still looks fine it seems: (latest stable)
Given this just needs a test, this could be transformed into an easy issue for newcomers.
Triage; not aware of any test . Still gives the good code when compiled.
Change:
<ins> error[E0606]: casting `&[_; 0]` as `*const Data` is invalid --> $DIR/unsized-struct-cast.rs:4:28 | LL |     const _: *const Data = &[] as *const Data; |                            ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0606`. </ins>

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. --: On playgrounds it seemed to affect and for , and . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like it also happens without the re-borrow, but with a different error. <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2021-11-14 found 7 bors merge commits in the specified range commit[0] 2021-11-12: Auto merge of - matthiaskrgr:rollup-ou6yrlw, r=matthiaskrgr commit[1] 2021-11-13: Auto merge of - workingjubilee:use-simd, r=MarkSimulacrum commit[2] 2021-11-13: Auto merge of - jfrimmel:rtcopychecks, r=Mark-Simulacrum commit[3] 2021-11-13: Auto merge of - mystor:expandliteral, r=petrochenkov commit[4] 2021-11-13: Auto merge of - the8472:privatize-the-means-of-rawvec-production, r=joshtriplett commit[5] 2021-11-13: Auto merge of - jhpratt:stabilize-constrawptrderef, r=oli-obk commit[6] 2021-11-13: Auto merge of - mfrw:mfrw/librustdoc, r=GuillaumeGomez ERROR: no CI builds available between and within last 167 days
Regression in nightly-2019-06-17 found 7 bors merge commits in the specified range commit[0] 2019-06-15: Auto merge of - RalfJung:cfg-if,

r=alexcrichton commit[1] 2019-06-16: Auto merge of - Centril:rollup-3p3m2fu, r=Centril commit[2] 2019-06-16: Auto merge of - matthewjasper:optimize-false-edges, r=pnkfelix commit[3] 2019-06-16: Auto merge of - chansuke:separate-unit-tests, r=petrochenkov commit[4] 2019-06-16: Auto merge of - nikomatsakis:trait-caching-perf-3, r=pnkfelix commit[5] 2019-06-16: Auto merge of - glaubitz:sparc64-ffi-abi, r=petrochenkov commit[6] 2019-06-16: Auto merge of - Centril:stabilize-underscoreconstnames, r=petrochenkov ERROR: no CI builds available between and within last 167 days
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This also returns ICE, but ICE message varies between rustc version.
Change:
// which makes this somewhat difficult and prevents us from just // using `self.path_inferred_arg_iter` here. hir::ExprKind::Struct(&hir::QPath::Resolved(_self_ty, path), _, _) <del> // FIXME(TaKO8Ki): Ideally we should support this. For that // we have to map back from the self type to the // type alias though. That's difficult. </del> <ins> // FIXME(TaKO8Ki): Ideally we should support other kinds, // such as `TyAlias` or `AssocTy`. For that we have to map // back from the self type to the type alias though. That's difficult. </ins> // // See the `need_type_info/issue-103053.rs` test for // a example. <del> if !matches!(path.res, Res::Def(DefKind::TyAlias, _)) => { </del> <ins> if matches!(path.res, Res::Def(DefKind::Struct | DefKind::Enum | DefKind::Union, _)) => { </ins> if let Some(ty) = self.opt_node_type(expr.hir_id) && let ty::Adt(_, args) = ty.kind() {

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!
Change:
<ins> // revisions: rpass1 rpass2 pub fn foo() { bar(); baz::<()>(); } fn bar() where <() as Table>::AllColumns:, { } fn baz<W>() where W: AsQuery, <W as AsQuery>::Query:, { } trait AsQuery { type Query; } trait UnimplementedTrait {} impl<T> AsQuery for T where T: UnimplementedTrait, { type Query = (); } struct Wrapper<Expr>(Expr); impl<Ret> AsQuery for Wrapper<Ret> { type Query = (); } impl AsQuery for () where Wrapper<<() as Table>::AllColumns>: AsQuery, { type Query = (); } trait Table { type AllColumns; } #[cfg(rpass1)] impl Table for () { type AllColumns = Checksum1; } #[cfg(rpass1)] struct Checksum1; #[cfg(rpass2)] impl Table for () { type AllColumns = Checksum2; } #[cfg(rpass2)] struct Checksum2; fn main() {} </ins>

Discussion:
Unfortunately I don't have a minimal reproduction for this () is the state of the repo at the time where it happened. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
also FWIW appears to work fine, but only causes the ICE
I can reproduce getting an ICE with
I’ve started some reduction work: (edit: there’s a full MCVE below; this fork will be deleted eventually) Interestingly, this reduced example’s ICE looks slightly different, I just noticed: <details<summary…click to show full output…</summary</details
Minimized: label -E-needs-mcve +S-bug-has-mcve <details<summaryfull reproduction instructions (e.g. if someone wants to add this to glacier), and backtrace</summaryin Then do Backtrace </details
Change:
#[export_name = "BAR"] static BAR: u32 = 3; <del> // CHECK: void @foo() </del> <ins> // CHECK: void @a() </ins> #[no_mangle] <del> pub extern fn foo() {} </del> <ins> pub extern fn a() {} </ins> <del> // CHECK: void @bar() #[export_name = "bar"] extern fn bar() {} </del> <ins> // CHECK: void @b() #[export_name = "b"] extern fn b() {} // CHECK: void @c() #[export_name = "c"] #[inline] extern fn c() {} // CHECK: void @d() #[export_name = "d"] #[inline(always)] extern fn d() {} </ins> }

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
// Parse the crate. let mut report = FormatReport::new(); let directory_ownership = input.to_directory_ownership(); <del> let krate = match Parser::parse_crate(input, &parse_session) { Ok(krate) => krate, // Surface parse error via Session (errors are merged there from report) Err(e) => { let forbid_verbose = input_is_stdin || e != ParserError::ParsePanicError; </del> <ins> // rustfmt doesn't use `run_compiler` like other tools, so it must emit any // stashed diagnostics itself, otherwise the `DiagCtxt` will assert when // dropped. The final result here combines the parsing result and the // `emit_stashed_diagnostics` result. let parse_res = Parser::parse_crate(input, &parse_session); let stashed_res = parse_session.emit_stashed_diagnostics(); let krate = match (parse_res, stashed_res) { (Ok(krate), None) => krate, (parse_res, _) => { // Surface parse error via Session (errors are merged there from report). let forbid_verbose = match parse_res { Err(e) if e != ParserError::ParsePanicError => true, _ => input_is_stdin, }; </ins> should_emit_verbose(forbid_verbose, config, || { eprintln!("The Rust parser panicked"); });

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
cc
Probably a duplicate of , and hopefully will be fixed by .
no, I checked, while is fixed, this one isn't :(