jiebi/CodeConvo huggingface dataset:
Change:
use crate::util::storage::AlwaysLiveLocals; use super::MirPass; <del> use rustc_middle::mir::visit::{PlaceContext, Visitor}; </del> <ins> use rustc_middle::mir::{ interpret::Scalar, visit::{PlaceContext, Visitor}, }; </ins> use rustc_middle::mir::{ AggregateKind, BasicBlock, Body, BorrowKind, Local, Location, MirPhase, Operand, Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, VarDebugInfo, }; use rustc_middle::ty::relate::{Relate, RelateResult, TypeRelation}; use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt}; <ins> use rustc_target::abi::Size; </ins> #[derive(Copy, Clone, Debug)] enum EdgeKind {

Discussion:
Hypothetically we could have a we expect this not to happen, so this is an invariant of MIR that we can check cc
Change:
DepKind::GetPanicStrategy => { force!(panic_strategy, krate!()); } DepKind::IsNoBuiltins => { force!(is_no_builtins, krate!()); } DepKind::ImplDefaultness => { force!(impl_defaultness, def_id!()); } <ins> DepKind::CheckItemWellFormed => { force!(check_item_well_formed, def_id!()); } DepKind::CheckTraitItemWellFormed => { force!(check_trait_item_well_formed, def_id!()); } DepKind::CheckImplItemWellFormed => { force!(check_impl_item_well_formed, def_id!()); } </ins> DepKind::ReachableNonGenerics => { force!(reachable_non_generics, krate!()); } DepKind::NativeLibraries => { force!(native_libraries, krate!()); } DepKind::PluginRegistrarFn => { force!(plugin_registrar_fn, krate!()); }

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.
Change:
self.tcx.hir().local_def_id(md.hir_id) ).unwrap(); let mut module_id = self.tcx.hir().as_local_hir_id(macro_module_def_id).unwrap(); <ins> if !self.tcx.hir().is_hir_id_module(module_id) { // `module_id` doesn't correspond to a `mod`, return early (#63164). return; } </ins> let level = if md.vis.node.is_pub() { self.get(module_id) } else { None }; let new_level = self.update(md.hir_id, level); if new_level.is_none() { <del> return </del> <ins> return; </ins> } loop {

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
| = note: expected `async` block `{async block@$DIR/coroutine-desc.rs:10:9: 10:17}` found `async` block `{async block@$DIR/coroutine-desc.rs:10:19: 10:27}` <ins> = note: no two async blocks, even if identical, have the same type = help: consider pinning your async block and casting it to a trait object </ins> note: function defined here --> $DIR/coroutine-desc.rs:8:4 |

Discussion:
Especially for people new to async, this message is extremely opaque. There is not actually enough information to understand it unless you already know (a) that async blocks produce an anonymous future type and (b) that regardless of the type, those futures are always unique and incompatible types. The message sort of implies this (“found a different block”), but it is not actionable in any way. It is pretty easy to get here by reaching for (to pick just one easy example) . I ended up stumbling across it in the process of building up some sample code for the new async chapter in , and I had a moment at first! I have the time to help fix this, so if someone can point me in the right direction and help get it landed, I would be delighted to do the work. No response No response_
This seems like a good suggestion. I'd suggest tweaking the wording a bit, since I don't know that the implications of async blocks having unique types are immediately obvious. Maybe something like this?
labels +AsyncAwait-Triaged We discussed this in our async call and agreed that some improvement along these lines would be good. We could wordsmith it in the PR of course. (It'd be interesting too to add such diagnostics for closures and other similar cases.)
For reference, here's the error message for mismatched s (). Perhaps borrowing from this phrasing could be helpful here?
Change:
<ins> // edition:2018 // check-pass #![allow(dead_code)] async fn fail<'a, 'b, 'c>(_: &'static str) where 'a: 'c, 'b: 'c, {} async fn pass<'a, 'c, 'b>(_: &'static str) where 'a: 'c, 'b: 'c, {} async fn pass2<'a, 'b, 'c>(_: &'static str) where 'a: 'c, 'b: 'c, 'c: 'a, {} async fn pass3<'a, 'b, 'c>(_: &'static str) where 'a: 'b, 'b: 'c, 'c: 'a, {} fn main() { } </ins>

Discussion:
The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.
Change:
<del> error: internal compiler error: unexpected concrete region in borrowck: ReEarlyBound(0, 'a) --> $DIR/associated-type-lifetime-ice.rs:29:5 | LL | /     fn f() -> Self::ImplTrait { LL | | LL | |         () LL | |     } | |_____^ | = error: internal compiler error: unexpected panic query stack during panic: end of query stack </del>

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. --Minimized: also occurs for but not <!-- 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 on Rust Playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Somehow I missed that this does not require async. Also crashes with and returning .
minimized:
-- the minimization no longer ICEs for me
-- this sure looks like a dup of
After a discussion with Niko about this and assigning to myself we saw that there's already a PR. Unassigning myself then :).
Change:
<ins> error[E0433]: failed to resolve: expected type, found function `channel` in `mpsc` --> $DIR/issue-71406.rs:4:26 | LL |     let (tx, rx) = mpsc::channel::new(1); |                          ^^^^^^^ expected type, found function `channel` in `mpsc` error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- 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. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.
Change:
if let Some(ty) = self .cx .tcx <del> .normalize_erasing_regions(self.cx.param_env, ty) </del> <ins> .try_normalize_erasing_regions(self.cx.param_env, ty) .unwrap_or(ty) </ins> .visit_with(&mut ProhibitOpaqueTypes) .break_value() {

Discussion:
Create an empty crate, add to dependencies, and . [ ] Previous Stable [ ] Current Stable [X] Current Beta [X] Current Nightly Discovered on since 1.72.0-nightly ( 2023-07-03). The previous version 2023-07-02 is good. The breaking day is the same as . I suspect this is also related to . But fix to that does NOT fix this ICE though. cc The error message is similar to , but that occurs on an earlier version 2023-06-28. I guess it's unrelated.
label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
ProjectionElem::Field(field, _) => { trace!("field proj on {:?}", proj.base); let (base, ty, span) = self.eval_place(&proj.base)?; <del> match base { Value::ScalarPair(a, b) => { trace!("by val pair: {:?}, {:?}", a, b); let base_layout = self.tcx.layout_of(self.param_env.and(ty)).ok()?; trace!("layout computed"); use rustc_data_structures::indexed_vec::Idx; let field_index = field.index(); let val = [a, b][field_index]; let cx = LayoutCx { tcx: self.tcx, param_env: self.param_env, }; let field = base_layout.field(cx, field_index).ok()?; trace!("projection resulted in: {:?}", val); Some((Value::Scalar(val), field.ty, span)) }, _ => None, } </del> <ins> let valty = self.use_ecx(span, |this| { this.ecx.read_field(base, None, field, ty) })?; Some((valty.value, valty.ty, span)) </ins> }, _ => None, },

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
if_ok!(self.cat_pattern(subcmt, &**subpat, |x,y,z| op(x,y,z))); } } <del> Some(&def::DefFn(..)) | </del> Some(&def::DefStruct(..)) => { for (i, subpat) in subpats.iter().enumerate() { let subpat_ty = if_ok!(self.pat_ty(&**subpat)); // see (*2)

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
box-shadow: 0 0 8px 4px #078dd8; } <del> .module-item .stab { </del> <ins> .module-item .stab, .import-item .stab { </ins> color: #ddd; }

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
<ins> warning: the feature `adt_const_params` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/refs_check_const_eq-issue-88384.rs:4:12 | LL | #![feature(adt_const_params)] |            ^^^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information warning: 1 warning emitted </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. --Looks a bit like <!-- 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 --
Used as feature and got this: Regressed somewhere between ... <details<summaryBefore</summary</details<details<summaryAfter</summary</details
claim
Change:
}] }; <ins> struct S {} trait Tr { fn foo(); fn bar() { //~^ NOTE: ...not the enclosing function body [(); return]; //~^ ERROR: return statement outside of function body [E0572] //~| NOTE: the return is part of this body... } } impl Tr for S { fn foo() { //~^ NOTE: ...not the enclosing function body [(); return]; //~^ ERROR: return statement outside of function body [E0572] //~| NOTE: the return is part of this body... } } </ins> fn main() { //~^ NOTE: ...not the enclosing function body [(); return || {

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
// use nth(1) to skip one layer of desugaring from `IntoIter::into_iter` if let Some((_, hir::Node::Expr(await_expr))) = hir.parent_iter(*hir_id).nth(1) <del> && let Some(expr_span) = expr.span.find_ancestor_inside(await_expr.span) </del> <ins> && let Some(expr_span) = expr.span.find_ancestor_inside_same_ctxt(await_expr.span) </ins> { let removal_span = self .tcx

Discussion:
File: auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: 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
additional ices with &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;!-- 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
slightly more reduced
Change:
impl Flags { pub fn parse(args: &[String]) -> Flags { <ins> let (args, free_args) = if let Some(pos) = args.iter().position(|s| s == "--") { let (args, free) = args.split_at(pos); (args, Some(free[1..].to_vec())) } else { (args, None) }; </ins> let mut subcommand_help = String::from( " Usage: x.py <subcommand> [options] [<paths>...]

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
impl fmt::Debug for OwnerNodes<'_> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { f.debug_struct("OwnerNodes") <ins> // Do not print all the pointers to all the nodes, as it would be unreadable. </ins> .field("node", &self.nodes[ItemLocalId::from_u32(0)]) <ins> .field( "parents", &self .nodes .iter_enumerated() .map(|(id, parented_node)| (id, parented_node.as_ref().map(|node| node.parent))) .collect::<Vec<_>>(), ) </ins> .field("bodies", &self.bodies) .field("local_id_to_def_id", &self.local_id_to_def_id) .field("hash_without_bodies", &self.hash_without_bodies)

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: with rustc this runs in a couple ms: with rustc this seems to hang somewhere in ( I killed the process after waiting for 5 minutes :upsidedownface: )
reduced: RIP
I think this is caused by cc
Clearly a well tested feature :stuckouttongue: I'll take a look.
The old code looked like this: The new code looks like this: because is no longer optional. The infinite recursion happens because the call returns a that is the same as the . When I printed that ID out it looks like this: An easy fix is to check if is the same as and return if so. But I don't know if that's just papering over a deeper problem. Is it an underlying bug that can return the same node it is given?
Change:
<ins> error: incorrect number of parameters for the `start` lang item --> $DIR/issue-92157.rs:11:1 | LL | fn start<T>(_main: fn() -> T, _argc: isize, _argv: *const *const u8) -> isize { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the `start` lang item should have four parameters, but found 3 = note: the `start` lang item should have the signature `fn(fn() -> T, isize, *const *const u8, u8) -> isize` error: aborting due to previous error </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
A "fix" for that code is to add however I don't want to get an ICE but a nice error.
The error comes from I think. If you weren't using hitting this case would be a genuine bug in rustc. Turning it from an ICE into a nice error would require special casing integer types to not ICE here. In general you should expect to see internal compiler errors when you mess up with . In some cases it is feasible to give nice errors but I think this is not such a case.
Thanks! You may close if you think there is nothing you can do.
I am by no means familiar with the relevant code, but this would seem more like a basis for making this a than closing it entirely. As in, it would be nice if there was a way to fix this, but we don't know what it is and it's not really a priority.
Triage: Fixed since nightly-2023-01-04, marking as .
Change:
"src/tools/jsondocck", "src/tools/html-checker", "src/tools/bump-stage0", <ins> "src/tools/lld-wrapper", </ins> ] exclude = [

Discussion:
Checked that on target, found duplicates in versions: and <strikeno duplicates</strike2 duplicates (<strikeonly</strike, ) in stable , (bisecting is kinda slow on my connection) there 3 copies of that executable, that gives ~ 187mb label +regression-from-stable-to-beta
Can be found in:
I think they were in and . I believe is also a copy of .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
claim
Sorry, I only came across this issue just now. The copies are there for a reason, see linked issues. Multiple things to consider: The files in the directory are only used with the unstable option. So they could be removed for beta and stable. They can be replaced with small Rust executables which just exec and respectively. I will be working on that for nightly.
Change:
<ins> // Copyright 2018 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. // #47096 #![feature(slice_patterns)] fn foo(s: &[i32]) -> &[i32] { let &[ref xs..] = s; xs } fn main() { let x = [1, 2, 3]; let y = foo(&x); assert_eq!(x, y); } </ins>

Discussion:
Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with: