jiebi/CodeConvo huggingface dataset:
Code 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; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Related discussion:
text: I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently
Code 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; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Related discussion:
text: I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:
Code 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; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Related discussion:
text: Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case
Code 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; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Related discussion:
text: Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()
Code 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; fn main() { || if let Foo::NotEvenReal() = Foo {}; //~ ERROR E0599 } </ins>

Related discussion:
text: Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search
Code change:
#[diag(parse_use_eq_instead)] pub(crate) struct UseEqInstead { #[primary_span] <ins> #[suggestion(style = "verbose", applicability = "machine-applicable", code = "=")] </ins> pub span: Span, <del> #[suggestion(style = "verbose", applicability = "machine-applicable", code = "")] pub suggestion: Span, </del> } #[derive(Diagnostic)]

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code 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. trait Foo { const AMT: usize; } enum Bar<A, B> { First(A), Second(B), } impl<A: Foo, B: Foo> Foo for Bar<A, B> { const AMT: usize = [A::AMT][(A::AMT > B::AMT) as usize]; //~ ERROR constant evaluation } impl Foo for u8 { const AMT: usize = 1; } impl Foo for u16 { const AMT: usize = 2; } fn main() { println!("{}", <Bar<u16, u8> as Foo>::AMT); } </ins>

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.
Code 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. trait Foo { const AMT: usize; } enum Bar<A, B> { First(A), Second(B), } impl<A: Foo, B: Foo> Foo for Bar<A, B> { const AMT: usize = [A::AMT][(A::AMT > B::AMT) as usize]; //~ ERROR constant evaluation } impl Foo for u8 { const AMT: usize = 1; } impl Foo for u16 { const AMT: usize = 2; } fn main() { println!("{}", <Bar<u16, u8> as Foo>::AMT); } </ins>

Related discussion:
text: Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .
Code 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. trait Foo { const AMT: usize; } enum Bar<A, B> { First(A), Second(B), } impl<A: Foo, B: Foo> Foo for Bar<A, B> { const AMT: usize = [A::AMT][(A::AMT > B::AMT) as usize]; //~ ERROR constant evaluation } impl Foo for u8 { const AMT: usize = 1; } impl Foo for u16 { const AMT: usize = 2; } fn main() { println!("{}", <Bar<u16, u8> as Foo>::AMT); } </ins>

Related discussion:
text: Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details
Code change:
use crate::build::{BlockAnd, BlockAndExtension, Builder}; use crate::build::{GuardFrame, GuardFrameLocal, LocalsForNode}; use crate::hair::{self, *}; <del> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; </del> <ins> use rustc_data_structures::{fx::{FxHashMap, FxHashSet}, stack::ensure_sufficient_stack}; </ins> use rustc_hir::HirId; use rustc_index::bit_set::BitSet; use rustc_middle::middle::region;

Related discussion:
text: I just tried the latest nightly (rustc 1.45.0-nightly ( 2020-06-01)) and noticed it can't compile one of the crates I work on. The crate does have an enum with a a huge number of variants (almost 6000), for which I use serde to derive Serialize and Deserialize. When building, even with just 'cargo check', the build fails with It works on stable 1.43.1. I tried running rustc under gdb. It didn't crash exactly the same way, I got SIGSEGV instead. Looking at the callstack in gdb, it is suspiciously deep ( functions deep). The top most functions are: If I reduce the number of enum variants to 5000, or stop using serde to derive Serialize/Deserialize, it starts working again. Since it works using stable, but not using nightly, I thought it might be some kind of regression. I totally realize this may not be a bug and that what I'm doing (Serde + giant enum) is just not a good idea. Accept my apologies if this kind of thing shouldn't be reported here!
cc -- I believe should have fixed this but I guess we're missing at least this case?
As an experiment I tried doubling the number of enum variants and compiling using stable. That still worked. So it seems the code wasn't just on the brink to stop working using the stable compiler.
Here is a github repo with a minimized test case for this issue:
It introduced a mechanism for dealing with this kind of issue, but I don’t doubt that we might have missed instances where the compiler is doing something recursive. MIR construction for matches appears to be one of these cases.
Yeah, that's what I expected, I just recalled seeing some commentary suggesting that we'd perhaps covered all cases. Definitely not unexpected that we didn't, though, nor did I intend to imply we should have :)
The beta seems to not have the problem. The problem does not occur with "rustc 1.44.0-beta.4 ( 2020-05-23)".
I saw the 'E-needs-mcve'-tag. Did you see my repro-case? (but maybe you're talking about something more self-contained, not referencing 'serde'?)
Code change:
use crate::build::{BlockAnd, BlockAndExtension, Builder}; use crate::build::{GuardFrame, GuardFrameLocal, LocalsForNode}; use crate::hair::{self, *}; <del> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; </del> <ins> use rustc_data_structures::{fx::{FxHashMap, FxHashSet}, stack::ensure_sufficient_stack}; </ins> use rustc_hir::HirId; use rustc_index::bit_set::BitSet; use rustc_middle::middle::region;

Related discussion:
text: I saw the repo, but it still needs some work to be reduced to a viable regression test case that could be included into the repo along with fix. This is what I’m working on now as I already have the fix itself.
Assigning .
If anyone else gets here having the same problem, manually implementing Serialize and Deserialize rather than relying on serde-derive, is one way around the problem. I adapted the examples at for my enum and this made the compile time insignificant. It also improved performance using the old rust considerably.
Mhh, I remember having seen some other issues related to derive macros recently... cc who might know.
Code change:
<ins> //@ check-pass //@ edition: 2021 #![feature(async_closure)] // Make sure that we don't hit a query cycle when validating // the by-move coroutine body for an async closure. use std::future::Future; async fn test<Fut: Future>(operation: impl Fn() -> Fut) { operation().await; } pub async fn orchestrate_simple_crud() { test(async || async {}.await).await; } fn main() {} </ins>

Related discussion:
text: Originally posted at and filing this upon request from . We're using nightly rust and as of nightly-2024-08-29 (prior to this it compiled fine) we see the following error: Function being flagged can be viewed at . We're having a bit of a hard time debugging this issue, it's not very clear what this actually means. I've tried looking at the HIR output but it didn't really help and I'm a bit lost on this one as I'm not familiar with MIR. I expected to see this happen: Compilation succeed. Instead, this happened: Compilation failed due to MIR cycle. : Backtrace contained no extra information.
this kind of looks like it should be an ICE instead? :thinking:
I'll try to put up a fix. It's due to (not that you need to understand what that PR does), not your fault.
For now, though, you'll need to either stop using closures (since you've got an bound, not ; why are you using closures over just , since those don't really buy you anything in this case?) or pin your nightly compiler version until I can minimize this and fix it.
Minimized: To reproduce: (Odd that the "optimization" also happens in debug builds.) Of note: During the minimization process, rust-analyzer froze multiple times. And a few times, also froze.
you're awesome! thanks for the minimization.
Thanks for confirming. We were having a lot of issues with lifetimes when using the async blocks which lead to us using async closures instead. Possibly we should just revisit that...
You might be interested in these two links for an explanation on how exactly async closures differ from a closure that returns an async block: https://rust-
Thanks I'll take a look at those.
Code change:
<ins> //@ aux-build:implied-predicates.rs //@ check-pass extern crate implied_predicates; use implied_predicates::Bar; fn bar<B: Bar>() {} fn main() {} </ins>

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry
Code change:
} code, pre, h1.fqn { <del> font-family: Menlo, Monaco, Consolas, "Inconsolata", "Courier New", monospace; </del> <ins> font-family: "Inconsolata", Menlo, Monaco, Consolas, "DejaVu Sans Mono", monospace; </ins> } code, pre { color: #333;

Related discussion:
text: It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.
Code change:
<ins> // Copyright 2016 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. // aux-build:issue-30535.rs extern crate issue_30535 as foo; fn bar( _: foo::Foo::FooV //~ ERROR value `foo::Foo::FooV` used as a type ) {} fn main() {} </ins>

Related discussion:
text: rustc crashes when compiling the following source code. I expect this to compile or report error. Instead the compiler crashed.
Reduced testcase:
This also causes an ICE with the latest nightly:
Any update on the issue. Please let me know if you need more information. Thanks
Code change:
message.push_str(&format!(" ({})", feature)); <del> if let Some(unstable_reason) = reason { let mut ids = cx.id_map.borrow_mut(); message = format!( "<details><summary>{}</summary>{}</details>", message, MarkdownHtml( &unstable_reason.as_str(), &mut ids, error_codes, cx.shared.edition(), &cx.shared.playground, ) .into_string() ); } </del> extra_info.push(format!("<div class="stab unstable">{}</div>", message)); }

Related discussion:
text: Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.