On 3/27/19 3:08 PM, Marek Polacek wrote:
I noticed that this test doesn't compile because build_converted_constant_expr
failed to consider explicit conversion functions. That's wrong: while Core
Issue 1981 specifies that explicit conversion functions are not considered for
contextual conversions, they are considered in contextual conversions to bool,
as defined in Core 2039.
Fixed by adding a new wrapper that uses LOOKUP_NORMAL instead of
LOOKUP_IMPLICIT.
Besides [dcl.fct.spec], these: [except.spec], [dcl.dcl]/6 (static_assert),
[stmt.if] (constexpr if) all talk about "a contextually converted constant
expression of type bool", so it would seem to make sense to use
build_converted_constant_bool_expr for them also. E.g. use that instead of
perform_implicit_conversion_flags in build_noexcept_spec. But that doesn't
work for this test:
int e();
int fn() noexcept(e);
because build_converted_constant_expr would issue a conversion error. We're
converting "e" to "bool". We have a ck_lvalue conversion from "int f()" to
"int (*f)()" and then a ck_std conversion from "int (*f)()" to bool. Those
should work fine but we issue an error for the ck_std conversion.
Converting a pointer to bool is a "boolean conversion", which is not
allowed under the rules for a converted constant expression
([expr.const]p7). So we should reject that testcase.
Also build_converted_constant_expr doesn't have the processing_template_decl
handling that perform_implicit_conversion_flags does, which (I believe) lead me
to changing check_narrowing to use maybe_constant_value instead of
fold_non_dependent_expr.
As I was saying elsewhere, I think that change was probably a mistake,
and that we should have fixed that bug by changing the caller instead.
Anyway, this patch should be safe.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
Jason
