On Thu, Mar 28, 2019 at 02:02:47PM -0400, Jason Merrill wrote: > 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.
Oh, right (though clang also accepts it). I'll see if there's anything else that breaks if I use build_converted_constant_expr instead of perform_implicit_conversion. > > 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. I need to address that. Unfortunately adding a sentinel in the caller broke so much stuff :(. > > Anyway, this patch should be safe. > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > OK. Thanks, committed. Marek
