64ff68421 Use TypeToString to demangle symbol in UnknownArrayHandle.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2315
d82fc92a1 Fix for serializable type names that change base C types
88eed2bbe Make sure all C scalar types are in TypeListScalarAll
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2312
MR !2311 fixed an issue where some base C types were not recognized by
`SerializableTypeString`. However, the fix was such that different types
with the same layout had the same string. For example `char` and
`signed char` both were given the string `I8`. That meant that the
serialization/deseralization would work, but the deserialization could
change the type. That could cause problems if two arrays were expected
to have the same type but did not.
This change undoes much of MR !2311 and redoes it so that the types are
correct.
C++ template considers some types different even though they have the
exact same format. For example `int`, `long`, and `long long` all match
different types even though they all represent either signed 32-bit ints
or signed 64-bit ints.
List all these possible types in
`TypeListScalarAll`.
ec4a434dc Include all int types in SerializableTypeString
d9fe6a546 Fix ArrayHandleCast serializable type name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2311
- It explicitly instantiate its concrete templates to
the supported types.
- It disables implicit template instantations for the
the supported types.
- Also fix small typo in Contour impl include guards
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
Previously, `SerializableTypeString` was specialized only for the VTK-m
defined int types (`Int8`, `UInt8`, `Int16`, etc.). You would think this
would cover all the base int types, but in fact C++ defines multiple int
types that have the exact same bit layout. These duplicates will not
match each other when matching template specializations. For example,
`char` is either the same as `signed char` or `unsigned char`, but will
match neither. Likewise, `long` is the same as either `int` or `long
long`, but all these types will match different template
specializations.
Now all integer types are covered.
The specialization for SerializableTypeString for ArrayHandleCast tried
to get the serialization for the base type and the storage tag. This is
wrong since the storage tag itself is not seralizable nor has a type
string. Instead, just record the type name for the sub ArrayHandle
itself.
Previously you had to create a special virtual object to place in the
`Buffer`'s metadata. This added a lot of difficulty that is probably
unnecessary.
Instead, just have `Buffer` hold an arbitrary object and some simple
functions to copy and delete it. There may be issues with type safety
across translation units, but we'll deal with that when/if we run into
it.
ArrayRangeCompute.hxx was removed, but other code may be including it.
The file was replaced. It now just includes its replacement
(ArrayRangeComputeTemplate.h) and forces a deprecation warning.
e3dfa4891 Do not attempt to move non-trivial objects in Variant
8e11b3ecd Remove ArrayPortalCheck
21db210a7 Make separate exec and cont versions of Variant
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2274
The `Variant` class has separate implementations for its move and copy
constructors/assignment operators depending on whether the classes it
holds can be trivially moved. If the objects are trivial, Variant is
trivial as well. However, in the case where the objects are not trivial,
special construction and copying needs to be done.
Previously, the non-trivial `Variant` defined a move constructor that
did a byte copy of the contained object and reset the right hand side
object so that it did not attempt to destroy the object. That usually
works because it guarantees that only one version of the `Variant` will
attempt to destroy the object and its resources should be cleaned up
correctly.
But C++ is a funny language that lets you do weird things. Turns out
there are cases where moving the location of memory for an object
without calling the proper copy method can invalidate the object. For
example, if the object holds a pointer to one of its own members, that
pointer will become invalid. Also, if it points to something that points
back, then the object will need to update those pointers when it is
moved. GCC's version of `std::string` seems to be a type like this.
Solve the problem by simply deleting the move constructors. The copy
constructors and destructor will be called instead to properly manage
the object. A test for these conditions is added to `UnitTestVariant`.
This portal only works on the control environment, which means it cannot
work with the new `ArrayHandle` type. Recent changes to
`ArrayHandleMultiplexer` also do not allow this, so just remove it
rather than try to fix it.
The `Variant` class is templated to hold objects of other types.
Depending on whether those objects of are meant to be used in the
control or execution side, the methods on `Variant` might need to be
declared with (or without) special modifiers. We can sometimes try to
compile the `Variant` methods for both host and device and ask the
device compiler to ignore incompatibilities, but that does not always
work.
To get around that, create two different implementations of `Variant`.
Their API and implementation is exactly the same except one declares its
methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
Instead, always use precompiled versions of range computing. This means
you won't be able to specify the type. Currently, types are limited to
scalars vecs up to size 4.
The main motivation for this change is to allow you to include Field.h
with a non-device compiler. This is an important feature for our
customers.
I plan in the future to implement a mechanism to pull out a component of
most ArrayHandle's as a single array. This would enable us to support a
precompiled version that can compute the range of arbitrarily sized
Vecs.
02f73fce1 Compiler warnings.
f876a2cee Structured ONLY in LS filter.
451720167 Fix testing for both SL and PA
fb72ab097 Add tests for all datasetypes for 3D
699dbae5c compile warning and fix to PA test.
4d6776cd1 Update filter test to use all data types.
c0189982a Messed up the merge.
a7f049ac1 Merge branch 'master' of https://gitlab.kitware.com/vtk/vtk-m into ghost_streamlines
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2293
0b2ddb83b UnitTestBounds custom compile flags expressed via generator expression
1ed5dfca0 vtkm/Math frexp(float) version works now with HIP
ff381bf8b vtkm/Swap works with hip
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2301
