https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115746
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppalka at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid I'd appreciate some guidance, mainly with how to implement the
satisfaction checking of fold expanded constraints.
The way I've implemented it is that when testing its satisfaction, another
argument with TREE_LIST of the packs and corresponding current index (which
pack element is currently being tested for satisfaction) is passed, in
sat_hasher::hash
and sat_hasher::equal this is looked up and in tsubst_parameter_mapping too and
if it sees a pack, it replaces it with the pack element.
Now, this works fine for the easy testcases (concepts/variadic{2,4}.C,
cpp26/fold-constr{1,2,4}.C), where in the atomic constraint mapping the
template argument is used directly, but it doesn't work and causes ICE on the
concepts/diagnostic3.C and cpp26/fold-constr3.C testcases; e.g. in
diagnostic3.C, the fold expanded constraint notes it is a pack expansion of the
Is pack, but in the mapping it uses S<Is> as the parameter.
I also think cpp26/fold-constr5.C fails because of that (though, in there there
is a mismatch between my expectations where I expect
static_assert (bar <int> ());
to fail because
C<typename U::type> && ... && C<typename T::type>
should be normalized to
(C<typename U::type> && ...) && C<typename T::type>
where U is an empty pack, so (C<typename U::type> && ...) should be satisfied,
but
C<typename T::type> shouldn't be because int::type is invalid, and for
conjunction I think that should then be unsatisfied, but clang++ trunk doesn't
diagnose that one).
In fold-constr6.C static_assert (U<int>::bar<int> ()); is rejected by clang++
trunk and I think in that case it shouldn't subsume but with my patch
apparently it is accepted.
