On 2/18/19 12:14 PM, Paolo Carlini wrote:
Hi Jason,
On 18/02/19 19:28, Jason Merrill wrote:
On 2/18/19 5:31 AM, Paolo Carlini wrote:
Hi Jason,
On 18/02/19 10:20, Jason Merrill wrote:
On 2/17/19 6:58 AM, Paolo Carlini wrote:
Hi,
here, when we don't see an initializer we believe we are surely
dealing with a case of C++17 template argument deduction for class
templates, but, in fact, it's just an ill-formed C++14 template
variable specialization. Conveniently, we can use here too the
predicate variable_template_specialization_p. Not 100% sure about
the exact wording of the error message, I added '#' to %qD to
explicitly print the auto-using type too.
I guess we should change the assert to a test, so that we give the
error if we aren't dealing with a class template placeholder.
Variable templates don't seem to be important to test for.
Thanks, simpler patch.
This error is also pretty poor for this testcase, where there is an
initializer.
Well, implementation-wise, certainly init == NULL_TREE and only when
we have an empty pack this specific issue occurs.
In practice, clang simply talks about an empty initializer (during
instantiation, etc, like we do), whereas EDG explicitly says that
pack expansion produces an empty list of expressions. I don't think
that in cp_finish_decl it would be easy for us to do exactly the
same, we simply see a NULL_TREE as second argument. Or we could just
*assume* that we are dealing with the outcome of a pack expansion,
say something like EDG even if we don't have details beyond the fact
that init == NULL_TREE. I believe that without a variadic template
the problem cannot occur, because we catch the empty initializer much
earlier, in grokdeclarator - indeed using a
!CLASS_PLACEHOLDER_TEMPLATE (auto_node) check. What do you think?
Again "instantiated for an empty pack" or something similar?
Perhaps we could complain in the code for empty pack expansion
handling in tsubst_init?
Ah, thanks Jason. In fact, however, tsubst_init isn't currently involved
at all, because, at the end of regenerate_decl_from_template we call by
hand tsubst_expr and assign the result to DECL_INITIAL. Simply changing
that avoids the ICE. However, the error we issue - likewise for the
existing cpp0x/auto31.C - is the rather user-unfriendly
"value-initialization of incomplete type ‘auto’", as produced by
build_value_init. Thus a simple additional test along the lines already
discussed, which now becomes much more simple to implement in a precise
way. Again, wording only tentative. I'm also a little puzzled that,
otherwise, we could get away with tubst_expr instead of tsubst_init...
+ if (type_uses_auto (TREE_TYPE (decl)))
+ {
+ if (complain & tf_error)
+ error ("initializer for %q#D expands to an empty list "
+ "of expressions", decl);
+ return error_mark_node;
+ }
This needs to allow the CLASS_PLACEHOLDER_TEMPLATE case.
And yes, we mustn't call build_value_init for a dependent type; if the
type is dependent, we should just return the NULL_TREE.
Jason
