After lots of experimenting, it appears that VS 2015 has problems when
you list a variate template argument before a normal template argument
in a specialization of a function, The compiler seems happy when the
variate argument is placed at the end of the template arguments.
The nvcc compiler was having problem resolving a template partial
specialization that contained a template param with its own number
list and another param that depended on that template.
The old version of ExecutionObject (that only takes a device) is still
supported, but you will get a deprecated warning if that is what is
defined.
Supporing this also included sending vtkm::cont::Token through the
vtkm::cont::arg::Transport mechanism, which was a change that propogated
through a lot of code.
When expanding variadic parameter packs in ArrayHandleDecorator
implementations, make sure that the types used are appropriate.
Since std::declval is used to test whether or not a method with
specific arguments exists, it is important that the reference types
are correct to ensure that the detection works as expected.
Portals are always passed to implementation functions as rvalue
references, and array handles are always passed as lvalue refs.
The older Xcode 9 compiler has troubles with ArrayHandleDecorator that
are similar to those of earlier Microsoft and Cuda compilers.
Note that the logic behind the changed compiler check has a lot of
guesswork involved. I noticed this problem on a laptop with Xcode 9
installed. However, even though Xcode uses the clang compiler, it
notoriously does not return the actual clang version. Instead, it
returns some toolchain version that has nothing to do with it. I'm
pretty sure Xcode 9 is using clang version 4 under the covers, but
__clang_major__ reports 9. Oddly, Xcode 10 reports __clang_major__ as 8,
so that's not too much help. So instead, we check for
__apple_build_version__, which returns the Xcode version (sort of) and
that seems a reasonable comparison.
Although I have not tried it, I'm willing to bet that the older clang
outside of Xcode will also have issues. Here is where the real guesswork
takes place since I don't have handy compilers to try. Like I said, I
think the internet claims that Xcode 9 is using clang 4, so also add to
the check any compiler that reports itself clang 4 or below.
The tao ones won't compile otherwise. This should be okay, since these
are all just compile time helpers on host-only functions -- they won't
generate different sized data structures etc if we mix them in the
same build.