clang++ does not match templates with inheritance

[Quuxplusone]

Bugzilla Link	PR33995
Status	RESOLVED INVALID
Importance	P normal
Reported by	Marcus Calhoun-Lopez (mcalhoun@macports.org)
Reported on	2017-07-30 11:06:36 -0700
Last modified on	2017-08-12 15:22:20 -0700
Version	4.0
Hardware	Macintosh MacOS X
CC	dgregor@apple.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

While attempting to compile a project called VIGRA
(https://github.com/macports/macports-ports/tree/master/graphics/vigra):
   * using /usr/bin/clang++ worked (Apple provided Clang)
   * using /opt/local/bin/g++-mp-6 worked (GCC version 6.3.0)
   * using /opt/local/bin/clang++-mp-4.0 Failed (Clang 4.0.1)
   * using /opt/local/bin/clang++-mp-5.0 Failed (Clang 5.0)

GCC and Clang are built using MacPorts (https://www.macports.org).
/usr/bin/clang++ is provided by Apple and is version 8.1.0.

------------------------------------------------------------------------------
The locally built clang++ gives me the error:
------------------------------------------------------------------------------
test.cxx:35:5: error: no matching function for call to
'gaussianDivergenceMultiArray'
    gaussianDivergenceMultiArray(array, res);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test.cxx:40:1: note: in instantiation of function template specialization
'pythonGaussianDivergence<double, 2>' requested here
pythonGaussianDivergence<double,2>(NumpyArray<2, TinyVector<double, 2> > array,
^
test.cxx:13:1: note: candidate template ignored: could not match
'MultiArrayView' against 'NumpyArray'
gaussianDivergenceMultiArray(MultiArrayView<N, TinyVector<T1, N> > const &
vectorField,
^
1 error generated.
------------------------------------------------------------------------------

------------------------------------------------------------------------------
The smallest test case I can get it down is:
------------------------------------------------------------------------------
template <unsigned N, class T>
class MultiArrayView
{
};

template <class T, int SIZE>
class TinyVector
{
};

template <unsigned N, class T1, class T2>
inline void
gaussianDivergenceMultiArray(MultiArrayView<N, TinyVector<T1, N> > const &
vectorField,
                             MultiArrayView<N, T2> divergence)
{
}

template<unsigned N, class T>
struct NumpyArrayTraits
{
    typedef T value_type;
};

template <unsigned N, class T>
class NumpyArray
: public MultiArrayView<N, typename NumpyArrayTraits<N, T>::value_type>
{
};

template <class PixelType, unsigned N>
void
pythonGaussianDivergence(NumpyArray<N, TinyVector<PixelType, N> > array,
                         NumpyArray<N, double > res)
{
    gaussianDivergenceMultiArray(array, res);
}

template
void
pythonGaussianDivergence<double,2>(NumpyArray<2, TinyVector<double, 2> > array,
                   NumpyArray<2, double > res);
------------------------------------------------------------------------------

[Quuxplusone]

> template <class T, int SIZE>
> class TinyVector

> template <unsigned N, class T1, class T2>
> inline void
> gaussianDivergenceMultiArray(MultiArrayView<N, TinyVector<T1, N> >

You have a type mismatch between the N in TinyVector<T1, N> here and the type
of the non-type template parameter SIZE of TinyVector. See
[temp.deduct.type]p18:

"If P has a form that contains <i>, and if the type of i differs from the type
of the corresponding template parameter of the template named by the enclosing
simple-template-id, deduction fails."

So Clang is correct to reject this... though it'd be better if we gave the
deduction failure message for deducing against the MultiArrayView base class
rather than the one for deducing against the derived class.

[Quuxplusone]

Thank you for looking into this.
The developer of Vigra is working on this problem based on the helpful
suggestions here.
See
https://mailhost.informatik.uni-hamburg.de/pipermail/vigra/2017-July/thread.html#1363
and
https://mailhost.informatik.uni-hamburg.de/pipermail/vigra/2017-August/thread.html#1367

[Quuxplusone]

Thanks for looking into this.
I will close this report since the code is correctly rejected.
For the sake of completeness, the developers of VIGRA seem to have fixed the
problem on their end (see
https://github.com/ukoethe/vigra/commit/b2ff44fbffcfa3f9e2862d890f43ad7cf588f565).