jiebi/CodeConvo huggingface dataset:
Change:
<ins> //! ICE test #124348 //! We should not be running const eval if the layout has errors. enum Eek { TheConst, UnusedByTheConst(Sum), //~^ ERROR cannot find type `Sum` in this scope } const fn foo() { let x: &'static [Eek] = &[]; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
<ins> error: incorrect function inside `extern` block --> $DIR/issue-74120-lowering-of-ffi-block-bodies.rs:7:8 | LL |   extern "C" { |   ---------- `extern` blocks define existing foreign functions and functions inside of them cannot have a body LL |       fn f() { |  ________^___- | |        | | |        cannot have a body LL | | LL | |         fn g() {} LL | |     } | |_____- help: remove the invalid body: `;` | = help: you might have meant to write a function accessible through FFI, which can be done by writing `extern fn` outside of the `extern` block = note: for more information, visit https://doc.rust-lang.org/std/keyword.extern.html 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. --: Also occurs on nightly at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Semicolon is not the main problem here. Standalone semicolons are allowed as items inside function body. Second function definition would be OK if not for the extern "C" block — AFAIK only function declarations are allowed there, so is not valid syntax.
Prioritized as as per .7B.3B.60)
claim
A possibly clearer repro:
glacier ""
The previous issue has been fixed, let's try again (sorry for the noise!). glacier ""
Change:
<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] #![crate_name = "foo"] // @has 'foo/struct.Foo.html' pub struct Foo; // There are 3 impl blocks with public item and one that should not be displayed // because it only contains private items. // @count - '//*[@class="impl has-srclink"]' 'impl Foo' 3 // Impl block only containing private items should not be displayed. /// Private impl Foo { const BAR: u32 = 0; type FOO = i32; fn hello() {} } // But if any element of the impl block is public, it should be displayed. /// Not private impl Foo { pub const BAR: u32 = 0; type FOO = i32; fn hello() {} } /// Not private impl Foo { const BAR: u32 = 0; pub type FOO = i32; fn hello() {} } /// Not private impl Foo { const BAR: u32 = 0; type FOO = i32; pub fn hello() {} } </ins>

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
<ins> // run-rustfix // See https://github.com/rust-lang/rust/issues/87955 #![deny(rust_2021_incompatible_closure_captures)] //~^ NOTE: the lint level is defined here fn main() { let a = ("hey".to_string(), "123".to_string()); let _ = || { let _ = &a; dbg!(a.0) }; //~^ ERROR: drop order //~| NOTE: only captures `a.0` //~| NOTE: for more information, see //~| HELP: add a dummy let to cause `a` to be fully captured } //~^ NOTE: dropped here </ins>

Discussion:
produces: It expanded the macro. This only happens when the macro invocation is the entire body of the closure.
cc
Working on a fix.
Change:
.tcx .associated_items(impl_def_id) .in_definition_order() <del> .map(|x| clean_middle_assoc_item(x, cx)) </del> <ins> .filter(|item| !item.is_impl_trait_in_trait()) .map(|item| clean_middle_assoc_item(item, cx)) </ins> .collect::<Vec<_>>(), polarity: ty::ImplPolarity::Positive, kind: ImplKind::Blanket(Box::new(clean_middle_ty(

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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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 --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
<ins> // run-rustfix mod test { public const X: i32 = 123; //~^ ERROR expected one of `!` or `::`, found keyword `const` } fn main() { println!("{}", test::X); } </ins>

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.

Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection
Change:
} } <del> fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool { </del> <ins> pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool { </ins> let ident_token: Token = Ident(ident, is_raw); !ident_token.is_reserved_ident() ||

Discussion:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `
Change:
where T: TypeFoldable<TyCtxt<'tcx>>, { <del> let old_universe = self.infcx.universe(); </del> let (instantiated, _) = self.infcx.instantiate_canonical_with_fresh_inference_vars(span, canonical); <del> for u in (old_universe + 1)..=self.infcx.universe() { self.borrowck_context.constraints.universe_causes.insert(u, UniverseInfo::other()); } </del> instantiated }

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. --Does not happen with this callback: <!-- 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
The code snippet is incomplete: is there a repository available that we could try, to reproduce the error? If not, could you at least add the full function? Thanks!
Rust use tungstenite::handshake::server::{Response, ErrorResponse}; fn acceptconnection(stream: TcpStream, config: rustls::server::ServerConfig) -Result<Socket{ let mut conn = rustls::server::ServerConnection::new(std::sync::Arc::new(()))?; let tlsstream = rustls::StreamOwned::new(conn, stream.tryclone()?); if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, -std::result::Result<Response, ErrorResponse{ let callback = -std::result::Result<tungstenite::handshake::server::Response, tungstenite::handshake::server::ErrorResponse{ dbg!(&req); dbg!(&res); Ok(res) }; if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, callback, None) { Err(HandshakeError::Interrupted(midhandshake)) ={ info!( "Handshake interrupted with peer {} - waiting to try again.", peer_addr ); Ok(Socket::Interrupted(midhandshake)) } Err(e) ={ error!("Error accepting secure websocket connection: {e}"); Err(e)? } Ok(ws) =Ok(Socket::SecureWebSocket(ws)), } } }
This is still incomplete and doesn't parse. Do you have a repository where the issue can be reproduced?
No repo. You can make it parse pretty easily. I am not a rustc expert but I believe the issue was with the callback.
Here's a small (but not minimal yet) working repro: and with that we can finally bisect, to : probably that (no need to ping anyone here) I'll minimize next to remove this dependency and create an MCVE.
removed:
Probably not yet an MCVE and could be further simplified, but getting close.

62 error -1.63 error + ice
WG-prioritization assigning priority (). label -I-prioritize +P-medium -E-needs-mcve
Change:
<ins> error[E0308]: mismatched types --> $DIR/const-argument-cross-crate-mismatch.rs:6:41 | LL |     let _ = const_generic_lib::function(const_generic_lib::Struct([0u8, 1u8])); |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `3usize`, found `2usize` | = note: expected type `const_generic_lib::Struct<3usize>` found type `const_generic_lib::Struct<_: usize>` error[E0308]: mismatched types --> $DIR/const-argument-cross-crate-mismatch.rs:8:39 | LL |     let _: const_generic_lib::Alias = const_generic_lib::Struct([0u8, 1u8, 2u8]); |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `2usize`, found `3usize` | = note: expected type `const_generic_lib::Struct<2usize>` found type `const_generic_lib::Struct<_: usize>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
<ins> error[E0308]: mismatched types --> $DIR/const-argument-cross-crate-mismatch.rs:6:41 | LL |     let _ = const_generic_lib::function(const_generic_lib::Struct([0u8, 1u8])); |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `3usize`, found `2usize` | = note: expected type `const_generic_lib::Struct<3usize>` found type `const_generic_lib::Struct<_: usize>` error[E0308]: mismatched types --> $DIR/const-argument-cross-crate-mismatch.rs:8:39 | LL |     let _: const_generic_lib::Alias = const_generic_lib::Struct([0u8, 1u8, 2u8]); |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `2usize`, found `3usize` | = note: expected type `const_generic_lib::Struct<2usize>` found type `const_generic_lib::Struct<_: usize>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
use rustc_ast::expand::allocator::AllocatorKind; use rustc_data_structures::svh::Svh; use rustc_hir as hir; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::{CrateNum, DefId, DefIdMap, CRATE_DEF_INDEX, LOCAL_CRATE}; use rustc_hir::definitions::{DefKey, DefPath, DefPathHash}; use rustc_middle::hir::exports::Export;

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:
<ins> error[E0308]: mismatched types --> $DIR/brackets-to-braces-single-element.rs:1:24 | LL | const A: [&str; 1] = { "hello" }; |                        ^^^^^^^ expected array `[&'static str; 1]`, found `&str` | help: to create an array, use square brackets instead of curly braces | LL | const A: [&str; 1] = [ "hello" ]; |                      ~         ~ error[E0308]: mismatched types --> $DIR/brackets-to-braces-single-element.rs:4:19 | LL | const B: &[u32] = &{ 1 }; |                   ^^^^^^ expected slice `[u32]`, found integer | = note: expected reference `&'static [u32]` found reference `&{integer}` help: to create an array, use square brackets instead of curly braces | LL | const B: &[u32] = &[ 1 ]; |                    ~   ~ error[E0308]: mismatched types --> $DIR/brackets-to-braces-single-element.rs:7:27 | LL | const C: &&[u32; 1] = &&{ 1 }; |                           ^ expected array `[u32; 1]`, found integer | help: to create an array, use square brackets instead of curly braces | LL | const C: &&[u32; 1] = &&[ 1 ]; |                         ~   ~ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
<del> Subproject commit 965160d4d7976ddead182b4a65b73f59818537de </del> <ins> Subproject commit fd0dccd4b12169e0aac42aff8addbb26b6d72197 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Change:
<ins> error[E0271]: type mismatch resolving `<() as Bar>::Foo == ()` --> $DIR/issue-63355.rs:34:20 | LL | pub type FooImpl = impl Foo; |                    -------- the found opaque type LL | pub type BarImpl = impl Bar<Foo = FooImpl>; |                    ^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found opaque type | = note: expected unit type `()` found opaque type `impl Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
() changing into inside will successfully compile
modify labels: A-impl-trait, F-typealiasimpl_trait, C-bug, I-ICE, T-compiler, requires-nightly
Source: <details<summaryStack trace</summary<p</p</detailsregression in nightly-2019-08-04 Auto merge of - Centril:sound-bind-by-move, r=matthewjasper Auto merge of - pietroalbini:move-azure-pipelines, r=Mark-Simulacrum Auto merge of - Centril:rollup-h9t731z, r=Centril Auto merge of - RalfJung:miritypedispatch_first, r=oli-obk Auto merge of - varkor:trait-alias-impl-trait, r=Centril Auto merge of - Centril:rollup-x39p5ga, r=Centril
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Though the error seems incorrect, in I don't see where it is getting the obligation from, nowhere does the code assert that is true.
This example should be disallowed with but is not. I filed to cover that.
I agree with that the behavior here is a bug, I don't think we handle appearing in these sorts of contexts very well, at least within the defining module.
Thanks for triaging, we still should add a regression test to prevent ICE at least, right?
Yep, that's good
Change:
Err(e) => { // Parsing failed, therefore it must be something more serious // than just a missing separator. <ins> for xx in &e.children { // propagate the help message from sub error 'e' to main error 'expect_err; expect_err.children.push(xx.clone()); } </ins> expect_err.emit(); e.cancel();

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim