Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

| LL | fn f_copy<T: Copy>(t: T) {} |              ^^^^ required by this bound in `f_copy` <ins> help: consider removing this method call, as the receiver has type `&'static str` and `&'static str: Copy` trivially holds | LL -     f_copy("".to_string()); LL +     f_copy(""); | </ins> error[E0277]: the trait bound `S: Clone` is not satisfied --> $DIR/issue-84973-blacklist.rs:16:13


Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

<ins> struct Foo; struct Bar; impl From<Bar> for Foo { fn from(_: Bar) -> Self { Foo } } fn qux(_: impl From<Bar>) {} fn main() { qux(Bar.into()); //~ ERROR type annotations needed //~| HELP try using a fully qualified path to specify the expected types //~| HELP consider removing this method call, as the receiver has type `Bar` and `Bar: From<Bar>` trivially holds } </ins>


Question:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment

<ins> error[E0283]: type annotations needed --> $DIR/argument-with-unnecessary-method-call.rs:8:13 | LL |     qux(Bar.into()); |     ---     ^^^^ |     | |     required by a bound introduced by this call | = note: cannot satisfy `_: From<Bar>` note: required by a bound in `qux` --> $DIR/argument-with-unnecessary-method-call.rs:6:16 | LL | fn qux(_: impl From<Bar>) {} |                ^^^^^^^^^ required by this bound in `qux` help: try using a fully qualified path to specify the expected types | LL |     qux(<Bar as Into<T>>::into(Bar)); |         +++++++++++++++++++++++   ~ help: consider removing this method call, as the receiver has type `Bar` and `Bar: From<Bar>` trivially holds | LL -     qux(Bar.into()); LL +     qux(Bar); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0283`. </ins>


Question:
This is a variant of that was not fixed by still fails with
Given that libcore and liballoc enable this feature, I am rather concerned they could inadvertently use it in a way that is still unsound. Also, unless we can fix this, the feature should probably be to to warn people against using it.
rustc bootstraps successfully with applied, so at least right now that does not seem to be the case (modulo the part of libstd that rustc never monomorphizes). Of course, that could change any time, there is no check for this.
Yes, thanks for opening this. To be specific, the issue here is centered on this line: and the fact that we have , and LLVM alloca's don't respect the alignment requirements, right? I think there may be a separate issue on that. (Link?) But: one thing we had discussed was separating out the "sound" part and the "unsound" part into distinct feature gates, so that we can enable only the former in libstd. Perhaps that's a good focus for this issue?
cc who had discussed the separate feature gate, and who might be interested in doing the follow-up work to create that gate.
Yes. Oh, I didn't know that. Let's see if someone finds it.^^ Unlike the other unsound features, this is one where we don't even have a plan for how to soundly implement it. Not sure how much I like keeping that around.
Yes, I see that argument. I'm reminded of , which limits the max alignment to 4K because of limits in dynamic linkers, though there's no real connection. It's just that part of the challenge here is that the alignment of a is totally unknown -- it's not like we can conservatively align to 64 bytes or something.
If lands we could conservatively align to 4k here. :rofl: (no I am not serious)
Assigning as , removing and nominating for discussion on our next weekly meeting.
Can't we do something dynamic where we allocate and align it ourselves? Also, this has been discussed before, hasn't it?
With being stable, this can be observed in stable compiler: EDIT: its fixed in nightly, never mind.
I don't know -- in we mostly talked about how to mitigate the effect on stable Rust. D'oh, I somehow forgot that one can manually implement "aligned" allocation on top of an unaligned allocator. Of course that would work. That's probably better than killing this part of codegen entirely.^^
, leaving the nomination up for now as requested by He wants to open some fresh issues about this.
Now that I've created more specific issues to track the important sub-tasks identified here, I think we can remove this from the nominated tickets.
Given that this feature has been removed from core/alloc and is unstable, I'm going to downgrade this to P-medium. This should obviously block stabilization of , but doesn't need special attention outside of that.

indirect_dest: PlaceRef<'tcx, V>, ) { debug!("OperandRef::store_unsized: operand={:?}, indirect_dest={:?}", self, indirect_dest); <del> let flags = MemFlags::empty(); </del> // `indirect_dest` must have `*mut T` type. We extract `T` out of it. let unsized_ty = indirect_dest .layout


Question:
This is a variant of that was not fixed by still fails with
Given that libcore and liballoc enable this feature, I am rather concerned they could inadvertently use it in a way that is still unsound. Also, unless we can fix this, the feature should probably be to to warn people against using it.
rustc bootstraps successfully with applied, so at least right now that does not seem to be the case (modulo the part of libstd that rustc never monomorphizes). Of course, that could change any time, there is no check for this.
Yes, thanks for opening this. To be specific, the issue here is centered on this line: and the fact that we have , and LLVM alloca's don't respect the alignment requirements, right? I think there may be a separate issue on that. (Link?) But: one thing we had discussed was separating out the "sound" part and the "unsound" part into distinct feature gates, so that we can enable only the former in libstd. Perhaps that's a good focus for this issue?
cc who had discussed the separate feature gate, and who might be interested in doing the follow-up work to create that gate.
Yes. Oh, I didn't know that. Let's see if someone finds it.^^ Unlike the other unsound features, this is one where we don't even have a plan for how to soundly implement it. Not sure how much I like keeping that around.
Yes, I see that argument. I'm reminded of , which limits the max alignment to 4K because of limits in dynamic linkers, though there's no real connection. It's just that part of the challenge here is that the alignment of a is totally unknown -- it's not like we can conservatively align to 64 bytes or something.
If lands we could conservatively align to 4k here. :rofl: (no I am not serious)
Assigning as , removing and nominating for discussion on our next weekly meeting.
Can't we do something dynamic where we allocate and align it ourselves? Also, this has been discussed before, hasn't it?
With being stable, this can be observed in stable compiler: EDIT: its fixed in nightly, never mind.
I don't know -- in we mostly talked about how to mitigate the effect on stable Rust. D'oh, I somehow forgot that one can manually implement "aligned" allocation on top of an unaligned allocator. Of course that would work. That's probably better than killing this part of codegen entirely.^^
, leaving the nomination up for now as requested by He wants to open some fresh issues about this.
Now that I've created more specific issues to track the important sub-tasks identified here, I think we can remove this from the nominated tickets.
Given that this feature has been removed from core/alloc and is unstable, I'm going to downgrade this to P-medium. This should obviously block stabilization of , but doesn't need special attention outside of that.

bug!("store_unsized called with a sized value") }; <del> // FIXME: choose an appropriate alignment, or use dynamic align somehow let max_align = Align::from_bits(128).unwrap(); let min_align = Align::from_bits(8).unwrap(); // Allocate an appropriate region on the stack, and copy the value into it let (llsize, _) = glue::size_and_align_of_dst(bx, unsized_ty, Some(llextra)); let lldst = bx.byte_array_alloca(llsize, max_align); bx.memcpy(lldst, max_align, llptr, min_align, llsize, flags); </del> <ins> // Allocate an appropriate region on the stack, and copy the value into it. Since alloca // doesn't support dynamic alignment, we allocate an extra align - 1 bytes, and align the // pointer manually. let (size, align) = glue::size_and_align_of_dst(bx, unsized_ty, Some(llextra)); let one = bx.const_usize(1); let align_minus_1 = bx.sub(align, one); let size_extra = bx.add(size, align_minus_1); let min_align = Align::ONE; let alloca = bx.byte_array_alloca(size_extra, min_align); let address = bx.ptrtoint(alloca, bx.type_isize()); let neg_address = bx.neg(address); let offset = bx.and(neg_address, align_minus_1); let dst = bx.inbounds_gep(bx.type_i8(), alloca, &[offset]); bx.memcpy(dst, min_align, llptr, min_align, size, MemFlags::empty()); </ins> // Store the allocated region and the extra to the indirect place. <del> let indirect_operand = OperandValue::Pair(lldst, llextra); </del> <ins> let indirect_operand = OperandValue::Pair(dst, llextra); </ins> indirect_operand.store(bx, indirect_dest); } }


Question:
This is a variant of that was not fixed by still fails with
Given that libcore and liballoc enable this feature, I am rather concerned they could inadvertently use it in a way that is still unsound. Also, unless we can fix this, the feature should probably be to to warn people against using it.
rustc bootstraps successfully with applied, so at least right now that does not seem to be the case (modulo the part of libstd that rustc never monomorphizes). Of course, that could change any time, there is no check for this.
Yes, thanks for opening this. To be specific, the issue here is centered on this line: and the fact that we have , and LLVM alloca's don't respect the alignment requirements, right? I think there may be a separate issue on that. (Link?) But: one thing we had discussed was separating out the "sound" part and the "unsound" part into distinct feature gates, so that we can enable only the former in libstd. Perhaps that's a good focus for this issue?
cc who had discussed the separate feature gate, and who might be interested in doing the follow-up work to create that gate.
Yes. Oh, I didn't know that. Let's see if someone finds it.^^ Unlike the other unsound features, this is one where we don't even have a plan for how to soundly implement it. Not sure how much I like keeping that around.
Yes, I see that argument. I'm reminded of , which limits the max alignment to 4K because of limits in dynamic linkers, though there's no real connection. It's just that part of the challenge here is that the alignment of a is totally unknown -- it's not like we can conservatively align to 64 bytes or something.
If lands we could conservatively align to 4k here. :rofl: (no I am not serious)
Assigning as , removing and nominating for discussion on our next weekly meeting.
Can't we do something dynamic where we allocate and align it ourselves? Also, this has been discussed before, hasn't it?
With being stable, this can be observed in stable compiler: EDIT: its fixed in nightly, never mind.
I don't know -- in we mostly talked about how to mitigate the effect on stable Rust. D'oh, I somehow forgot that one can manually implement "aligned" allocation on top of an unaligned allocator. Of course that would work. That's probably better than killing this part of codegen entirely.^^
, leaving the nomination up for now as requested by He wants to open some fresh issues about this.
Now that I've created more specific issues to track the important sub-tasks identified here, I think we can remove this from the nominated tickets.
Given that this feature has been removed from core/alloc and is unstable, I'm going to downgrade this to P-medium. This should obviously block stabilization of , but doesn't need special attention outside of that.

<ins> // Test that unsized locals uphold alignment requirements. // Regression test for #71416. // run-pass #![feature(unsized_locals)] #![allow(incomplete_features)] use std::any::Any; #[repr(align(256))] #[allow(dead_code)] struct A { v: u8 } impl A { fn f(&self) -> *const A { assert_eq!(self as *const A as usize % 256, 0); self } } fn mk() -> Box<dyn Any> { Box::new(A { v: 4 }) } fn main() { let x = *mk(); let dwncst = x.downcast_ref::<A>().unwrap(); let addr = dwncst.f(); assert_eq!(addr as usize % 256, 0); } </ins>


Question:
A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true

<ins> #[derive(PartialEq, Eq)] enum X { A, B, C, } fn main() { let x = X::A; let y = Some(X::A); match (x, y) { //~^ ERROR non-exhaustive patterns: `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 //~| more not covered (_, None) => false, (v, Some(w)) if v == w => true, (X::B, Some(X::C)) => false, (X::B, Some(X::A)) => false, (X::A, Some(X::C)) | (X::C, Some(X::A)) => false, }; } </ins>


Question:
A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true

<ins> error[E0004]: non-exhaustive patterns: `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered --> $DIR/issue-72377.rs:8:11 | LL |     match (x, y) { |           ^^^^^^ patterns `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `(X, Option<X>)` error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>


Question:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim

use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; use rustc_session::Session; <ins> use rustc_span::hygiene::DesugaringKind; </ins> use rustc_span::Span; #[derive(Clone, Copy, Debug, PartialEq)]


Question:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim

label: &Destination, cf_type: &str, ) -> bool { <del> if self.cx == LabeledBlock { </del> <ins> if !span.is_desugaring(DesugaringKind::QuestionMark) && self.cx == LabeledBlock { </ins> if label.label.is_none() { struct_span_err!( self.sess,


Question:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim

<ins> // compile-flags: --edition 2018 #![feature(label_break_value, try_blocks)] // run-pass fn main() { let _: Result<(), ()> = try { 'foo: { Err(())?; break 'foo; } }; } </ins>


Question:
The following code: gives the following output: The "unused lifetimes" warning is redundant - not using a lifetime parameter is a hard error, so the warning gives no additional information.
Note that this lint still makes sense for functions: But then running clippy on the following looks dumb (the lints are redundant): I don't really know the compiler internals, but should this lint just skip structs ? (is that even possible ?)
label +E-needs-test This was fixed in but no test was for nonduplication.

<ins> // Check that `unused_lifetimes` lint doesn't duplicate a "parameter is never used" error. // Fixed in <https://github.com/rust-lang/rust/pull/96833>. // Issue: <https://github.com/rust-lang/rust/issues/72587>. #![warn(unused_lifetimes)] struct Foo<'a>; //~^ ERROR parameter `'a` is never used fn main() {} </ins>


Question:
The following code: gives the following output: The "unused lifetimes" warning is redundant - not using a lifetime parameter is a hard error, so the warning gives no additional information.
Note that this lint still makes sense for functions: But then running clippy on the following looks dumb (the lints are redundant): I don't really know the compiler internals, but should this lint just skip structs ? (is that even possible ?)
label +E-needs-test This was fixed in but no test was for nonduplication.

<ins> error[E0392]: lifetime parameter `'a` is never used --> $DIR/dedup.rs:6:12 | LL | struct Foo<'a>; |            ^^ unused lifetime parameter | = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0392`. </ins>


Question:
I just tried the latest nightly (rustc 1.45.0-nightly ( 2020-06-01)) and noticed it can't compile one of the crates I work on. The crate does have an enum with a a huge number of variants (almost 6000), for which I use serde to derive Serialize and Deserialize. When building, even with just 'cargo check', the build fails with It works on stable 1.43.1. I tried running rustc under gdb. It didn't crash exactly the same way, I got SIGSEGV instead. Looking at the callstack in gdb, it is suspiciously deep ( functions deep). The top most functions are: If I reduce the number of enum variants to 5000, or stop using serde to derive Serialize/Deserialize, it starts working again. Since it works using stable, but not using nightly, I thought it might be some kind of regression. I totally realize this may not be a bug and that what I'm doing (Serde + giant enum) is just not a good idea. Accept my apologies if this kind of thing shouldn't be reported here!
cc -- I believe should have fixed this but I guess we're missing at least this case?
As an experiment I tried doubling the number of enum variants and compiling using stable. That still worked. So it seems the code wasn't just on the brink to stop working using the stable compiler.
Here is a github repo with a minimized test case for this issue:
It introduced a mechanism for dealing with this kind of issue, but I don’t doubt that we might have missed instances where the compiler is doing something recursive. MIR construction for matches appears to be one of these cases.
Yeah, that's what I expected, I just recalled seeing some commentary suggesting that we'd perhaps covered all cases. Definitely not unexpected that we didn't, though, nor did I intend to imply we should have :)
The beta seems to not have the problem. The problem does not occur with "rustc 1.44.0-beta.4 ( 2020-05-23)".
I saw the 'E-needs-mcve'-tag. Did you see my repro-case? (but maybe you're talking about something more self-contained, not referencing 'serde'?)
I saw the repo, but it still needs some work to be reduced to a viable regression test case that could be included into the repo along with fix. This is what I’m working on now as I already have the fix itself.
Assigning .
If anyone else gets here having the same problem, manually implementing Serialize and Deserialize rather than relying on serde-derive, is one way around the problem. I adapted the examples at for my enum and this made the compile time insignificant. It also improved performance using the old rust considerably.
Mhh, I remember having seen some other issues related to derive macros recently... cc who might know.

use crate::build::{BlockAnd, BlockAndExtension, Builder}; use crate::build::{GuardFrame, GuardFrameLocal, LocalsForNode}; use crate::hair::{self, *}; <del> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; </del> <ins> use rustc_data_structures::{fx::{FxHashMap, FxHashSet}, stack::ensure_sufficient_stack}; </ins> use rustc_hir::HirId; use rustc_index::bit_set::BitSet; use rustc_middle::middle::region;


Question:
I just tried the latest nightly (rustc 1.45.0-nightly ( 2020-06-01)) and noticed it can't compile one of the crates I work on. The crate does have an enum with a a huge number of variants (almost 6000), for which I use serde to derive Serialize and Deserialize. When building, even with just 'cargo check', the build fails with It works on stable 1.43.1. I tried running rustc under gdb. It didn't crash exactly the same way, I got SIGSEGV instead. Looking at the callstack in gdb, it is suspiciously deep ( functions deep). The top most functions are: If I reduce the number of enum variants to 5000, or stop using serde to derive Serialize/Deserialize, it starts working again. Since it works using stable, but not using nightly, I thought it might be some kind of regression. I totally realize this may not be a bug and that what I'm doing (Serde + giant enum) is just not a good idea. Accept my apologies if this kind of thing shouldn't be reported here!
cc -- I believe should have fixed this but I guess we're missing at least this case?
As an experiment I tried doubling the number of enum variants and compiling using stable. That still worked. So it seems the code wasn't just on the brink to stop working using the stable compiler.
Here is a github repo with a minimized test case for this issue:
It introduced a mechanism for dealing with this kind of issue, but I don’t doubt that we might have missed instances where the compiler is doing something recursive. MIR construction for matches appears to be one of these cases.
Yeah, that's what I expected, I just recalled seeing some commentary suggesting that we'd perhaps covered all cases. Definitely not unexpected that we didn't, though, nor did I intend to imply we should have :)
The beta seems to not have the problem. The problem does not occur with "rustc 1.44.0-beta.4 ( 2020-05-23)".
I saw the 'E-needs-mcve'-tag. Did you see my repro-case? (but maybe you're talking about something more self-contained, not referencing 'serde'?)
I saw the repo, but it still needs some work to be reduced to a viable regression test case that could be included into the repo along with fix. This is what I’m working on now as I already have the fix itself.
Assigning .
If anyone else gets here having the same problem, manually implementing Serialize and Deserialize rather than relying on serde-derive, is one way around the problem. I adapted the examples at for my enum and this made the compile time insignificant. It also improved performance using the old rust considerably.
Mhh, I remember having seen some other issues related to derive macros recently... cc who might know.

split_or_candidate |= self.simplify_candidate(candidate); } <del> if split_or_candidate { // At least one of the candidates has been split into subcandidates. // We need to change the candidate list to include those. let mut new_candidates = Vec::new(); </del> <ins> ensure_sufficient_stack(|| { if split_or_candidate { // At least one of the candidates has been split into subcandidates. // We need to change the candidate list to include those. let mut new_candidates = Vec::new(); </ins> <del> for candidate in candidates { candidate.visit_leaves(|leaf_candidate| new_candidates.push(leaf_candidate)); </del> <ins> for candidate in candidates { candidate.visit_leaves(|leaf_candidate| new_candidates.push(leaf_candidate)); } self.match_simplified_candidates( span, start_block, otherwise_block, &mut *new_candidates, fake_borrows, ); } else { self.match_simplified_candidates( span, start_block, otherwise_block, candidates, fake_borrows, ); </ins> } <del> self.match_simplified_candidates( span, start_block, otherwise_block, &mut *new_candidates, fake_borrows, ); } else { self.match_simplified_candidates( span, start_block, otherwise_block, candidates, fake_borrows, ); }; </del> <ins> }); </ins> } fn match_simplified_candidates(