jiebi/CodeConvo huggingface dataset:
Change:
return variants; } <del> let rty = ty::node_id_to_type(ccx.tcx, id); </del> let hint = ty::lookup_repr_hint(ccx.tcx, ast::DefId { crate: ast::LOCAL_CRATE, node: id }); if hint != attr::ReprAny && vs.len() <= 1 { ccx.tcx.sess.span_err(sp, format!("unsupported representation for {}variant enum",

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
[[package]] name = "mdbook" <del> version = "0.4.14" </del> <ins> version = "0.4.15" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "f6e77253c46a90eb7e96b2807201dab941a4db5ea05eca5aaaf7027395f352b3" </del> <ins> checksum = "241f10687eb3b4e0634b3b4e423f97c5f1efbd69dc9522e24a8b94583eeec3c6" </ins> dependencies = [ "ammonia", "anyhow",

Discussion:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax
Change:
<ins> error: unknown start of token: u{2796} --> $DIR/suggest-remove-compount-assign-let-ice.rs:13:11 | LL |     let x ➖= 1; |           ^^ | help: Unicode character '➖' (Heavy Minus Sign) looks like '-' (Minus/Hyphen), but it is not | LL |     let x -= 1; |           ~ error: can't reassign to an uninitialized variable --> $DIR/suggest-remove-compount-assign-let-ice.rs:13:11 | LL |     let x ➖= 1; |           ^^^ | = help: if you meant to overwrite, remove the `let` binding help: initialize the variable | LL -     let x ➖= 1; LL +     let x = 1; | error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: 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: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.
Change:
assert_eq!(nonzero_fields.len(), 1); let nonzero_field = ty::lookup_field_type(tcx, did, nonzero_fields[0].id, substs); match nonzero_field.sty { <ins> ty::ty_ptr(ty::mt { ty, .. }) if !type_is_sized(tcx, ty) => { path.push_all(&[0, FAT_PTR_ADDR]); Some(path) }, </ins> ty::ty_ptr(..) | ty::ty_int(..) | ty::ty_uint(..) => { path.push(0); Some(path)

Discussion:
Given the following code: Rustc bails out on an LLVM assertion: Here's the stack: And here's the vitals: Playpen link that also fails on 2015-03-16:
/cc
Change:
<ins> //@ compile-flags: -Zvalidate-mir -Zinline-mir=yes #![feature(unboxed_closures)] use std::sync::Arc; pub struct WeakOnce<T>(); //~^ ERROR type parameter `T` is never used impl<T> WeakOnce<T> { extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} //~^ ERROR functions with the "rust-call" ABI must take a single non-self tuple argument //~| ERROR mismatched types pub fn get(&self) -> Arc<T> { self.try_get() .unwrap_or_else(|| panic!("Singleton {} not available", std::any::type_name::<T>())) } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' File: --auto-reduced (treereduce-rust): original: 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: Closure arguments are not passed as a tuple', 'error: internal compiler error: Closure arguments are not passed as a tuple' File: --auto-reduced (treereduce-rust): original: 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
This one also seems to be cc
Change:
InteriorOfTypeWithDestructor { container_ty: place_ty }, )); } <del> // move out of union - always move the entire union </del> ty::Adt(adt, _) if adt.is_union() => { <del> return Err(MoveError::UnionMove { path: base }); </del> <ins> union_path.get_or_insert(base); </ins> } ty::Slice(_) => { return Err(MoveError::cannot_move_out_of(

Discussion:
The following code ICEs, when it should produce a cannot move error
Worse, the following compiles:
regression from stable-to-beta and stable-to-nightly
triage: P-high
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct ConstString<const T: &'static str>; struct ConstBytes<const T: &'static [u8]>; pub fn main() { let _: ConstString<"Hello"> = ConstString::<"Hello">; let _: ConstString<"Hello"> = ConstString::<"World">; //~ ERROR mismatched types let _: ConstString<"ℇ㇈↦"> = ConstString::<"ℇ㇈↦">; let _: ConstString<"ℇ㇈↦"> = ConstString::<"ℇ㇈↥">; //~ ERROR mismatched types let _: ConstBytes<b"AAA"> = ConstBytes::<{&[0x41, 0x41, 0x41]}>; let _: ConstBytes<b"AAA"> = ConstBytes::<b"BBB">; //~ ERROR mismatched types } </ins>

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
/// # Examples /// /// ``` <del> /// #![feature(future_join, future_poll_fn)] </del> <ins> /// #![feature(future_join)] </ins> /// /// use std::future::join; ///

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR () [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should this be named instead? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial implementation in - closed as it's ambiguous, see the discussion on that PR
This exists in futures-lite, and people use it. It seems worth having available in the standard library. The naming discussion doesn't seem likely to change, and all else being equal there's a history for the name . Shall we stabilize this? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
There are some soundness issues with (not strictly speaking a soundness bug, but we might still want to do a breaking change now before there are too many people relying on this): the fact that is always is a problem. It should require for that. See for details, in particular .
I am proposing to change the impl in
Change:
<ins> error[E0271]: type mismatch resolving `for<'r> <L<[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:39]> as T0<'r, (<Unit2 as Ty<'r>>::V,)>>::O == <_ as Ty<'r>>::V` --> $DIR/issue-62203-hrtb-ice.rs:38:19 | LL |     let v = Unit2.m( |                   ^ expected struct `Unit4`, found associated type | = note: expected type `Unit4` found type `<_ as Ty<'_>>::V` error[E0271]: type mismatch resolving `<[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:39] as std::ops::FnOnce<((&u8,),)>>::Output == Unit3` --> $DIR/issue-62203-hrtb-ice.rs:38:19 | LL |     let v = Unit2.m( |                   ^ expected struct `Unit4`, found struct `Unit3` | = note: expected type `Unit4` found type `Unit3` = note: required because of the requirements on the impl of `for<'r> T0<'r, (<Unit2 as Ty<'r>>::V,)>` for `L<[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:39]>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
The following code results in an ICE on stable, beta, and nightly () Errors:
thanks to for providing a ICE appears to have been injected between 1.32.0 and 1.33.0. We could obviously use further bisection.
triage: P-high, removing nomination, marking needs-bisect, and assigning to self.
ICE was injected between nightly-2019-01-03 ( 2019-01-02) and nightly-2019-01-04 ( 2019-01-03). We did not have many PR's merged in that time frame, just these: Based on past experience, I'm guessing this is due to the Universes PR .
I'm going to take a shot at just turning the current call into a and see where that gets us.
Change:
let (first, last) = if kind_ord < arg_ord { (kind, arg.descr()) } else { (arg.descr(), kind) }; err.note(&format!("{} arguments must be provided before {} arguments", first, last)); <ins> if let Some(help) = help { err.help(help); } </ins> err.emit(); }

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
self.push_region_constraints(locations, category, data); } <ins> // If the query has created new universes and errors are going to be emitted, register the // cause of these new universes for improved diagnostics. </ins> let universe = self.infcx.universe(); <del> if old_universe != universe { let universe_info = match error_info { Some(error_info) => error_info.to_universe_info(old_universe), None => UniverseInfo::other(), }; </del> <ins> if old_universe != universe && let Some(error_info) = error_info { let universe_info = error_info.to_universe_info(old_universe); </ins> for u in (old_universe + 1)..=universe { self.borrowck_context.constraints.universe_causes.insert(u, universe_info.clone()); }

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> // Regression test for #110899. // When looking for the elided lifetime for `wrap`, // we must not consider the lifetimes in `bar` as candidates. fn wrap(self: Wrap<{ fn bar(&self) {} }>) -> &() { //~^ ERROR `self` parameter is only allowed in associated functions //~| ERROR `self` parameter is only allowed in associated functions //~| ERROR missing lifetime specifier //~| ERROR cannot find type `Wrap` in this scope &() } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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:
<del> Subproject commit 22c97b33e470d0b7c085e98417bef8b362d43d4e </del> <ins> Subproject commit 065ff89e33b67b3527fcdd56cf8b432e593e32d4 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
( FieldIdx::from_usize(parent_field_idx + num_args), parent_capture_ty, <del> needs_deref, </del> <ins> peel_deref, </ins> child_precise_captures, ), )

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' File: --auto-reduced (treereduce-rust): original: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is: