Change:
<ins> // check-pass // // regression test for #88071 #![feature(const_btree_new)] #![feature(const_fn_trait_bound)] use std::collections::BTreeMap; pub struct CustomMap<K, V>(BTreeMap<K, V>); impl<K, V> CustomMap<K, V> where K: Ord, { pub const fn new() -> Self { CustomMap(BTreeMap::new()) } } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I replaced with this code after creating an empty lib: When running , I expected to see this happen: built successfully Instead, this happened: And when I followed the suggestions it offered, it turned into a type mismatch error and wanted me to cancel the borrowing. : The output of is the same as above.
So this is odd: if you move the Ord bound to the function it works fine: and if you add both bounds it stops working, which is pretty incomprehensible to me:
This is definitely related to , because removing from the function makes it work fine.
It seems that you don't even need to specify a trait bound in your code to cause this bug. The following code : which gives the following very weird output on nightly: (But anyway, there is a trait bound specified in 's source code. Hope this code helps in diagnosing this problem.)
Update: I'm not quite sure what happened, but it seems that this problem is already fixed in the latest nightly, and both code snippets can now be compiled without problem. Maybe it's time to close this issue. (This issue should be some kind of regression introduced at some point between and , according to my tests.)

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit
Okay so this works: this fails:
<details<summaryAnother even more minimized example</summary</detailsOkay, so ultimately, this ends up being very similar to . At some point or another, depending on specific variations of this test, we require that is . This is hairy (I'll get to that shortly), but basically, we can't. This is a problem, and we run into a layout error here: We probably should be giving a smarter error here; enums should always be sized. Okay, so now to explain why we can't prove that is : So looks like to prove this is , we only have to prove that is . Let's imagine the where clause wasn't there. Then, it might be obvious that we could get a recursive cycle (it's a bit complicated, but we do). However, supposedly that where clause is supposed to help us, right? There's a few problems here. But one problem is that when we collect the size predicates, we try to eagerly normalize them . That alone isn't a problem, but it means we can't use that where clause. But, to normalize, we have to check that , we also require that , so ; so, even projecting gives us problems! A simple solution here is to change the associated type definition to be I'm not sure removing the eager normalization call above would itself be enough. We theoretically can normalize, we specifically don't want to (and anywhere else that tries will run into more problems; this includes if the attempts to normalize before proving the sized predicate!).
No longer ICEs since
Woah. Unexpected.

Error message: Commit that reproduces the issue: I get the same error (except for the exact line number) on 1.38, 1.40, beta, and a couple of nightlies. The other issues reachable via the query ( and ) are both about the invocation at , this invocation is at , so this is unlikely to be a duplicate. I haven't yet tried to minimize this: The commit beforehand (1 line difference) on the same nalgebra branch is a compile-fail due to a trait method not being found, and I'm still trying to figure out if that one's a bug in my code.
It would be nice if you could post the backtrace next time :)
Something small-ish:
This is an issue with how performs caching. Predicates are "freshened" before being used as cache keys, which replaces each distinct type variable with a deterministic . This is supposed to allow us to cache predicates across different . Unfortunately, this doesn't take into account relationships between type variables. This leads to the following scenario: tries to select the predicate , where and are distinct type variables (there is no relationship between them). This succeeds, and we cache the result under the key enter a different , and create the type variables and . These region variables end up getting equated to each other - although we don't know the concrete type, it is the same for both of them. try to select the predicate . We try to lookup the cached result under the key . However, this is wrong: we cached the result assuming that and are different types. However, we now have the same type for both substs, so we have no guarantee that our cached result is valid. In the minimized example, we end up caching under . We then try to use this cached result when searching through inherent methods in the impl - we lookup where == == . We get a cached result of , which does not actually apply here. I think we either need to either: much more conservative about the caching we perform incorporate extra knowledge about inference variable relationships into the cache key. It's not obvious to me whether this could be done by unifying 'equivalent' inference variables, or if we would need to somehow store actual constraints from the . This may have soundness implications, especially when it comes to regions.

I don't think we're guaranteed to always ICE on a cache entry that's actually inapplicable.
cc I believe this may have been exposed by , since without it we wouldn't be caching the , However, I think the underlying issue would still exist without that PR.
Can't freshening try to resolve every variable it's replacing, on the fly? Assuming we're still using union-find, one of and should get redirected to the other. cc
I got another ICE with the same codebase, after tweaking it to pass trait resolution. Commit that reproduces the ICE is at . Should I file this as a separate issue, or treat it as related for now? I'll probably try and create a minimal testcase for this next. Backtrace is as follows:
a new issue would be great
Issue gives an error message with very similar strings ("broken MIR in DefId"/"NoSolution") and their minimized example looks like it was minimized from a type that's also used by nalgebra, so I'll try to figure out whether the second ICE is a duplicate of that before filing an issue/adding to that thread.
triage: P-high, removing nomination
cc
I'm familiar with this bug, I can try to dig in and make a recommendation for a fix.
No longer ICEs since

EDITED: MCVE is here: with From the code (Offending implementation at the top, specifically : Changing to does not fix the crash. Changing to compiles. The latter is the correct implementation and I discovered this crash in the middle of some refactoring so I did not expect anything specific to happen except a type checking error. The crash also happens in nightly 2018-7-23 and 2018-7-30.
Do you think you could create a reproducer that doesn't depend on external crates?
I gave it a shot but I think I'm getting other confounding bugs and I can't get the type checking to pass. It's been over a year since I've looked at this Cthulhu's nest of code so I can't even tell if I'm moving in the right direction. Good news is, it still crashes in its original form on ! (from a parent workspace)
ping ICEBreaker-Cleanup-Crew
Error: This team () cannot be pinged via this command;it may need to be to on the master branch. Please let know if you're having trouble with this bot.
Let's see if we can get some help reducing the bug. ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
Hi! First time I have some time to do some ICE work. I could remove the frunk/frunk_core dependency and some trait implementations + simplify the clause, and still have the compiler error : (thanks ) (other older bigger versions : ) You could make and the same type but unless you change the as described above, you will get : Which is I think the intended behavior by the author (once the rustc bug is fixed). Removing type from also stops the bug from occuring. Curious to know how it pans out.
removing all comments is also recommended ;) but good work so far!
Thanks to the Rust playground provided by I was able to reduce a little bit more the example, removing a bunch more generic constraints, some functions, some useless body functions.
No longer ICEs since