This is my first frontend contribution. While it fixes the crash and produces an explanatory error message, the message isn't quite right. I don't understand the message generation system so I might need help. Or, it looks like there's an issue with template backtraces at the moment anyway, so there might be an interaction with another known bug.
The problem occurs when operator-> drill-down behavior is infinitely chained,
for example with a template
template< int n >
t< n + 1 >
t< n >::operator->()
There is no cycle to signal endlessness, and no template nesting, as drill-down
is implemented as a deep expression, not tail-calls. The result is that the
compiler hangs.
My solution is to pretend that there is template nesting, presuming the user
will find this intuitive. There is the added benefit of the maximum chain
length being configured by the template nesting limit.
Drill-down is implemented by build_x_arrow. If operator-> resolves, it calls it
and uses the result type to lookup another operator->. I'd like to re-open a
template context related to operator-> after generating the call. The function
push_tinst_level seems to relate only to diagnostics, with no semantic effect,
so it seems a good candidate.
Optimally the re-opened context would be the preceding operator-> function
itself, to create the illusion of nested calls. However, the result of
build_new_op may be a target_expr or a call_expr. I'm not sure of the best way
to recover the function declaration from this ambiguous tree, nor whether it
would a performance issue (i.e., too much work for the reward).
The identity of the class containing the *next* operator-> call is easy to
recover, however, since it is the type of the expression from build_new_op.
This introduces an off-by-one error, and gets us a class template rather than
the more relevant function member. These problems shouldn't matter since this
is all just for diagnostics. But perhaps the discrepancy between having a
function type and a class type is interfering with message generation?
Thanks for the help and consideration!
endless_arrow.clog
Description: Binary data
endless_arrow.patch
Description: Binary data
