https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW --- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Daniel Frey from comment #5) > I don't know if it is possible for GCC to know, but it feels like it should > know. If one type needs to instantiate another type, this goes on until > either everything worked or GCC stops to instantiate a sub-type because this > is already part of the current "stack" of template instantiations. Maybe I But this is not what seems to be happening. Otherwise it would give some error like "maximum number of recursive instantiations reached". > lack the background to understand what else the compiler could do, but it > seems to me that it must somehow detect where to stop and instead bail out > with an incomplete type which is then triggering the current error message > in the caller which does require the instantiation to be successful. There is indeed a function called can_complete_type_without_circularity() that is invoked in the above testcase. However, the information from this function is never passed down to cxx_incomplete_type_inform(), which is responsible of explaining the problem. If you add a breakpoint at the point of error in typeck2.c you'll see what I mean. I think it should be possible to generate an output like: test.cc: In instantiation of ‘struct bar<int>’: test.cc:4:20: required from ‘struct foo<bar<int> >’ test.cc:14:19: required from here test.cc:11:14: error: ‘bar<T>::p’ has incomplete type foo< bar > p; ^ test.cc:4: note: cyclic instantiation dependency instantiating 'bar<int>' required for 'foo<bar<int> >' typename T::type dummy(); ^ test.cc:11: note: instantiating 'foo<bar<int> >' required for 'bar<int>', end of cycle foo< bar > p; Unfortunately, how to achieve this does not look trivial to me and this still requires some thinking on how to pass this info down, and some trial-and-error to understand the correct conditions that can generate the correct message. I personally do not have the time required to do this and, judging for how long this has been open, I'm afraid no developer currently active considers this a priority. If you are motivated, I would humbly encourage you to try to figure out the solution and propose a patch. This may seem a daunting task, but contributing to GCC is much easier than it was just a few years ago (https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps) and you can work on it at your own pace. Even if it takes you one or two years, it will get fixed faster than if you never tried. Even a draft patch can motivate others to work on this. (I will change the status to NEW, but this does not mean that anyone is going to work on this)