Question:
Some Miri tests, e.g. , now ICE with This is a regression introduced by The likely cause is Cc
I removed "regression from stable" as Miri does not exist on stable.
Sorry, got it.

impl<'mir, 'tcx, Tag, Extra> Frame<'mir, 'tcx, Tag, Extra> { /// Return the `SourceInfo` of the current instruction. <del> pub fn current_source_info(&self) -> Option<mir::SourceInfo> { self.loc.map(|loc| { let block = &self.body.basic_blocks()[loc.block]; if loc.statement_index < block.statements.len() { block.statements[loc.statement_index].source_info } else { block.terminator().source_info } }) </del> <ins> pub fn current_source_info(&self) -> Option<&mir::SourceInfo> { self.loc.map(|loc| self.body.source_info(loc)) </ins> } }


Question:
Some Miri tests, e.g. , now ICE with This is a regression introduced by The likely cause is Cc
I removed "regression from stable" as Miri does not exist on stable.
Sorry, got it.

}) // Assert that there is always such a frame. .unwrap(); <ins> // Assert that the frame we look at is actually executing code currently // (`current_source_info` is None when we are unwinding and the frame does // not require cleanup). </ins> let loc = frame.loc.unwrap(); <ins> // If this is a `Call` terminator, use the `fn_span` instead. </ins> let block = &frame.body.basic_blocks()[loc.block]; <del> assert_eq!(block.statements.len(), loc.statement_index); debug!( "find_closest_untracked_caller_location:: got terminator {:?} ({:?})", block.terminator(), block.terminator().kind ); if let TerminatorKind::Call { fn_span, .. } = block.terminator().kind { return fn_span; </del> <ins> if loc.statement_index == block.statements.len() { debug!( "find_closest_untracked_caller_location:: got terminator {:?} ({:?})", block.terminator(), block.terminator().kind ); if let TerminatorKind::Call { fn_span, .. } = block.terminator().kind { return fn_span; } </ins> } <del> unreachable!(); </del> <ins> // This is a different terminator (such as `Drop`) or not a terminator at all // (such as `box`). Use the normal span. frame.body.source_info(loc).span </ins> } /// Allocate a `const core::panic::Location` with the provided filename and line/column numbers.


Question:
When encountering a , there must be a corresponding in the MIR body. If there isn't, later passes can panic due to indexing out of bounds of the array. The validation pass could detect this problem earlier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Instructions: Extend the validation pass in by implementing for the MIR visitor: The trait is documented . The method should check that the local exists in , and fail with a descriptive error message if not (by calling , not by panicking directly).
claim
FYI, the validation pass currently fails on even libcore until is merged, so you need to either wait for that, or cherry-pick some commits from there to get it to work. You can test your changes by running (the validator only runs on very little code by default, turns it on for everything).
I wanted to double check, running should fail when I run it, right? It actually passed for me after I merged in your branch from I wonder if I should try clean and build stage 1 again. :
It should pass with applied, but fail on current master.
So your PR fixes this issue () as well?
Ah, no, this issue is just about adding additional validation. It shouldn't actually detect any locals that don't exist. So the command should work both before and after implementing this. If it fails after implementing this, something else is going on that we should look into.
are you still working on this?
No, sorry. Didn’t have time for it. Go ahead.
release-assignment
Would like to work on this, but it seems there is another check, not on the declaration like this one, but on the memory liveness. This should cover the case that the local is not declared (I think), or would it not?

impl<'a, 'tcx> Visitor<'tcx> for TypeChecker<'a, 'tcx> { fn visit_local(&mut self, local: &Local, context: PlaceContext, location: Location) { <ins> if self.body.local_decls.get(*local).is_none() { self.fail( location, format!("local {:?} has no corresponding declaration in `body.local_decls`", local), ); } </ins> if self.reachable_blocks.contains(location.block) && context.is_use() { // Uses of locals must occur while the local's storage is allocated. self.storage_liveness.seek_after_primary_effect(location);


Question:
Recently enabled benchmarks () frequently fail on arm-android builder on GitHub Actions: The issue looks similar to previously reported .
I'm sorry, I noticed this during my local testing, but figured it was due to my hardware which had a very high parallel count, and it seemed to go away when I lowered the parallel test threads. I also had great difficulty running these tests at -j32 on android as well: They either seemed to hang, or took a very long time to finish. Would people prefer to just disable the bench tests on android, or should we do more investigation?
Again? cc
Looks like didn't fix the "died due to signal 11" errors either :(
hm, yeah if these keep coming back I guess that's reason enough for me to allocate time for it again.
will open a PR disabling collectionsbench on Android for the time being.

<ins> // Disabling on android for the time being // See https://github.com/rust-lang/rust/issues/73535#event-3477699747 #![cfg(not(target_os = "android"))] </ins> #![feature(btree_drain_filter)] #![feature(map_first_last)] #![feature(repr_simd)]


Question:
Recently enabled benchmarks () frequently fail on arm-android builder on GitHub Actions: The issue looks similar to previously reported .
I'm sorry, I noticed this during my local testing, but figured it was due to my hardware which had a very high parallel count, and it seemed to go away when I lowered the parallel test threads. I also had great difficulty running these tests at -j32 on android as well: They either seemed to hang, or took a very long time to finish. Would people prefer to just disable the bench tests on android, or should we do more investigation?
Again? cc
Looks like didn't fix the "died due to signal 11" errors either :(
hm, yeah if these keep coming back I guess that's reason enough for me to allocate time for it again.
will open a PR disabling collectionsbench on Android for the time being.

// std testing crates, okay for now at least "src/libcore/tests", "src/liballoc/tests/lib.rs", <ins> "src/liballoc/benches/lib.rs", </ins> // The `VaList` implementation must have platform specific code. // The Windows implementation of a `va_list` is always a character // pointer regardless of the target architecture. As a result,


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

/// Inline asm operand type must be `Sized`. InlineAsmSized, /// `[T, ..n]` implies that `T` must be `Copy`. <del> RepeatVec, </del> <ins> /// If the function in the array repeat expression is a `const fn`, /// display a help message suggesting to move the function call to a /// new `const` item while saying that `T` doesn't implement `Copy`. RepeatVec(bool), </ins> /// Types of fields (other than the last, except for packed structs) in a struct must be sized. FieldSized {


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

use crate::dataflow::impls::MaybeInitializedPlaces; use crate::dataflow::move_paths::MoveData; use crate::dataflow::ResultsCursor; <ins> use crate::transform::{ check_consts::ConstCx, promote_consts::is_const_fn_in_array_repeat_expression, }; </ins> use crate::borrow_check::{ borrow_set::BorrowSet,


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

Operand::Copy(..) | Operand::Constant(..) => { // These are always okay: direct use of a const, or a value that can evidently be copied. } <del> Operand::Move(_) => { </del> <ins> Operand::Move(place) => { </ins> // Make sure that repeated elements implement `Copy`. let span = body.source_info(location).span; let ty = operand.ty(body, tcx); if !self.infcx.type_is_copy_modulo_regions(self.param_env, ty, span) { <ins> let ccx = ConstCx::new_with_param_env(tcx, body, self.param_env); let is_const_fn = is_const_fn_in_array_repeat_expression(&ccx, &place, &body); debug!("check_rvalue: is_const_fn={:?}", is_const_fn); </ins> let def_id = body.source.def_id().expect_local(); self.infcx.report_selection_error( &traits::Obligation::new( ObligationCause::new( span, self.tcx().hir().local_def_id_to_hir_id(def_id), <del> traits::ObligationCauseCode::RepeatVec, </del> <ins> traits::ObligationCauseCode::RepeatVec(is_const_fn), </ins> ), self.param_env, ty::Binder::bind(ty::TraitRef::new(


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

promotions } <ins> /// This function returns `true` if the function being called in the array /// repeat expression is a `const` function. crate fn is_const_fn_in_array_repeat_expression<'tcx>( ccx: &ConstCx<'_, 'tcx>, place: &Place<'tcx>, body: &Body<'tcx>, ) -> bool { match place.as_local() { // rule out cases such as: `let my_var = some_fn(); [my_var; N]` Some(local) if body.local_decls[local].is_user_variable() => return false, None => return false, _ => {} } for block in body.basic_blocks() { if let Some(Terminator { kind: TerminatorKind::Call { func, destination, .. }, .. }) = &block.terminator { if let Operand::Constant(box Constant { literal: ty::Const { ty, .. }, .. }) = func { if let ty::FnDef(def_id, _) = *ty.kind() { if let Some((destination_place, _)) = destination { if destination_place == place { if is_const_fn(ccx.tcx, def_id) { return true; } } } } } } } false } </ins>


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

ObligationCauseCode::Coercion { source: _, target } => { err.note(&format!("required by cast to type `{}`", self.ty_to_string(target))); } <del> ObligationCauseCode::RepeatVec => { </del> <ins> ObligationCauseCode::RepeatVec(is_const_fn) => { </ins> err.note( "the `Copy` trait is required because the repeated element will be copied", ); <ins> if is_const_fn { err.help( "consider creating a new `const` item and initializing with the result  of the function call to be used in the repeat position, like  `const VAL: Type = const_fn();` and `let x = [VAL; 42];`", ); } if self.tcx.sess.is_nightly_build() && is_const_fn { err.help( "create an inline `const` block, see PR  #2920 <https://github.com/rust-lang/rfcs/pull/2920>  for more information", ); } </ins> } ObligationCauseCode::VariableType(hir_id) => { let parent_node = self.tcx.hir().get_parent_node(hir_id);


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

This directory contains the source code of the rust project, including: - The test suite - The bootstrapping build system - Various submodules for tools, like rustdoc, rls, etc.


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

= help: the following implementations were found: <Option<T> as Copy> = note: the `Copy` trait is required because the repeated element will be copied <ins> = help: consider creating a new `const` item and initializing with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` = help: create an inline `const` block, see PR #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information </ins> error: aborting due to previous error


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

<ins> fn main() { // should hint to create an inline `const` block // or to create a new `const` item let strings: [String; 5] = [String::new(); 5]; //~^ ERROR the trait bound `String: Copy` is not satisfied println!("{:?}", strings); } </ins>


Question:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim

<ins> error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:4:32 | LL |     let strings: [String; 5] = [String::new(); 5]; |                                ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = note: the `Copy` trait is required because the repeated element will be copied = help: consider creating a new `const` item and initializing with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` = help: create an inline `const` block, see PR #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.

use rustc_infer::infer::{self, InferOk, TyCtxtInferExt}; use rustc_middle::ty; use rustc_middle::ty::error::{ExpectedFound, TypeError}; <del> use rustc_middle::ty::subst::{InternalSubsts, Subst, SubstsRef}; </del> <ins> use rustc_middle::ty::subst::{InternalSubsts, Subst}; </ins> use rustc_middle::ty::util::ExplicitSelf; <del> use rustc_middle::ty::{GenericParamDefKind, ToPredicate, TyCtxt, WithConstness}; </del> <ins> use rustc_middle::ty::{GenericParamDefKind, ToPredicate, TyCtxt}; </ins> use rustc_span::Span; use rustc_trait_selection::traits::error_reporting::InferCtxtExt; use rustc_trait_selection::traits::{self, ObligationCause, ObligationCauseCode, Reveal}; use super::{potentially_plural_count, FnCtxt, Inherited}; <del> use std::iter; </del> /// Checks that a method from an impl conforms to the signature of /// the same method as declared in the trait.


Question:
So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.

return Ok(()); } <del> let param_env = tcx.param_env(impl_ty.def_id); </del> // Given // // impl<A, B> Foo<u32> for (A, B) {


Question:
So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.

impl_ty_substs.rebase_onto(tcx, impl_ty.container.id(), impl_trait_ref.substs); let impl_ty_value = tcx.type_of(impl_ty.def_id); <del> // Map the predicate from the trait to the corresponding one for the impl. // For example: </del> <ins> let param_env = tcx.param_env(impl_ty.def_id); // When checking something like </ins> // <del> // trait X<A> { type Y<'a>: PartialEq<A> } impl X for T { type Y<'a> = &'a S; } // impl<'x> X<&'x u32> for () { type Y<'c> = &'c u32; } </del> <ins> // trait X { type Y: PartialEq<<Self as X>::Y> } // impl X for T { default type Y = S; } </ins> // <del> // For the `for<'a> <<Self as X<A>>::Y<'a>: PartialEq<A>` bound, this // function would translate and partially normalize // `[<Self as X<A>>::Y<'a>, A]` to `[&'a u32, &'x u32]`. let translate_predicate_substs = move |predicate_substs: SubstsRef<'tcx>| { tcx.mk_substs( iter::once(impl_ty_value.into()) .chain(predicate_substs[1..].iter().map(|s| s.subst(tcx, rebased_substs))), ) </del> <ins> // We will have to prove the bound S: PartialEq<<T as X>::Y>. In this case // we want <T as X>::Y to normalize to S. This is valid because we are // checking the default value specifically here. Add this equality to the // ParamEnv for normalization specifically. let normalize_param_env = { let mut predicates = param_env.caller_bounds().iter().collect::<Vec<_>>(); predicates.push( ty::Binder::dummy(ty::ProjectionPredicate { projection_ty: ty::ProjectionTy { item_def_id: trait_ty.def_id, substs: rebased_substs, }, ty: impl_ty_value, }) .to_predicate(tcx), ); ty::ParamEnv::new(tcx.intern_predicates(&predicates), Reveal::UserFacing, None) </ins> }; tcx.infer_ctxt().enter(move |infcx| {


Question:
So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.

); let predicates = tcx.projection_predicates(trait_ty.def_id); debug!("compare_projection_bounds: projection_predicates={:?}", predicates); for predicate in predicates { <del> let concrete_ty_predicate = match predicate.kind() { ty::PredicateKind::Trait(poly_tr, c) => poly_tr .map_bound(|tr| { let trait_substs = translate_predicate_substs(tr.trait_ref.substs); ty::TraitRef { def_id: tr.def_id(), substs: trait_substs } }) .with_constness(*c) .to_predicate(tcx), ty::PredicateKind::Projection(poly_projection) => poly_projection .map_bound(|projection| { let projection_substs = translate_predicate_substs(projection.projection_ty.substs); ty::ProjectionPredicate { projection_ty: ty::ProjectionTy { substs: projection_substs, item_def_id: projection.projection_ty.item_def_id, }, ty: projection.ty.subst(tcx, rebased_substs), } }) .to_predicate(tcx), ty::PredicateKind::TypeOutlives(poly_outlives) => poly_outlives .map_bound(|outlives| { ty::OutlivesPredicate(impl_ty_value, outlives.1.subst(tcx, rebased_substs)) }) .to_predicate(tcx), _ => bug!("unexepected projection predicate kind: `{:?}`", predicate), }; </del> <ins> let concrete_ty_predicate = predicate.subst(tcx, rebased_substs); debug!("compare_projection_bounds: concrete predicate = {:?}", concrete_ty_predicate); </ins> let traits::Normalized { value: normalized_predicate, obligations } = traits::normalize( &mut selcx, <del> param_env, </del> <ins> normalize_param_env, </ins> normalize_cause.clone(), &concrete_ty_predicate, ); debug!("compare_projection_bounds: normalized predicate = {:?}", normalized_predicate); inh.register_predicates(obligations);


Question:
So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.

<ins> // Test that associated type bounds are correctly normalized when checking // default associated type values. // check-pass #![allow(incomplete_features)] #![feature(specialization)] #[derive(PartialEq)] enum Never {} trait Foo { type Assoc: PartialEq; // PartialEq<<Self as Foo>::Assoc> } impl<T> Foo for T { default type Assoc = Never; } trait Trait1 { type Selection: PartialEq; } trait Trait2: PartialEq<Self> {} impl<T: Trait2> Trait1 for T { default type Selection = T; } fn main() {} </ins>


Question:
Hey, This code attempts to increment a integer behind a tokio RwLock by 1, This causes a compiler error. Minimized example that reproduces the ICE: But, making this very small modification makes the code not break the compiler my contains as a dependency. This code does not compile, and generates the following error (full backtrace in bottom of the issue) rustc --version --verbose also breaks the same way on (the traces attached are from nightly ^) rustup run stable rustc --version -v
Confirmed this also breaks the same way on
MCVE: Fun fact: changing to doesn't ICE. Also I can't inline an instance into the function. It has to be created outside?!. Weird stuff somtimes. Also it would be nice to get rid of the deref, but I couldn't figure out how. So it's on this currently. Also worth mentioning: this needs . isn't sufficient. modify labels: -E-needs-mcve +E-needs-bisection
The bisection doesn't emit anything useful. This panics like forever. I went back to 2019-01-01 (with the old API and stuff) and it still ICEs there, so I guess it was like this forever. Feel free to add the tag again, but I'll remove it. modify labels: -E-needs-bisection
modify labels: -E-needs-bisection

/// N.B., **No cleanup is scheduled for this temporary.** You should /// call `schedule_drop` once the temporary is initialized. crate fn temp(&mut self, ty: Ty<'tcx>, span: Span) -> Place<'tcx> { <del> let temp = self.local_decls.push(LocalDecl::new(ty, span)); </del> <ins> // Mark this local as internal to avoid temporaries with types not present in the // user's code resulting in ICEs from the generator transform. let temp = self.local_decls.push(LocalDecl::new(ty, span).internal()); </ins> let place = Place::from(temp); debug!("temp: created temp {:?} with type {:?}", place, self.local_decls[temp].ty); place


Question:
Hey, This code attempts to increment a integer behind a tokio RwLock by 1, This causes a compiler error. Minimized example that reproduces the ICE: But, making this very small modification makes the code not break the compiler my contains as a dependency. This code does not compile, and generates the following error (full backtrace in bottom of the issue) rustc --version --verbose also breaks the same way on (the traces attached are from nightly ^) rustup run stable rustc --version -v
Confirmed this also breaks the same way on
MCVE: Fun fact: changing to doesn't ICE. Also I can't inline an instance into the function. It has to be created outside?!. Weird stuff somtimes. Also it would be nice to get rid of the deref, but I couldn't figure out how. So it's on this currently. Also worth mentioning: this needs . isn't sufficient. modify labels: -E-needs-mcve +E-needs-bisection
The bisection doesn't emit anything useful. This panics like forever. I went back to 2019-01-01 (with the old API and stuff) and it still ICEs there, so I guess it was like this forever. Feel free to add the tag again, but I'll remove it. modify labels: -E-needs-bisection
modify labels: -E-needs-bisection

<ins> // build-pass // compile-flags:-Copt-level=0 // edition:2018 struct S<T>(std::marker::PhantomData<T>); impl<T> std::ops::Deref for S<T> { type Target = T; fn deref(&self) -> &Self::Target { todo!() } } impl<T> std::ops::DerefMut for S<T> { fn deref_mut(&mut self) -> &mut Self::Target { todo!() } } async fn new() -> S<u64> { todo!() } async fn crash() { *new().await = 1 + 1; } fn main() { let _ = crash(); } </ins>


Question:
This is just my personal taste. I'm never a fan of making comments italic. It is hard to read for me. Rather, I really enjoy what Dark and Light theme is doing: Mark doc comments with different color than normal comments. cc
Can you add a screenshot of what this looks like in both Ayu and Dark themes?
Here in Ayu and Dark theme respectively: ! !
I was searching about the italic comment topic and found that people prefer both. But I think the good choice is to default to non-italic and add a rustdoc config to change to italic.
We will definitely not add a rustdoc config for that (way too specific). :)
Thanks for your critique of the theme, it's been very helpful :) I would like to keep the comment style italic because: It provides a rustdoc theme with italic comments for those who like it (if one dislikes this there are two other themes that don't make this choice) The Ayu theme everywhere else has italic comments, example: ! I don't want to break with the standard Ayu look in this regard unless a significant number of people find the italics to be a problem. As far as the color being different between doc comments and normal comments, I am personally against this. I've never seen an editor highlight doc comments differently from normal comments, nor do I see a reason to do so. The only thing that sets doc comments apart from normal comments is that they are present in the generated rustdoc HTML, and to me this is not a reason to introduce an entirely new color into the mix just for the sake of styling them differently (why would you care about this when reading the comment? What benefit does the color being different from a normal comment provide, and does that benefit outweigh the visual clutter introduced by using another color? I'm interested to hear your thoughts about this). Here I would say similar to the above: the Ayu theme provides a choice to view comments with a unified color. If one dislikes this, there are two other themes available with that feature .
I'd like to comment in favour of removing the italic. In here it's important to remember that themes are only supposed to change colors, not presentation. Adding italic on comments is breaking the coherency with the other themes and I think it should be removed, even though the original theme has it (are you sure it's the theme and not the IDE btw?).
That's a fair point, I can agree with that. Yes it is the theme
I will note that my vim configuration at least does this and I personally quite like it -- I differentiate between regular comments and doc comments when reading. Regular comments are intended for the programmer and doc comments for the end-user of the API; those are at least for me two different mindsets. !
Thanks for letting me know about its origins. I've never used Ayu theme in editor other than in mdbook and rustdoc. It is great. This issue () is not related to rustdoc but it points out a group of people finding a way to disable italic on comments and language keywords on VS Code. I wish Rust-Enhancement package (Sublime Text) render they differently. already did it. Mark already posted a reason for the difference:
Interesting! Thanks for chiming in. Your point about who each type of comment is written for makes sense I'll look into a color that would make sense to use for doc comments in the theme here.
I'll throw another vote in favor of not using italics. They are, in general, a poor experience with monospaced fonts.
If people are interested, we could use a different color for the doc comments. It sounds like a good add.
I played around with some options and I believe meshes reasonably well as a doc comment color. Before: ! After: ! Another potential option that draws less attention away from the code itself is : ! Thoughts on this?
I find the last proposal better, but maybe we should put it into another issue to not lose track of the original issue? ;)
Opened a new issue :)

pre.rust .comment, pre.rust .doccomment { color: #788797; <del> font-style: italic; </del> } nav:not(.sidebar) {


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> #![feature(associated_type_defaults)] #![feature(generic_associated_types)] #![allow(incomplete_features)] trait Trait1 { fn foo(); } trait Trait2 { type Associated: Trait1 = Self; //~^ ERROR: the trait bound `Self: Trait1` is not satisfied //~| the size for values of type `Self` cannot be known } impl Trait2 for () {} fn call_foo<T: Trait2>() { T::Associated::foo() } fn main() { call_foo::<()>() } </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> error[E0277]: the trait bound `Self: Trait1` is not satisfied --> $DIR/issue-74816.rs:10:5 | LL |     type Associated: Trait1 = Self; |     ^^^^^^^^^^^^^^^^^------^^^^^^^^ |     |                | |     |                required by this bound in `Trait2::Associated` |     the trait `Trait1` is not implemented for `Self` | help: consider further restricting `Self` | LL | trait Trait2: Trait1 { |             ^^^^^^^^ error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/issue-74816.rs:10:5 | LL |     type Associated: Trait1 = Self; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |     | |     doesn't have a size known at compile-time |     required by this bound in `Trait2::Associated` | help: consider further restricting `Self` | LL | trait Trait2: Sized { |             ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> #![feature(type_alias_impl_trait)] #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] type FooArg<'a> = &'a dyn ToString; type FooRet = impl std::fmt::Debug; type FooItem = Box<dyn Fn(FooArg) -> FooRet>; type Foo = impl Iterator<Item = FooItem>; //~ ERROR: type mismatch #[repr(C)] struct Bar(u8); impl Iterator for Bar { type Item = FooItem; fn next(&mut self) -> Option<Self::Item> { Some(Box::new(quux)) } } fn quux(st: FooArg) -> FooRet { Some(st.to_string()) } fn ham() -> Foo { Bar(1) } fn oof() -> impl std::fmt::Debug { let mut bar = ham(); let func = bar.next().unwrap(); return func(&"oof"); } fn main() { let _ = oof(); } </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> error[E0271]: type mismatch resolving `<Bar as Iterator>::Item == Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> Option<String> + 'static)>` --> $DIR/issue-70877.rs:9:12 | LL | type FooRet = impl std::fmt::Debug; |               -------------------- the expected opaque type ... LL | type Foo = impl Iterator<Item = FooItem>; |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found enum `Option` | = note: expected struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> impl Debug + 'static)>` found struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> Option<String> + 'static)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> // check-pass // Regression test of #70944, should compile fine. use std::ops::Index; pub struct KeyA; pub struct KeyB; pub struct KeyC; pub trait Foo: Index<KeyA> + Index<KeyB> + Index<KeyC> {} pub trait FooBuilder { type Inner: Foo; fn inner(&self) -> &Self::Inner; } pub fn do_stuff(foo: &impl FooBuilder) { let inner = foo.inner(); &inner[KeyA]; &inner[KeyB]; &inner[KeyC]; } fn main() {} </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> // check-pass #![feature(trait_alias)] struct Bar; trait Foo {} impl Foo for Bar {} trait Baz = Foo where Bar: Foo; fn new() -> impl Baz { Bar } fn main() { let _ = new(); } </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> #![feature(unsize)] use std::marker::Unsize; pub trait CastTo<T: ?Sized>: Unsize<T> { fn cast_to(&self) -> &T; } impl<T: ?Sized, U: ?Sized + Unsize<T>> CastTo<T> for U { fn cast_to(&self) -> &T { self } } impl<T: ?Sized> Cast for T {} pub trait Cast { fn cast<T: ?Sized>(&self) -> &T where Self: CastTo<T>, { self } } pub trait Foo: CastTo<[i32]> {} impl Foo for [i32; 0] {} fn main() { let x: &dyn Foo = &[]; let x = x.cast::<[i32]>(); //~^ ERROR: the trait bound `dyn Foo: CastTo<[i32]>` is not satisfied } </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> error[E0277]: the trait bound `dyn Foo: CastTo<[i32]>` is not satisfied --> $DIR/issue-71659.rs:30:15 | LL |     let x = x.cast::<[i32]>(); |               ^^^^ the trait `CastTo<[i32]>` is not implemented for `dyn Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> pub trait Callback { fn cb(); } pub trait Processing { type Call: Callback; } fn f<P: Processing + ?Sized>() { P::Call::cb(); } fn main() { struct MyCall; f::<dyn Processing<Call = MyCall>>(); //~^ ERROR: the trait bound `MyCall: Callback` is not satisfied } </ins>


Question:
() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

<ins> error[E0277]: the trait bound `MyCall: Callback` is not satisfied --> $DIR/issue-75707.rs:15:5 | LL | fn f<P: Processing + ?Sized>() { |         ---------- required by this bound in `f` ... LL |     f::<dyn Processing<Call = MyCall>>(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Callback` is not implemented for `MyCall` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

use crate::infer::error_reporting::nice_region_error::NiceRegionError; use crate::infer::lexical_region_resolve::RegionResolutionError; <del> use crate::infer::{Subtype, TyCtxtInferExt, ValuePairs}; </del> <ins> use crate::infer::{Subtype, ValuePairs}; </ins> use crate::traits::ObligationCauseCode::CompareImplMethodObligation; use rustc_errors::ErrorReported; use rustc_hir as hir;


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

} fn emit_err(&self, sp: Span, expected: Ty<'tcx>, found: Ty<'tcx>, trait_def_id: DefId) { <del> let tcx = self.tcx(); </del> let trait_sp = self.tcx().def_span(trait_def_id); let mut err = self .tcx()


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

); } <del> if let Some((expected, found)) = tcx .infer_ctxt() .enter(|infcx| infcx.expected_found_str_ty(&ExpectedFound { expected, found })) </del> <ins> if let Some((expected, found)) = self.infcx.expected_found_str_ty(&ExpectedFound { expected, found }) </ins> { // Highlighted the differences when showing the "expected/found" note. err.note_expected_found(&"", expected, &"", found);


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

<ins> // Regression test for issue #74918 // Tests that we don't ICE after emitting an error struct ChunkingIterator<T, S: 'static + Iterator<Item = T>> { source: S, } impl<T, S: Iterator<Item = T>> Iterator for ChunkingIterator<T, S> { type Item = IteratorChunk<T, S>; //~ ERROR missing lifetime fn next(&mut self) -> Option<IteratorChunk<T, S>> { //~ ERROR `impl` todo!() } } struct IteratorChunk<'a, T, S: Iterator<Item = T>> { source: &'a mut S, } impl<T, S: Iterator<Item = T>> Iterator for IteratorChunk<'_, T, S> { type Item = T; fn next(&mut self) -> Option<T> { todo!() } } fn main() {} </ins>


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

<ins> error[E0106]: missing lifetime specifier --> $DIR/issue-74918-missing-lifetime.rs:9:31 | LL |     type Item = IteratorChunk<T, S>; |                               ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | LL |     type Item<'a> = IteratorChunk<<'a>T, S>; |              ^^^^                 ^^^^ error: `impl` item signature doesn't match `trait` item signature --> $DIR/issue-74918-missing-lifetime.rs:11:5 | LL |     fn next(&mut self) -> Option<IteratorChunk<T, S>> { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&mut ChunkingIterator<T, S>) -> std::option::Option<IteratorChunk<'_, T, S>>` | ::: $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL | LL |     fn next(&mut self) -> Option<Self::Item>; |     ----------------------------------------- expected `fn(&mut ChunkingIterator<T, S>) -> std::option::Option<IteratorChunk<'static, _, _>>` | = note: expected `fn(&mut ChunkingIterator<T, S>) -> std::option::Option<IteratorChunk<'static, _, _>>` found `fn(&mut ChunkingIterator<T, S>) -> std::option::Option<IteratorChunk<'_, _, _>>` = help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait` = help: verify the lifetime relationships in the `trait` and `impl` between the `self` argument, the other inputs and its output error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0106`. </ins>


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

<ins> // Regresison test for issue #75361 // Tests that we don't ICE on mismatched types with inference variables trait MyTrait { type Item; } pub trait Graph { type EdgeType; fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType>>; } impl<T> Graph for T { type EdgeType = T; fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType> + '_> { //~ ERROR `impl` panic!() } } fn main() {} </ins>


Question:
<!-- 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .

<ins> error: `impl` item signature doesn't match `trait` item signature --> $DIR/issue-75361-mismatched-impl.rs:18:3 | LL |   fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType>>; |   --------------------------------------------------------------------- expected `fn(&T) -> std::boxed::Box<(dyn MyTrait<Item = &_> + 'static)>` ... LL |   fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType> + '_> { |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&T) -> std::boxed::Box<dyn MyTrait<Item = &_>>` | = note: expected `fn(&T) -> std::boxed::Box<(dyn MyTrait<Item = &T> + 'static)>` found `fn(&T) -> std::boxed::Box<dyn MyTrait<Item = &T>>` help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait` --> $DIR/issue-75361-mismatched-impl.rs:12:55 | LL |   fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType>>; |                                                       ^^^^^^^^^^^^^^ consider borrowing this type parameter in the trait error: aborting due to previous error </ins>


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::util; use rustc_session::config::EntryFnType; <del> use rustc_span::{Span, DUMMY_SP}; </del> <ins> use rustc_span::{symbol::sym, Span, DUMMY_SP}; </ins> use rustc_target::spec::abi::Abi; use rustc_trait_selection::traits::error_reporting::InferCtxtExt as _; use rustc_trait_selection::traits::{


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

.emit(); error = true; } <ins> for attr in it.attrs { if attr.check_name(sym::track_caller) { tcx.sess .struct_span_err( attr.span, "`main` function is not allowed to be `#[track_caller]`", ) .span_label( main_span, "`main` function is not allowed to be `#[track_caller]`", ) .emit(); error = true; } } </ins> if error { return; }


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

tcx.sess, span, E0752, <del> "start is not allowed to be `async`" </del> <ins> "`start` is not allowed to be `async`" </ins> ) <del> .span_label(span, "start is not allowed to be `async`") </del> <ins> .span_label(span, "`start` is not allowed to be `async`") </ins> .emit(); error = true; } <ins> for attr in it.attrs { if attr.check_name(sym::track_caller) { tcx.sess .struct_span_err( attr.span, "`start` is not allowed to be `#[track_caller]`", ) .span_label( start_span, "`start` is not allowed to be `#[track_caller]`", ) .emit(); error = true; } } </ins> if error { return; }


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

#[start] pub async fn start(_: isize, _: *const *const u8) -> isize { <del> //~^ ERROR start is not allowed to be `async` </del> <ins> //~^ ERROR `start` is not allowed to be `async` </ins> 0 }


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

<del> error[E0752]: start is not allowed to be `async` </del> <ins> error[E0752]: `start` is not allowed to be `async` </ins> --> $DIR/issue-68523-start.rs:6:1 | LL | pub async fn start(_: isize, _: *const *const u8) -> isize { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ start is not allowed to be `async` </del> <ins> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `start` is not allowed to be `async` </ins> error: aborting due to previous error


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

<ins> #[track_caller] //~ ERROR `main` function is not allowed to be fn main() { panic!("{}: oh no", std::panic::Location::caller()); } </ins>


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

<ins> error: `main` function is not allowed to be `#[track_caller]` --> $DIR/error-with-main.rs:1:1 | LL |   #[track_caller] |   ^^^^^^^^^^^^^^^ LL | / fn main() { LL | |     panic!("{}: oh no", std::panic::Location::caller()); LL | | } | |_- `main` function is not allowed to be `#[track_caller]` error: aborting due to previous error </ins>


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

<ins> #![feature(start)] #[start] #[track_caller] //~ ERROR `start` is not allowed to be `#[track_caller]` fn start(_argc: isize, _argv: *const *const u8) -> isize { panic!("{}: oh no", std::panic::Location::caller()); } </ins>


Question:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .

<ins> error: `start` is not allowed to be `#[track_caller]` --> $DIR/error-with-start.rs:4:1 | LL |   #[track_caller] |   ^^^^^^^^^^^^^^^ LL | / fn start(_argc: isize, _argv: *const *const u8) -> isize { LL | |     panic!("{}: oh no", std::panic::Location::caller()); LL | | } | |_- `start` is not allowed to be `#[track_caller]` error: aborting due to previous error </ins>


Question:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.

return Ok(expr); } } <ins> if (op.node == AssocOp::Equal || op.node == AssocOp::NotEqual) && self.token.kind == token::Eq && self.prev_token.span.hi() == self.token.span.lo() { // Look for JS' `===` and `!==` and recover 😇 let sp = op.span.to(self.token.span); let sugg = match op.node { AssocOp::Equal => "==", AssocOp::NotEqual => "!=", _ => unreachable!(), }; self.struct_span_err(sp, &format!("invalid comparison operator `{}=`", sugg)) .span_suggestion_short( sp, &format!("`{s}=` is not a valid comparison operator, use `{s}`", s = sugg), sugg.to_string(), Applicability::MachineApplicable, ) .emit(); self.bump(); } </ins> let op = op.node; // Special cases: if op == AssocOp::As {


Question:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.

<ins> fn main() { if 1 == = 1 { //~ ERROR expected expression println!("yup!"); } } </ins>


Question:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.

<ins> error: expected expression, found `=` --> $DIR/js-style-comparison-op-separate-eq-token.rs:2:13 | LL |     if 1 == = 1 { |             ^ expected expression error: aborting due to previous error </ins>


Question:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.

<ins> // run-rustfix fn main() { if 1 == 1 { //~ ERROR invalid comparison operator `===` println!("yup!"); } else if 1 != 1 { //~ ERROR invalid comparison operator `!==` println!("nope!"); } } </ins>


Question:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.

<ins> // run-rustfix fn main() { if 1 === 1 { //~ ERROR invalid comparison operator `===` println!("yup!"); } else if 1 !== 1 { //~ ERROR invalid comparison operator `!==` println!("nope!"); } } </ins>


Question:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.

<ins> error: invalid comparison operator `===` --> $DIR/js-style-comparison-op.rs:3:10 | LL |     if 1 === 1 { |          ^^^ help: `===` is not a valid comparison operator, use `==` error: invalid comparison operator `!==` --> $DIR/js-style-comparison-op.rs:5:17 | LL |     } else if 1 !== 1 { |                 ^^^ help: `!==` is not a valid comparison operator, use `!=` error: aborting due to 2 previous errors </ins>


Question:
As reported on Zulip: https://rust- This works for simple enums with one or more variants, but for zero it fails, possibly due to interaction with . This kind of code can come up in macro code. cc
I think for zero-variant enums it fails mostly as an oversight. This doesn't even have to generate any MIR as it is unreachable code anyway. Nominating for lang team discussion.
From the head comment at , I infer that this is indeed only designed to work with C-style enums. My proposal would be to add another cast category saying that empty enums can cast to anything, desugaring to .
No, enum casts have nothing to do with C-style enums. This works:
Oh, the comment says "C-like". That's not the same as . "C-like" just means that all enum variants have no data. This is satisfied by -- there are no enum variants, and thus all of them have no data.
Here's the offending check: It seems that the "payload-free" check is not just "all variants have no data" but also "it is not empty". I would hesitate to change this definition because it's likely to affect C-like enum handling elsewhere, but maybe can get another class specifically for uninhabited enums.
I'd argue a no-variant enum is payload-free. But all uses of that function should be carefully checked. Adding a new case to seems like a hack to me.
These were historically known as "C-like" enums, and is not C-like. From GCC: Can you maybe elaborate more on this?
Sure, C might not permit them, but I don't see how that's a reason to disallow casts in Rust.
I mean, what value does have that will make sense?
It's not actually reachable, so it could just typecheck without actually ever needing to produce a value.
It can compile the same way as , which is to say, produce no code and mark the remainder of the function as unreachable. Compiling to would also work for all numeric types that this could target, although then appears unused which might cause other unintended behaviors in the compiler.
Currently, the compiler marks code . What do you mean ? Unreachable is unsafe, does it mean that is unsafe ?
This uses no unsafe code: Here the code after the match statement (if there was any) would be unreachable, and this requires no unsafe code. Basically is an impossible value, therefore the function cannot be called in the first place and no code need be generated. EDIT: Your linked example is pattern matching on an with no branches. Here is an empty enum, , so an empty match of an empty enum is exhaustive without any unsafe.
Thanks, I got that part now. But the question raised by : What is the concrete example of macros that have use cases for ? Also, is a never type, if allowed, would we want to make any operations on unreachable?
The actual macro where this came up was a safe wrapper that declares an int-like enum and an array indexed by the enum. Roughly, it creates a type and , and then the implementation for uses where . When has zero elements, this causes the macro to produce malformed code. It is possible to work around this issue by explicitly checking for this case, but I don't really see a reason for it not to work in the first place. Any operation on Void is unreachable. That means that the compiler can do whatever it wants to for codegen here because it doesn't matter, the function is not callable. But from a typing point of view, I think that should have type , not .
It's no surprise that macros run into this -- this happens any time that we have special exceptions. "s without fields can be cast to integers, except if the enum has 0 variants" is such a special exception, and from a language design perspective it has no reason to exist. Not sure what the next step here is -- probably an RFC? This is a language extension after all.
Discussed in the meeting today: We agreed that this seems like a harmless extension (specifically: permitting zero variant enums to be to a usize). We don't feel an RFC is required and we would recommend somebody creating a PR that fixes this and nominates the PR for lang-team consideration, we can do an FCP directly on the PR.
I have opened to fix this issue.

self.variants.iter().flat_map(|v| v.fields.iter()) } <ins> /// Whether the ADT lacks fields. Note that this includes uninhabited enums, /// e.g., `enum Void {}` is considered payload free as well. </ins> pub fn is_payloadfree(&self) -> bool { <del> !self.variants.is_empty() && self.variants.iter().all(|v| v.fields.is_empty()) </del> <ins> self.variants.iter().all(|v| v.fields.is_empty()) </ins> } /// Return a `VariantDef` given a variant id.


Question:
As reported on Zulip: https://rust- This works for simple enums with one or more variants, but for zero it fails, possibly due to interaction with . This kind of code can come up in macro code. cc
I think for zero-variant enums it fails mostly as an oversight. This doesn't even have to generate any MIR as it is unreachable code anyway. Nominating for lang team discussion.
From the head comment at , I infer that this is indeed only designed to work with C-style enums. My proposal would be to add another cast category saying that empty enums can cast to anything, desugaring to .
No, enum casts have nothing to do with C-style enums. This works:
Oh, the comment says "C-like". That's not the same as . "C-like" just means that all enum variants have no data. This is satisfied by -- there are no enum variants, and thus all of them have no data.
Here's the offending check: It seems that the "payload-free" check is not just "all variants have no data" but also "it is not empty". I would hesitate to change this definition because it's likely to affect C-like enum handling elsewhere, but maybe can get another class specifically for uninhabited enums.
I'd argue a no-variant enum is payload-free. But all uses of that function should be carefully checked. Adding a new case to seems like a hack to me.
These were historically known as "C-like" enums, and is not C-like. From GCC: Can you maybe elaborate more on this?
Sure, C might not permit them, but I don't see how that's a reason to disallow casts in Rust.
I mean, what value does have that will make sense?
It's not actually reachable, so it could just typecheck without actually ever needing to produce a value.
It can compile the same way as , which is to say, produce no code and mark the remainder of the function as unreachable. Compiling to would also work for all numeric types that this could target, although then appears unused which might cause other unintended behaviors in the compiler.
Currently, the compiler marks code . What do you mean ? Unreachable is unsafe, does it mean that is unsafe ?
This uses no unsafe code: Here the code after the match statement (if there was any) would be unreachable, and this requires no unsafe code. Basically is an impossible value, therefore the function cannot be called in the first place and no code need be generated. EDIT: Your linked example is pattern matching on an with no branches. Here is an empty enum, , so an empty match of an empty enum is exhaustive without any unsafe.
Thanks, I got that part now. But the question raised by : What is the concrete example of macros that have use cases for ? Also, is a never type, if allowed, would we want to make any operations on unreachable?
The actual macro where this came up was a safe wrapper that declares an int-like enum and an array indexed by the enum. Roughly, it creates a type and , and then the implementation for uses where . When has zero elements, this causes the macro to produce malformed code. It is possible to work around this issue by explicitly checking for this case, but I don't really see a reason for it not to work in the first place. Any operation on Void is unreachable. That means that the compiler can do whatever it wants to for codegen here because it doesn't matter, the function is not callable. But from a typing point of view, I think that should have type , not .
It's no surprise that macros run into this -- this happens any time that we have special exceptions. "s without fields can be cast to integers, except if the enum has 0 variants" is such a special exception, and from a language design perspective it has no reason to exist. Not sure what the next step here is -- probably an RFC? This is a language extension after all.
Discussed in the meeting today: We agreed that this seems like a harmless extension (specifically: permitting zero variant enums to be to a usize). We don't feel an RFC is required and we would recommend somebody creating a PR that fixes this and nominates the PR for lang-team consideration, we can do an FCP directly on the PR.
I have opened to fix this issue.

// # First handle non-scalar source values. <del> // Handle cast from a univariant (ZST) enum. </del> <ins> // Handle cast from a ZST enum (0 or 1 variants). </ins> match src.layout.variants { Variants::Single { index } => { <ins> if src.layout.abi.is_uninhabited() { // This is dead code, because an uninhabited enum is UB to // instantiate. throw_ub!(Unreachable); } </ins> if let Some(discr) = src.layout.ty.discriminant_for_variant(*self.tcx, index) { assert!(src.layout.is_zst()); let discr_layout = self.layout_of(discr.ty)?;


Question:
As reported on Zulip: https://rust- This works for simple enums with one or more variants, but for zero it fails, possibly due to interaction with . This kind of code can come up in macro code. cc
I think for zero-variant enums it fails mostly as an oversight. This doesn't even have to generate any MIR as it is unreachable code anyway. Nominating for lang team discussion.
From the head comment at , I infer that this is indeed only designed to work with C-style enums. My proposal would be to add another cast category saying that empty enums can cast to anything, desugaring to .
No, enum casts have nothing to do with C-style enums. This works:
Oh, the comment says "C-like". That's not the same as . "C-like" just means that all enum variants have no data. This is satisfied by -- there are no enum variants, and thus all of them have no data.
Here's the offending check: It seems that the "payload-free" check is not just "all variants have no data" but also "it is not empty". I would hesitate to change this definition because it's likely to affect C-like enum handling elsewhere, but maybe can get another class specifically for uninhabited enums.
I'd argue a no-variant enum is payload-free. But all uses of that function should be carefully checked. Adding a new case to seems like a hack to me.
These were historically known as "C-like" enums, and is not C-like. From GCC: Can you maybe elaborate more on this?
Sure, C might not permit them, but I don't see how that's a reason to disallow casts in Rust.
I mean, what value does have that will make sense?
It's not actually reachable, so it could just typecheck without actually ever needing to produce a value.
It can compile the same way as , which is to say, produce no code and mark the remainder of the function as unreachable. Compiling to would also work for all numeric types that this could target, although then appears unused which might cause other unintended behaviors in the compiler.
Currently, the compiler marks code . What do you mean ? Unreachable is unsafe, does it mean that is unsafe ?
This uses no unsafe code: Here the code after the match statement (if there was any) would be unreachable, and this requires no unsafe code. Basically is an impossible value, therefore the function cannot be called in the first place and no code need be generated. EDIT: Your linked example is pattern matching on an with no branches. Here is an empty enum, , so an empty match of an empty enum is exhaustive without any unsafe.
Thanks, I got that part now. But the question raised by : What is the concrete example of macros that have use cases for ? Also, is a never type, if allowed, would we want to make any operations on unreachable?
The actual macro where this came up was a safe wrapper that declares an int-like enum and an array indexed by the enum. Roughly, it creates a type and , and then the implementation for uses where . When has zero elements, this causes the macro to produce malformed code. It is possible to work around this issue by explicitly checking for this case, but I don't really see a reason for it not to work in the first place. Any operation on Void is unreachable. That means that the compiler can do whatever it wants to for codegen here because it doesn't matter, the function is not callable. But from a typing point of view, I think that should have type , not .
It's no surprise that macros run into this -- this happens any time that we have special exceptions. "s without fields can be cast to integers, except if the enum has 0 variants" is such a special exception, and from a language design perspective it has no reason to exist. Not sure what the next step here is -- probably an RFC? This is a language extension after all.
Discussed in the meeting today: We agreed that this seems like a harmless extension (specifically: permitting zero variant enums to be to a usize). We don't feel an RFC is required and we would recommend somebody creating a PR that fixes this and nominates the PR for lang-team consideration, we can do an FCP directly on the PR.
I have opened to fix this issue.

<ins> // check-pass </ins> enum E {} fn f(e: E) { <del> println!("{}", (e as isize).to_string());   //~ ERROR non-primitive cast </del> <ins> println!("{}", (e as isize).to_string()); </ins> } fn main() {}


Question:
As reported on Zulip: https://rust- This works for simple enums with one or more variants, but for zero it fails, possibly due to interaction with . This kind of code can come up in macro code. cc
I think for zero-variant enums it fails mostly as an oversight. This doesn't even have to generate any MIR as it is unreachable code anyway. Nominating for lang team discussion.
From the head comment at , I infer that this is indeed only designed to work with C-style enums. My proposal would be to add another cast category saying that empty enums can cast to anything, desugaring to .
No, enum casts have nothing to do with C-style enums. This works:
Oh, the comment says "C-like". That's not the same as . "C-like" just means that all enum variants have no data. This is satisfied by -- there are no enum variants, and thus all of them have no data.
Here's the offending check: It seems that the "payload-free" check is not just "all variants have no data" but also "it is not empty". I would hesitate to change this definition because it's likely to affect C-like enum handling elsewhere, but maybe can get another class specifically for uninhabited enums.
I'd argue a no-variant enum is payload-free. But all uses of that function should be carefully checked. Adding a new case to seems like a hack to me.
These were historically known as "C-like" enums, and is not C-like. From GCC: Can you maybe elaborate more on this?
Sure, C might not permit them, but I don't see how that's a reason to disallow casts in Rust.
I mean, what value does have that will make sense?
It's not actually reachable, so it could just typecheck without actually ever needing to produce a value.
It can compile the same way as , which is to say, produce no code and mark the remainder of the function as unreachable. Compiling to would also work for all numeric types that this could target, although then appears unused which might cause other unintended behaviors in the compiler.
Currently, the compiler marks code . What do you mean ? Unreachable is unsafe, does it mean that is unsafe ?
This uses no unsafe code: Here the code after the match statement (if there was any) would be unreachable, and this requires no unsafe code. Basically is an impossible value, therefore the function cannot be called in the first place and no code need be generated. EDIT: Your linked example is pattern matching on an with no branches. Here is an empty enum, , so an empty match of an empty enum is exhaustive without any unsafe.
Thanks, I got that part now. But the question raised by : What is the concrete example of macros that have use cases for ? Also, is a never type, if allowed, would we want to make any operations on unreachable?
The actual macro where this came up was a safe wrapper that declares an int-like enum and an array indexed by the enum. Roughly, it creates a type and , and then the implementation for uses where . When has zero elements, this causes the macro to produce malformed code. It is possible to work around this issue by explicitly checking for this case, but I don't really see a reason for it not to work in the first place. Any operation on Void is unreachable. That means that the compiler can do whatever it wants to for codegen here because it doesn't matter, the function is not callable. But from a typing point of view, I think that should have type , not .
It's no surprise that macros run into this -- this happens any time that we have special exceptions. "s without fields can be cast to integers, except if the enum has 0 variants" is such a special exception, and from a language design perspective it has no reason to exist. Not sure what the next step here is -- probably an RFC? This is a language extension after all.
Discussed in the meeting today: We agreed that this seems like a harmless extension (specifically: permitting zero variant enums to be to a usize). We don't feel an RFC is required and we would recommend somebody creating a PR that fixes this and nominates the PR for lang-team consideration, we can do an FCP directly on the PR.
I have opened to fix this issue.

<del> error[E0605]: non-primitive cast: `E` as `isize` --> $DIR/uninhabited-enum-cast.rs:4:20 | LL |     println!("{}", (e as isize).to_string()); |                    ^^^^^^^^^^^^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object error: aborting due to previous error For more information about this error, try `rustc --explain E0605`. </del>


Question:
<!-- 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
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> #![feature(associated_type_defaults)] #![feature(generic_associated_types)] #![allow(incomplete_features)] trait Trait1 { fn foo(); } trait Trait2 { type Associated: Trait1 = Self; //~^ ERROR: the trait bound `Self: Trait1` is not satisfied //~| the size for values of type `Self` cannot be known } impl Trait2 for () {} fn call_foo<T: Trait2>() { T::Associated::foo() } fn main() { call_foo::<()>() } </ins>


Question:
<!-- 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
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> error[E0277]: the trait bound `Self: Trait1` is not satisfied --> $DIR/issue-74816.rs:10:5 | LL |     type Associated: Trait1 = Self; |     ^^^^^^^^^^^^^^^^^------^^^^^^^^ |     |                | |     |                required by this bound in `Trait2::Associated` |     the trait `Trait1` is not implemented for `Self` | help: consider further restricting `Self` | LL | trait Trait2: Trait1 { |             ^^^^^^^^ error[E0277]: the size for values of type `Self` cannot be known at compilation time --> $DIR/issue-74816.rs:10:5 | LL |     type Associated: Trait1 = Self; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |     | |     doesn't have a size known at compile-time |     required by this bound in `Trait2::Associated` | help: consider further restricting `Self` | LL | trait Trait2: Sized { |             ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>