jiebi/CodeConvo huggingface dataset:
Change:
) -> Option<Const<'tcx>> { let span = source_info.span; match *rvalue { <del> // This branch exists for the sanity type check Rvalue::Use(Operand::Constant(ref c)) => { assert_eq!(c.ty, place_layout.ty); self.eval_constant(c, source_info) }, </del> Rvalue::Use(ref op) => { self.eval_operand(op, source_info) },

Discussion:
This code triggers this ICE with rustc 1.29.0-beta.2 ( 2018-08-05) but compiles fine with current stable 1.28.0:

Not sure if it's really something that is ever gonna happen in real code, but the following ICE's: <details<summaryBacktrace:</summary</details
Just figured out that declaring the existential type like this: won't panic. I guess because its being copied? But I think that it should not be allowed,
A version without transmutes and , but with pointer casts instead:
Change:
<ins> // run-pass #![feature(core_intrinsics)] #![feature(repr128)] #[repr(i128)] enum Big { A, B } fn main() { unsafe { println!("{} {:?}", std::intrinsics::discriminant_value(&Big::A), std::mem::discriminant(&Big::B)); } } </ins>

Discussion:
ICE occurs whether we use or . cc
The no longer ICEs.
this can be closed as it no longer ICEs.
Actually, presumably, E-needstest.
Change:
let body_id = hir.maybe_body_owned_by(def_id)?; let owner_id = hir.body_owner(body_id); <del> let fn_decl = hir.fn_decl_by_hir_id(owner_id).unwrap(); </del> <ins> let fn_decl = hir.fn_decl_by_hir_id(owner_id)?; </ins> let poly_fn_sig = tcx.fn_sig(id).instantiate_identity(); let fn_sig = tcx.liberate_late_bound_regions(id, poly_fn_sig);

Discussion:
The code below leads to the following compiler panic <details<summaryfull stderr</summary</details<details<summary<coderustc -Vv</code</summary</details label -needs-triage C-bug I-ICE T-compiler F-genericconstitems requires-incomplete-features claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
Change:
#[cfg(not(stage0))] #[cold] #[inline(never)] // this is the slow path, always #[lang="fail"] <del> fn fail(expr_file_line: &(&'static str, &'static str, uint)) -> ! { </del> <ins> pub fn fail(expr_file_line: &(&'static str, &'static str, uint)) -> ! { </ins> let (expr, file, line) = *expr_file_line; let ref file_line = (file, line); format_args!(|args| -> () {

Discussion:
These appear all the time and result in large code bloat. At least the file and line should be combined into a static.
Also, and result in inefficient codegen and code bloat because they call into the string formatter when they don't need to.
This seems to be done for . The macro in still uses the string formatter for all invocations, but I don't even know how to use those.
Change:
}) .flat_map(|b| predicates_from_bound(self, ty, b)); <ins> let param_def_id = self.tcx.hir().local_def_id(param_id).to_def_id(); </ins> let from_where_clauses = ast_generics .where_clause .predicates

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] trait If<const COND: bool> {} impl If<true> for () {} trait IsZero<const N: u8> { type Answer; } struct True; struct False; impl<const N: u8> IsZero<N> for () where (): If<{N == 0}> { //~ERROR constant expression type Answer = True; } trait Foobar<const N: u8> {} impl<const N: u8> Foobar<N> for () where (): IsZero<N, Answer = True> {} impl<const N: u8> Foobar<N> for () where (): IsZero<N, Answer = False> {} fn main() {} </ins>

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
<ins> // Copyright 2017 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. struct Foo; impl Foo { fn bar(&mut self) -> bool { true } } fn error(foo: &mut Foo) { if let Some(_) = Some(true) { } else if foo.bar() {} } fn ok(foo: &mut Foo) { if let Some(_) = Some(true) { } else { if foo.bar() {} } } fn main() {} </ins>

Discussion:
is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.
Change:
pat: &'tcx hir::Pat<'tcx>, ty: Ty<'tcx>, ) { <ins> struct V<'tcx> { tcx: TyCtxt<'tcx>, pat_hir_ids: Vec<hir::HirId>, } impl<'tcx> Visitor<'tcx> for V<'tcx> { type NestedFilter = rustc_middle::hir::nested_filter::All; fn nested_visit_map(&mut self) -> Self::Map { self.tcx.hir() } fn visit_pat(&mut self, p: &'tcx hir::Pat<'tcx>) { self.pat_hir_ids.push(p.hir_id); hir::intravisit::walk_pat(self, p); } } </ins> if let Err(guar) = ty.error_reported() { // Override the types everywhere with `err()` to avoid knock on errors. let err = Ty::new_error(self.tcx, guar); self.write_ty(hir_id, err); self.write_ty(pat.hir_id, err); <ins> let mut visitor = V { tcx: self.tcx, pat_hir_ids: vec![] }; hir::intravisit::walk_pat(&mut visitor, pat); // Mark all the subpatterns as `{type error}` as well. This allows errors for specific // subpatterns to be silenced. for hir_id in visitor.pat_hir_ids { self.write_ty(hir_id, err); } </ins> self.locals.borrow_mut().insert(hir_id, err); self.locals.borrow_mut().insert(pat.hir_id, err); }

Discussion:
It's underlining the wrong argument. No response No response
I'm getting an entirely different and much more helpful error:
Are you sure you minimized the code correctly? Not sure how to repro the example you shared,
Arf, sorry about that... Also important to note, I'm using: I pushed the code with this issue . However it requires a mac to enter this code. Just running is enough to trigger it.
This should be re-minimized by someone who has a Mac then. label +E-needs-mcve
Minimization: Note that: in all cases (including when I ran the original code), there is now a more sensible type error, and the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch. It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the , even though it's not the part of the tuple that has the type mismatch. Tested on versions:
label -E-needs-mcve
Change:
impl Error for alloc::collections::TryReserveError {} #[unstable(feature = "duration_checked_float", issue = "83400")] <del> impl Error for time::FromSecsError {} </del> <ins> impl Error for time::FromFloatSecsError {} </ins> // Copied from `any.rs`. impl dyn Error + 'static {

Discussion:
Hello. I am diagnosing why I've got a wrong duration computed from Duration::fromsecsf32()... I tried this code: I expected to see an exact 30-second duration. Instead, I've got this: which is: 30 seconds and 1024 nanos. I dig deeper into rust code and I've prepared a sample code which is computing it based on the source code: As the result I've got: Instead of exact 30 seconds and 0 nanos.
?
Works on current stable and nightly: I mean, that this issue exist for that versions.
yep, I also confirmed on:
What is interesting the function: fromsecsf64 doesn't seem to have this problem... so a quick workaround would be use it and cast from f32 to f64
Extending(?) f32 to u128 gives this addition in 1024:
CC: CC: Adding authors ... guys please take a quick look if you have a time...
f32 will naturally have trouble representing all possible nanosecond values and so doing calculations in f64 may help here somewhat. However the most appropriate approach would be to decompose the float into the whole part and the fractional part and then operate on the two separately to produce the values necessary to create the . and may work sufficiently well for the purpose. EDIT: I think we would still need to be careful about how the nanosecond fraction is handled. We cannot simply multiply the number by and then convert to an integer, because is not capable of representing integers of such degree losslessly.
We cannot simply multiply the number by and then convert to an integer, because f32 is not capable of representing integers of such degree losslessly. Small correction: is represented exactly by , the problem is with . The closest float is , which results in the 1024 ns error. For example, would have produced an exact value. I would say such loss of precision is expected for and if you want exact values, you should use the integer based methods. So I don't think this issue should be marked as a bug. It could be worthwhile to improve the code by processing the fractional part separately, but note that it will not solve this issue fundamentally. We still have the issue of mapping at most 23 fractional bits into ~30 bits, e.g. calling would still result in an inexact result.

specifically may be representable exactly, but f32 cannot represent all integers exactly. Though maybe its not a huge deal if after we end up roundtripping back to the actual integer in all cases.
Argh, I forgot that the method is not available on , so the linked PR will not work out of box. UPD: I have implemented manual fraction/exponent splitting and their conversion to integers.
Change:
} } <del> tool_doc!(Rustdoc, "rustdoc-tool", "src/tools/rustdoc", ["rustdoc", "rustdoc-json-types"]); </del> <ins> tool_doc!( Rustdoc, "rustdoc-tool", "src/tools/rustdoc", ["rustdoc", "rustdoc-json-types"], binary = false ); </ins> tool_doc!( Rustfmt, "rustfmt-nightly",

Discussion:
Compare to This is almost certainly caused by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // check-pass // only-x86_64 // Checks that the compiler does not actually try to allocate 4 TB during compilation and OOM crash. fn main() { [0; 4 * 1024 * 1024 * 1024 * 1024]; } </ins>

Discussion:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.
Change:
} visit::walk_ty(self, ty) } <ins> // A type may have an expression as a const generic argument. // We do not want to recurse into those. fn visit_expr(&mut self, _: &'a Expr) {} </ins> } let impl_self = self

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
Further reduced:
searched toolchains nightly-2023-01-26 through nightly-2023-04-28 Regression in nightly-2023-01-29 searched toolchains through Regression in cc
Are you sure? The linked PR does not touch parser nor lowering. It just touches typeck and what happens after it.

oh right, hm, I'm getting different results now, maybe I forgot to press ctrl+s on the bisection snippet... :upsidedownface: searched toolchains nightly-2022-07-14 through nightly-2023-04-28 Regression in nightly-2022-07-26 commit[0] 2022-07-24: Auto merge of - RalfJung:rollup-bojacrc, r=RalfJung commit[1] 2022-07-24: Auto merge of - fasterthanlime:ra-subtree-2, r=jyn514 commit[2] 2022-07-25: Auto merge of - AngelicosPhosphoros:improvecalloccheckinvecmacrofor_tuples, r=Mark-Simulacrum commit[3] 2022-07-25: Auto merge of - thomcc:dont-overwrite, r=tmiasko commit[4] 2022-07-25: Auto merge of - klensy:no-string-dupes-ugly, r=cjgillot commit[5] 2022-07-25: Auto merge of - tmiasko:subst-folder, r=petrochenkov commit[6] 2022-07-25: Auto merge of - JohnTitor:rollup-74rb8vq, r=JohnTitor commit[7] 2022-07-25: Auto merge of - csmoe:export-exe-sym, r=bjorn3 commit[8] 2022-07-25: Auto merge of - RalfJung:miri, r=RalfJung commit[9] 2022-07-25: Auto merge of - cjgillot:ast-lifetimes-anon, r=petrochenkov maybe ?
Change:
<ins> // aux-build:unstable-trait.rs #![crate_name = "foo"] #![feature(private_trait)] extern crate unstable_trait; // @has foo/struct.Foo.html 'bar' // @has foo/struct.Foo.html 'bar2' #[doc(inline)] pub use unstable_trait::Foo; </ins>

Discussion:
e.g., is missing the file/line/column method docs which are present in beta cc
Removing as this is issue.
Why?
A quick test indicates that copying the source of std::panic::Location out into a no_std crate doesn't fix the problem
Oh wait I don't have the latest nightly
As mentioned in , I'm not sure this should be prioritized under t-compiler's wg-prioritization. If this label is useful for the rustdoc team as well, we could tweak triagebot not to notify on Zulip.
Yeah it seems like it would be useful for us
Hmm so I am unable to reproduce this bug on a self contained no-core file that contains the exact code of aside for changes in the body
Regression range .. Auto merge of - Manishearth:rollup-9gxn4od, r=Manishearth Auto merge of - marmeladema:duration-consts-2, r=oli-obk Auto merge of - oli-obk:mir_const, r=RalfJung Auto merge of - Manishearth:rollup-i7iueu8, r=Manishearth Auto merge of - Manishearth:rollup-10vbpdh, r=Manishearth
Works in Regressing PR is
Rustdoc PRs in that rollup Rollup merge of - Manishearth:re-spotlight, r=GuillaumeGomez Rollup merge of - lzutao:rustdoc-tostring, r=GuillaumeGomez Rollup merge of - GuillaumeGomez:focus-source-file-sidebar, r=kinnison Rollup merge of - GuillaumeGomez:doc-alias-check, r=Manishearth Rollup merge of - euclio:rustdoc-highlighting, r=ollie27,GuillaumeGomez Rollup merge of - alexcrichton:ignore-unstable, r=estebank,GuillaumeGomez Rollup merge of - jyn514:name-resolve-first, r=eddyb
Confirmed, (try build from ) is the culprit
What's happening is that that code erroneously checks the stability of the impl, which apparently is "unstable if it contains unstable items". The "foreign item" check applies to libstd reexporting libcore. It shouldn't.

The minimal reproduction is two crates, one using stability attrs such that an impl has at least one unstable item, and the second crate reexporting the type.
I'm going to take a stab at fixing this.
Change:
self.push_comma(&mut values.0, &mut values.1, len, i); } <ins> // Do the same for const arguments, if they are equal, do not highlight and // elide them from the output. let const_arguments = sub1.consts().zip(sub2.consts()); for (i, (ca1, ca2)) in const_arguments.enumerate() { let i = i + consts_offset; if ca1 == ca2 { values.0.push_normal("_"); values.1.push_normal("_"); } else { values.0.push_highlighted(ca1.to_string()); values.1.push_highlighted(ca2.to_string()); } self.push_comma(&mut values.0, &mut values.1, len, i); } </ins> // Close the type argument bracket. // Only draw `<...>` if there're lifetime/type arguments. if len > 0 {

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
/// file they represent, just information about length, line breaks, and /// multibyte characters. This information is enough to generate valid debuginfo /// for items inlined from other crates. <ins> /// /// Proc macro crates don't currently export spans, so this function does not have /// to work for them. </ins> pub fn imported_source_files(&'a self, <del> local_source_map: &source_map::SourceMap) -> ReadGuard<'a, Vec<cstore::ImportedSourceFile>> { </del> <ins> local_source_map: &source_map::SourceMap) -> ReadGuard<'a, Vec<cstore::ImportedSourceFile>> { </ins> { let source_files = self.source_map_import_info.borrow(); if !source_files.is_empty() {

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
<ins> // Copyright 2015 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. pub trait Subscriber { type Input; } pub trait Processor: Subscriber<Input = <Self as Processor>::Input> { type Input; } fn main() {} </ins>

Discussion:
Example (reduced by from something reported on IRC):
Is that allowed syntax? As RFC 195 states . I tried to express something like but thought I have to wait until where clauses on associated type definitions land.
Nevermind, got it. Only is not in scope for the trait header, but is a path to it, so it is valid syntax. Keep up your excellent work :)
The code snippet above now causes the following error: Changing the trait to: yields
I'd like to nominate this, I don't think we can remove oldimplcheck without it.
This currently reports . The cycle can be broken by explicit UFCS notation: