https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
There can be three scenarios:
1) decltype is in a template and it has no dependent expressions -- PROBLEM
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so we just return compound_literal; without
calling check_narrowing
- then we call finish_decltype_type, EXPR is {NON_LVALUE_EXPR <2.0e+0>} but
that is not instantiation_dependent_uneval_expression_p, so we just take its
unlowered_expr_type and return it, without calling check_narrowing.
2) decltype is in a template and has dependent expressions
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so we just return compound_literal; without
calling check_narrowing
- then we call finish_decltype_type, EXPR is
instantiation_dependent_uneval_expression_p, so we create DECLTYPE_TYPE with
the dependent expression
- tsubst_copy_and_build then calls
RETURN (finish_compound_literal (type, r, complain, cl));
while substituting the CONSTRUCTOR. Now processing_template_decl is 0, so
finish_compound_literal calls check_narrowing, so we detect it.
3) decltype is not in a template
- we call finish_compound_literal from cp_parser_functional_cast, but
processing_template_decl is 0, so we call check_narrowing so we detect it.
So one idea would to be to walk_tree on the expression at the end of
finish_decltype_type, looking for compound literals and call check_narrowing.
