C++ PATCH to implement C++20 P0892R2 - explicit(bool)

[Jason Merrill]

On Tue, Oct 2, 2018 at 5:25 PM Marek Polacek <polacek@redhat.com> wrote:
>
> On Mon, Oct 01, 2018 at 07:47:10PM -0400, Jason Merrill wrote:
> > On Mon, Oct 1, 2018 at 6:41 PM Marek Polacek <polacek@redhat.com> wrote:
> > >
> > > This patch implements C++20 explicit(bool), as described in:
> > > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0892r2.html>.
> > >
> > > I tried to follow the noexcept specifier implementation where I could, which
> > > made the non-template parts of this fairly easy.  To make explicit(expr) work
> > > with dependent expressions, I had to add DECL_EXPLICIT_SPEC to lang_decl_fn,
> > > which serves as a vessel to get the explicit-specifier to tsubst_function_decl
> > > where I substitute the dependent arguments.
> >
> > What's the impact of that on memory consumption?  I'm nervous about
> > adding another word to most functions when it's not useful to most of
> > them.  For several similar things we've been using hash tables on the
> > side.
>
> Yeah, that is a fair concern.  I'm not sure if I know of a good way to measure
> it.  I took wide-int.ii and ran /usr/bin/time -v ./cc1plus; then it's roughly
> Maximum resident set size (kbytes): 95020
> vs.
> Maximum resident set size (kbytes): 95272
> which doesn't seem too bad but I don't know if it proves anything.
>
> If we went with the hash table, would it work like this?
> 1) have a hash table mapping decls (key) to explicit-specifiers
> 2) instead of setting DECL_EXPLICIT_SPEC put the parsed explicit-specifier
>    into the table
> 3) in tsubst_function_decl look if the fn decl is associated with any
>    explicit-specifier, if it is, substitute it, and set DECL_NONCONVERTING_P
>    accordingly.

Yes.  I think you want to use tree_cache_map so you don't have to
worry about removing entries from the table if the decl is GC'd.

> > > +/* Create a representation of the explicit-specifier with
> > > +   constant-expression of EXPR.  COMPLAIN is as for tsubst.  */
> > > +
> > > +tree
> > > +build_explicit_specifier (tree expr, tsubst_flags_t complain)
> > > +{
> > > +  if (processing_template_decl && value_dependent_expression_p (expr))
> > > +    /* Wait for instantiation.  tsubst_function_decl will take care of it.  */
> > > +    return expr;
> > > +
> > > +  expr = perform_implicit_conversion_flags (boolean_type_node, expr,
> > > +                                           complain, LOOKUP_NORMAL);
> > > +  expr = instantiate_non_dependent_expr (expr);
> > > +  expr = cxx_constant_value (expr);
> > > +  return expr;
> > > +}
> >
> > Is there a reason not to use build_converted_constant_expr?
>
> build_converted_constant_expr doesn't allow narrowing conversions but we should
> allow them in explicit-specifier which takes "contextually converted constant
> expression of type bool", much like in
>
> constexpr int foo () { return 42; }
> static_assert (foo());
>
> Right?

That's what the standard seems to require, but I think that's broken;
I cc'd you on my email to the reflector.

Jason