Eg:
```
vtkm::Float32 -> F32
vtkm::Int64 -> I64
vtkm::Vec< vtkm::Float32, 3 > -> Vec3f_32
vtkm::Vec< vtkm::Pair< vtkm::Int32, vtkm::Float64 > -> Vec<Pair<I32, F64>>
```
This makes the benchmark names a lot shorter to keep rows tabular
results on
a single line.
60c57303d Fix name clash of template parameter and field
4a52a3f7a Shorter StorageTag for ArrayHandleZip
4a626b2e9 Shorter storage tag for ArrayHandleView
4c8c28d1f Shorter storage tag for ArrayHandleReverse
bfd21dfae Declare StorageTags with VTKM_ALWAYS_EXPORT
1ec716e5d Shorten storage tag for ArrayHandlePermutation
ca0ad1dc2 Shorten storage tag for ArrayHandleIndex
7bd5802dd Shorter storage tag for ArrayHandleGroupVecVariable
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1937
Also discovered that many C++ compilers have trouble giving warnings
for partial specialization of classes marked as deprecated. Fix
the problem by instead deprecating the items in the class.
870bd1d17 Removed unnecessary increment and decrement from ZFPDecode
f9860b847 Correct warnings found by gcc-9 in vtkm::Particle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1935
These extra operations caused the pointer to go out of bound and
then back in, but some compilers (gcc 9) would detect and warn
that the pointer had gone out of bounds.
c5f9b9b20 Fix to examples to use vtkm::Particle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1932
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 convenience functions `ArrayPortalToIteratorBegin()` and
`ArrayPortalToIteratorEnd()` wouldn't detect specializations of
`ArrayPortalToIterators<PortalType>` since the specializations aren't
visible when the `Begin`/`End` functions are declared.
Since the CUDA iterators rely on a specialization, the convenience
functions would not compile on CUDA.
Now, instead of specializing `ArrayPortalToIterators` to provide custom
iterators for a particular portal, the portal may advertise custom
iterators by defining `IteratorType`, `GetIteratorBegin()`, and
`GetIteratorEnd()`. `ArrayPortalToIterators` will detect such portals
and automatically switch to using the specialized portals.
This eliminates the need for the specializations to be visible to the
convenience functions and allows them to be usable on CUDA.
bf2290c9e Fixed an implicit conversion change warning.
18caed60e Fixed some of the compiler warning from CDash.
d7d7cdd5b Merges with upstream reformated version.
d6cbd8301 Merge with unformated previous state of the remote branch.
9a6dec8bc Refactored control side function call from a VTKM_EXEC function.
ca5f79056 Swapped x and y dimensions when reading in contour trees from text files.
da83076d7 Merge branch 'master' into peter-changes
01c49f139 Wrote some documentation for the CT Height Branch Decomposition code.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1899
