On 2/25/19 10:27 AM, Paolo Carlini wrote:
Hi,
this error recovery regression has to do with the recent changes
committed by Jason for c++/88368. What happens is that
maybe_instantiate_noexcept fails the hard way, thus, toward the end of
the function, doesn't update TREE_TYPE (fn) and just returns false.
process_subob_fn doesn't notice and proceeds to call
merge_exception_specifiers anyway where of course the gcc_assert
(!DEFERRED_NOEXCEPT_SPEC_P (add)) triggers, because
maybe_instantiate_noexcept has not done its normal job. To improve
error-recovery I think we can simply leave *spec_p alone in such cases,
because we would merge the *spec_p with a TYPE_RAISES_EXCEPTIONS
(TREE_TYPE (fn)) where TREE_TYPE (fn) has not been normally computed. I
tried a few other things which prima facie looked sensible but nothing
else worked - eg, returning false from maybe_instantiate_noexcept and
also updating TREE_TYPE (fn) to a noexcept_false_spec variant causes
regressions exactly for the testcases of c++/88368.
If maybe_instantiate_noexcept returns false, I think we should set
*spec_p to error_mark_node.
Jason
