jiebi/CodeConvo huggingface dataset:
Change:
// the expected const's type. Specifically, we don't want const infer vars // to do any type shapeshifting before and after resolution. if let Err(guar) = compatible_types { <del> return Ok(self.tcx.const_error_with_guaranteed( if relation.a_is_expected() { a.ty() } else { b.ty() }, guar, )); </del> <ins> // HACK: equating both sides with `[const error]` eagerly prevents us // from leaving unconstrained inference vars during things like impl // matching in the solver. let a_error = self.tcx.const_error_with_guaranteed(a.ty(), guar); if let ty::ConstKind::Infer(InferConst::Var(vid)) = a.kind() { return self.unify_const_variable(vid, a_error); } let b_error = self.tcx.const_error_with_guaranteed(b.ty(), guar); if let ty::ConstKind::Infer(InferConst::Var(vid)) = b.kind() { return self.unify_const_variable(vid, b_error); } return Ok(if relation.a_is_expected() { a_error } else { b_error }); </ins> } match (a.kind(), b.kind()) {

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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
/// /// let p: *const i32 = ptr::null(); /// assert!(p.is_null()); <ins> /// assert_eq!(p as usize, 0); // this pointer has the address 0 </ins> /// ``` #[inline(always)] #[must_use]

Discussion:
This has come up in two places recently: and We should do the following: On , document that is equivalent to Either before or after it lands, update the text in to document that "allocated objects" cannot contain the 0 address (alternatively, if that PR lands with text that says that an allocated object cannot contain the "null" address, update the text to mention that null is equal to 0) Are there other places we should update too? cc
there was some discussion in https://rust-
Int-to-ptr casts are terrible, I'd rather not do that. In fact these two are not equivalent for Miri (but that might be a Miri limitation, int2ptr is just hard or impossible to handle precisely for a tool like Miri). We should say that it returns a pointer whose address is 0, but we shouldn't commit to which provenance it has.
adds the docs for this.
Change:
self.get_crate_data(def.krate).def_key(def.index) } <ins> fn def_kind(&self, def: DefId) -> DefKind { self.get_crate_data(def.krate).def_kind(def.index) } </ins> fn def_path(&self, def: DefId) -> DefPath { self.get_crate_data(def.krate).def_path(def.index) }

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
<del> error[E0433]: failed to resolve: `Self` is only available in impls, traits, and type definitions </del> <ins> error[E0433]: failed to resolve: `Self` cannot be used in imports </ins> --> $DIR/use-self-type.rs:7:16 | LL |         pub(in Self::f) struct Z; <del> |                ^^^^ `Self` is only available in impls, traits, and type definitions </del> <ins> |                ^^^^ `Self` cannot be used in imports </ins> error[E0432]: unresolved import `Self` --> $DIR/use-self-type.rs:6:13

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
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
span: Span, ) -> &'tcx Const<'tcx> { bad_placeholder_type(self.tcx(), vec![span]).emit(); <ins> // Typeck doesn't expect erased regions to be returned from `type_of`. let ty = self.tcx.fold_regions(ty, &mut false, |r, _| match r { ty::ReErased => self.tcx.lifetimes.re_static, _ => r, }); </ins> self.tcx().const_error(ty) }

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
} else { Async::No }; <del> if let Async::Yes { span, .. } = asyncness { // Feature-gate `async ||` closures. self.sess.gated_spans.gate(sym::async_closure, span); } </del> let capture_clause = self.parse_capture_clause(); let decl = self.parse_fn_block_decl()?;

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
run_lints!(cx, check_item, early_passes, it); cx.visit_ids(|v| v.visit_item(it)); ast_visit::walk_item(cx, it); <ins> run_lints!(cx, check_item_post, early_passes, it); </ins> }) }

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
let expected = ScalarMaybeUninit::from(Scalar::from_bool(*expected)); let value_const = self.ecx.read_scalar(value).unwrap(); if expected != value_const { <del> // Poison all places this operand references so that further code // doesn't use the invalid value match cond { Operand::Move(ref place) | Operand::Copy(ref place) => { Self::remove_const(&mut self.ecx, place.local); } Operand::Constant(_) => {} } </del> let mut eval_to_int = |op| { let op = self .eval_operand(op, source_info)

Discussion:
UPDATE: MCVE can be found . Nightly compilation error due to rustc bug I tried this code: I expected to see this happen: explanation Successful compilation. Instead, this happened: tells to report a bug, see backtrace. : Reproduce with (1st update) <details<summaryBacktrace</summary<p</p</details
cc
Also occured with
I'm getting this when I try to repro: On a side note, are there any cargo feature flags I can pass to cut down on how much stuff is being compiled? Compiling 900 crates to get a repo is quite a lot
Also occured with just now.
mmh try with commit hash ? (for )
updated script:
Yeah, sorry for that. One of the difficulties of working with a big framework like Substrate. I'll see if I can narrow it down more.
That did it! Thank you
Some with the same issue (a different chain also using Substrate) found out that apparently works.
Seems is the cause, marking as .
Here's a smaller repro (at least in terms of how much code is built: 33 crates instead of a few hundred):
just confirmed that it does not occur with
I have a minimal repro:
Wild guess: erases the local before we are able to emit the diagnostic message.
I seem to be getting a similar error again on a more current nightly (). Should I open a new issue or do we just reopen this one?
This is still broken. I'm pretty confused because running the test you in on the shows that it ICEs. Is the test not actually working for some reason? Edit: Does that test need in order to actually check the body of those functions since they are uncalled from ?
Assigning as and removing I-prioritize.
Hi and have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.
I've updated to rust version 1.47.0-nightly ( 2020-07-22), and tried compiling the crate which was triggering this ICE (). I no longer encounter an ICE, the crate compiles successfully.
I can confirm is not throwing ICE :+1:
Great, thank you!
Change:
find_opaque_ty_constraints_for_tait(tcx, def_id) } // Opaque types desugared from `impl Trait`. <del> ItemKind::OpaqueTy(OpaqueTy { origin: hir::OpaqueTyOrigin::FnReturn(owner) | hir::OpaqueTyOrigin::AsyncFn(owner), in_trait, .. }) => { </del> <ins> ItemKind::OpaqueTy(OpaqueTy { origin: hir::OpaqueTyOrigin::FnReturn(owner) | hir::OpaqueTyOrigin::AsyncFn(owner), in_trait, .. }) => { </ins> if in_trait { span_bug!(item.span, "impl-trait in trait has no default") } else {

Discussion:
The following code produces several ICEs on both beta and nightly (no necessary). <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details label F-genericassociatedtypes A-const-generics
This regressed in the last day...
Wait wrong issue
As GATs are stable on beta but not on stable, similar to : label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
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. #![feature(test)] extern crate test; use std::f64::{NAN, NEG_INFINITY, INFINITY, MAX}; use std::mem::size_of; use test::black_box; // Ensure the const-eval result and runtime result of float comparison are equivalent. macro_rules! compare { ($op:tt) => { compare!( [NEG_INFINITY, -MAX, -1.0, -0.0, 0.0, 1.0, MAX, INFINITY, NAN], $op ); }; ([$($lhs:expr),+], $op:tt) => { $(compare!( $lhs, $op, [NEG_INFINITY, -MAX, -1.0, -0.0, 0.0, 1.0, MAX, INFINITY, NAN] );)+ }; ($lhs:expr, $op:tt, [$($rhs:expr),+]) => { $({ // Wrap the check in its own function to reduce time needed to borrowck. fn check() { static CONST_EVAL: bool = $lhs $op $rhs; let runtime_eval = black_box($lhs) $op black_box($rhs); assert_eq!(CONST_EVAL, runtime_eval, stringify!($lhs $op $rhs)); assert_eq!( size_of::<[u8; ($lhs $op $rhs) as usize]>(), runtime_eval as usize, stringify!($lhs $op $rhs (forced const eval)) ); } check(); })+ }; } fn main() { assert_eq!(0.0/0.0 < 0.0/0.0, false); assert_eq!(0.0/0.0 > 0.0/0.0, false); assert_eq!(NAN < NAN, false); assert_eq!(NAN > NAN, false); compare!(==); compare!(!=); compare!(<); compare!(<=); compare!(>); compare!(>=); } </ins>

Discussion:
The following tests do not pass for me, but I think they should, as comparisons with NaN should always simply evaluate to : I get this result on both debug and release builds. I'm on an x86_64 running Linux, rustc 1.27.0-nightly ( 2018-05-15).
Playground link for this test. Affects both debug and release, Nightly and Stable.
: ~I think this is an issue with rather than the floating-point comparisons, but I haven't dug into it yet.~
This seems to be a regression introduced by 1.26.
Reduced, . Edit: Or maybe a bug in Miri (cc
Bisection between ... gives as the regression PR, as expected.
I guess this logic, which I blindly copied, was never correct to begin with: I think this is how old const eval did it, and we didn't want to regress that. cc
Has the comment about existing bad behaviour.
The old logic used unwrap, meaning would just ICE (?). I think we can safely replace them directly as etc. Edit: The unwrap is in
The incorrect behavior mentioned in was this: If we fix the float comparison behavior, this code will no longer compile. But I think this is clearly a bug fix and breaking code like this is .
Fixed in
Change:
<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/ice-118285-fn-ptr-value.rs:1:25 | LL | struct Checked<const F: fn(usize) -> bool>; |                         ^^^^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 1 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. --: The same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- 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 --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing
Change:
} StmtMac(ref m, _) => { // statement macro; might be an expr <del> let has_semi; </del> match self.token { token::SEMI => { <del> has_semi = true; </del> <ins> self.bump(); stmts.push(@codemap::Spanned { node: StmtMac((*m).clone(), true), span: stmt.span, }); </ins> } token::RBRACE => { // if a block ends in `m!(arg)` without // a `;`, it must be an expr <del> has_semi = false; </del> expr = Some( self.mk_mac_expr(stmt.span.lo, stmt.span.hi, m.node.clone())); } _ => { <del> has_semi = false; </del> stmts.push(stmt); } } <del> if has_semi { self.bump(); stmts.push(@codemap::Spanned { node: StmtMac((*m).clone(), true), span: stmt.span, }); } </del> } _ => { // all other kinds of statements: stmts.push(stmt);

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
} } <ins> fn type_error_message_str(@mut self, sp: span, mk_msg: &fn(Option<~str>, ~str) -> ~str, actual_ty: ~str, err: Option<&ty::type_err>) { self.type_error_message_str_with_expected(sp, mk_msg, None, actual_ty, err) } fn type_error_message_str_with_expected(@mut self, sp: span, mk_msg: &fn(Option<~str>, ~str) -> ~str, expected_ty: Option<ty::t>, actual_ty: ~str, err: Option<&ty::type_err>) { debug!("hi! expected_ty = %?, actual_ty = %s", expected_ty, actual_ty); </ins> <del> fn type_error_message_str(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ~str, err: Option<&ty::type_err>) { </del> let error_str = err.map_default(~"", |t_err| fmt!(" (%s)", ty::type_err_to_str(self.tcx, *t_err))); <del> self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(actual_ty), error_str)); for err.each |err| { ty::note_and_explain_type_err(self.tcx, *err) </del> <ins> let resolved_expected = expected_ty.map(|&e_ty| { self.resolve_type_vars_if_possible(e_ty) }); if !resolved_expected.map_default(false, |&e| { ty::type_is_error(e) }) { match resolved_expected { None => self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(None, actual_ty), error_str)), Some(e) => { self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(Some(self.ty_to_str(e)), actual_ty), error_str)); } } for err.each |err| { ty::note_and_explain_type_err(self.tcx, *err) } </ins> } } <del> fn type_error_message(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ty::t, err: Option<&ty::type_err>) { </del> <ins> fn type_error_message(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ty::t, err: Option<&ty::type_err>) { </ins> let actual_ty = self.resolve_type_vars_if_possible(actual_ty); // Don't report an error if actual type is ty_err.

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
let body_span = hir_body.value.span; let source_file = source_map.lookup_source_file(body_span.lo()); let fn_sig_span = match some_fn_sig.filter(|fn_sig| { <del> Lrc::ptr_eq(&source_file, &source_map.lookup_source_file(fn_sig.span.hi())) </del> <ins> fn_sig.span.ctxt() == body_span.ctxt() && Lrc::ptr_eq(&source_file, &source_map.lookup_source_file(fn_sig.span.hi())) </ins> }) { Some(fn_sig) => fn_sig.span.with_hi(body_span.lo()), None => body_span.shrink_to_lo(),

Discussion:
See below. Last nightly version that was known to work was 2021-04-19. Note that it says below but this is the version that installs as ! Similarly is the last known to work version but installed via as .
points at the following: searched nightlies: from nightly-2021-04-18 to nightly-2021-04-22 regressed nightly: nightly-2021-04-21 searched commits: from to regressed commit:
Because it was a small change, I have a guess about what I may need to check, but it would help to have an MCVE. I can't tell what code you're compiling that caused this. Can you provide a small example I can build locally? Thanks! cc:
By the way, where is the source for ? It looks like it is gone from github. I tried building , on the off chance that it might cause the same ICE with , but it built without issues.
We're having the same issue, if this helps: I'll see if I can get a minimal example
I don't have a minimal example, had no time to dig through the code yet to understand the problem. But you can easily reproduce it via
Ah! Thanks for providing the link to the source. I wasn't sure how to get it without access to the repo. Yes I can reproduce this. Looking into it now. Thanks!
Change:
<ins> // Copyright 2012 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. // compile-flags: -Z emit-end-regions -Z borrowck-mir fn ok() { loop { let _x = 1; } } fn fail() { loop { let x: i32; let _ = x + 1; //~ERROR (Ast) [E0381] //~^ ERROR (Mir) [E0381] } } fn main() { ok(); fail(); } </ins>

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it