On 2/20/19 10:31 AM, Marek Polacek wrote:
Here we ICE when substituting a deferred noexcept-specifier, because it
contains 'this', a PARM_DECL, in an evaluated context. This is different
from "noexcept(noexcept(this))" where the noexcept operator's operand is
an unevaluated operand. We crash within tsubst_copy's PARM_DECL handling
of a 'this' PARM_DECL:
15488 gcc_assert (cp_unevaluated_operand != 0)
It'd be wrong to mess with cp_unevaluated_operand (or current_class_*), and
since we only check the expression's constness after substituting in
maybe_instantiate_noexcept, one fix would be the following.
This is not just about 'this', as the 87844 test shows: here we also have
a parameter whose value we're trying to determine -- it's a template arg
of a late-specified return type. Returning the original value in tsubst_copy
and leaving the later code to complain seems to work here as well. Just
removing the assert should work as well.
I'm reluctant to mess with this assert, as it catches a lot of lambda bugs.
I think we want to register_parameter_specializations when instantiating
deferred noexcept, so that tsubst_copy can find the right decls.
Jason
