On 2/26/19 10:22 AM, Paolo Carlini wrote:
Hi,
On 26/02/19 15:33, Jason Merrill wrote:
On 2/26/19 5:42 AM, Paolo Carlini wrote:
Hi,
the issue is rather easy to explain: after Alexandre' change in
r266874, which simplified the condition at the beginning of
build_noexcept_spec to evaluate early all the expressions which
aren't deferred or value-dependent, we obviously ICE during
error-recovery on the new testcase because an expression which isn't
a potential constant filters through and cxx_constant_value can't
handle it. We can avoid this in various ways - for example by adding
a gate && potential_rvalue_constant_expression_p (expr) in the
condition at the beginning of build_noexcept_spec and adjust/remove
the final gcc_assert (which is already a bit obsolete wrt Alexandre'
change). Or we can handle this earlier, in
cp_parser_noexcept_specification_opt - in complete analogy, with,
say, cp_parser_initializer_list - thus don't let through those
expressions at all (possible variant: set expr = error_mark_node),
which has the advantage of avoiding a duplicate
potential_rvalue_constant_expression call (note: in the parser
build_no_except_spec is called only by
cp_parser_noexcept_specification_opt)
All those variants pass the testsuite on x86_64-linux.
What happens if 'sm' is constexpr?
Well, if 'sm' is constexpr we accept the snippet, as we should, AFAICS.
This is true for all my tentative patches, I think, certainly for what I
posted.
Yes, we should. Then the patch is OK.
Jason
