Previously, the `VTKM_ALWAYS_EXPORT` and `VTKM_NEVER_EXPORT` macros
used the gnu-specific `__attribute__` keyword. This change instead
uses the C++11 standard method of using `[[ ]]` as attributes.
Specifically, `__attribute(visibility("---"))` is changed to
`[[gnu::visibility("--")]]`.
The main impetus for this change is that `__attribute__` does not
seem to work with `[[deprecated]]` on GCC compilers. (For sure on
GCC 6. I didn't check all compiler versions.) This change was
recommended from
https://stackoverflow.com/questions/40886628/deprecated-attribute-visibility-default-in-gcc-6-2
This creates a minor backward incompatibility. We have always meant
for these macros to be used before the return type when used with
a function. However, GCC accepted placing `__attribute__` after
the return type. The C++11 `[[ ]]` cannot be placed there, so
some macros might have to be moved. Still, this was a broken
use that happened to work.
A new header named TypeList.h and the type lists have been redefined in
this new file. All the types have been renamed from `TypeListTag*` to
`TypeList*`. TypeListTag.h has been gutted to provide deprecated
versions of the old type list names.
There were also some other type lists that were changed from using the
old `ListTagBase` to the new `List`.
The newer List operations should still work on the old ListTags, so make
those changes first to ensure that everything still works as expected if
given an old ListTag.
Next step is to deprecate ListTagBase itself and move all the lists to
the new types.
`vtkm::List` is meant to replace `vtkm::ListTag`. Rather than
subclassing a base class with a variadic template, all lists expose the
list of types.
`vtkm::ListTag` was originally created before we required C++11 so
supporting variadic templates was problematic. To hide the issue we had,
we made list tags subclass other lists rather than be the list
themselves. It makes for nicer types in the compiler, but hides
important details about what is actually in the type. It also creates
lots of unnecessary new types.
The new `vtkm::List` is in some ways simpler. All lists have to be a
`vtkm::List`. Subclasses are not supported (or rather, they will not
work as expected). All manipulations (such as `vtkm::ListAppend`)
resolve directly back to a `vtkm::List`. Although the types reported by
the compiler will be longer, they will be more specific to the types
being used. Also, the new implimentation should ultimately use fewer
types.
Previously we relied on CMake's compiler detection module to build the
macros for using the deprecated attribute. However, CMake created macros
for pre-C++14 versions of the feature, which do not work in all cases.
Also, we have the need to be able to suppress deprecation warnings when
we are implementing a deprecated thing. Since we have to query compilers
ourself, we might as well figure out if the deprecated attribute we want
is supported.
Worst case is that we won't support deprecation warnings everywhere we
could. That will not create incorrect code and we can always add that
later.
Previously, Configure.h.in used a pragma to disable warning 4996 is all
VTK-m code and anything that used it. The reason for this was that the
warning was given for any use of std algorithms such as fill_n that the
Visual Studio team deemed unsafe. Although we could fix it in our code,
it was impossible to work around warnings in other headers as the actual
warning comes from a system header file (xutility) that we have very
little control over. At the time we disabled this warning, we were
getting the warning from a bost header file, and the warning was never
to be fixed (https://svn.boost.org/trac/boost/ticket/11426).
Unfortunately, disabling warning 4996 also disables all warnings about
deprecated items. We want to support warnings for things deprecated in
VTK-m itself, so turning off this warning means we cannot correctly
support VTK-m deprecation.
Fortunately, a lot has changed since then. We no longer boost at all, so
the issue there is no longer our problem. We can thus re-enable the
warning (by removing the pragma). We've managed to avoid using these
"unsafe" functions anyway, so we should be able to cleanly build with
this warning on.
The `VTKM_DEPRECATED` macro allows us to remove (and usually replace)
features from VTK-m in minor releases while still following the conventions
of semantic versioning. The idea is that when we want to remove or replace
a feature, we first mark the old feature as deprecated. The old feature
will continue to work, but compilers that support it will start to issue a
warning that the use is deprecated and should stop being used. The
deprecated features should remain viable until at least the next major
version. At the next major version, deprecated features from the previous
version may be removed.
Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few
C++11 features they do not support. One of these features is
std::is_trivially_copyable. So on these platforms, do not attempt to use
it. Instead, treat nothing as trivially copyable.
The code from the previous commit was causing one of the dashboards,
which is using gcc-7, to produce the following warning:
In file included from ../testing/UnitTestVariant.cxx:11:0:
../Variant.h: In function 'void {anonymous}::TestCopyDestroy()':
../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized]
this->Storage = std::move(rhs.Storage);
^~~~
At best, this warning is not helpful as it does not seem to point to
anything that could be used uninitialized. At worst, it might be a
compiler bug. A Google search finds a few similar bugs although none I
can assert with any confidence of this issue. However, many reported
bugs and issues point to the use of anonymous namespaces. So, I'm going
to attempt to fix the problem by removing anonymous namespaces.
Hopefully it will fix the warning or at least point me to something
concrete that I can fix.
The Variant template can hold any type. If it is holding a type that is
non-copyable, then it has to make sure that appropriate constructors,
copiers, movers, and destructors are called.
Previously, these were called even the Variant was holding a trivially
copyable class because no harm no foul. If you were holding a trivially
copyable class and did a memcpy, that work work, which should make it
possible to copy between host and device, right?
In theory yes, but in practice no. The problem is that Cuda is
outsmarting the code. It is checking that Variant is not trivially-
copyable by C++ semantics and refusing to push it.
So, change Variant to check to see if all its supported classes are
trivially copyable. If they are, then it use the default constructors,
destructors, movers, and copiers so that C++ recognizes it as trivially
copyable.
This is done through a new version of ApplyPolicy. This version takes
a type of the array as its first template argument, which must be
specified.
This requires having a list of potential storage to try. It will use
that to construct an ArrayHandleMultiplexer containing all potential
types. This list of storages comes from the policy. A StorageList
item was added to the policy.
Types are automatically converted. So if you ask for a vtkm::Float64 and
field contains a vtkm::Float32, it will the array wrapped in an
ArrayHandleCast to give the expected type.
I ran into a bug with GCC 4.8 where if you use the alignas keyword
with a number declared with a constexpr, it gives an error about
the expression not being a constant expression (even though it
is). A workaround to the issue is to wrap the alianas in a class
templated by the size you want to align with. GCC does not
complain when you use a constexpr with a template parameter, and
it is happy to use that template parameter in the alignas
expression.
Workaround found here:
https://stackoverflow.com/questions/29879609/g-complains-constexpr-function-is-not-a-constant-expression
The `From` and `To` nomenclature for topology mapping has been confusing for
both users and developers, especially at lower levels where the intention of
mapping attributes from one element to another is easily conflated with the
concept of mapping indices (which maps in the exact opposite direction).
These identifiers have been renamed to `VisitTopology` and `IncidentTopology`
to clarify the direction of the mapping. The order in which these template
parameters are specified for `WorkletMapTopology` have also been reversed,
since eventually there may be more than one `IncidentTopology`, and having
`IncidentTopology` at the end will allow us to replace it with a variadic
template parameter pack in the future.
Other implementation details supporting these worklets, include `Fetch` tags,
`Connectivity` classes, and methods on the various `CellSet` classes (such as
`PrepareForInput` have also reversed their template arguments. These will need
to be cautiously updated.
The convenience implementations of `WorkletMapTopology` have been renamed for
clarity as follows:
```
WorkletMapPointToCell --> WorkletVisitCellsWithPoints
WorkletMapCellToPoint --> WorkletVisitPointsWithCells
```
The `ControlSignature` tags have been renamed as follows:
```
FieldInTo --> FieldInVisit
FieldInFrom --> FieldInMap
FromCount --> IncidentElementCount
FromIndices --> IncidentElementIndices
```
Although it is mostly C++11 compliant, GCC 4.8 does not have an
implementation of std::aligned_union. We cannot drop this compiler, so
provide our own implementation in that case.
Previously, templates were used in the implementation of CastAndCall to
find the type and call the underlying function. The templates checked
one type at a time.
However, compilers were not always great at optimizing a 15-call deep
stack with an if statement at each one. Instead, use a case statement in
a single function block. This requires providing separate code for each
number of types. Currently, up to 20 are created (with pyexpander). If
there are more than that, then the template recurses.
Currently, ListTags are implemented by having a subtype name list set to
a brigand::list. However, there is always a chance this will change. To
make things more explicit, create a vtkm::internal::ListTagToBrigandList
to make it clear what the resulting type should be (and provide some
potential future-proofing).
Also add a convenient vtkm::ListTagApply that allows you to easily
instantiate a template with the list of types in a ListTag.
vtkm::internal::Variant is a simplified version of C++17's std::variant
or boost's variant. It is a template that takes a list of types. The
Variant may be set to any one of those types. A CastAndCall allows you
to call a functor with the appropriately cast type.
how did any of this work?
match other CellSet file layouts.
???
compile in CUDA.
unit tests.
also only serial.
make error message accurate
Well, this compiles and works now.
Did it ever?
use CellShapeTagGeneric
UnitTest matches previous changes.
whoops
Fix linking problems.
Need the same interface
as other ThreadIndices.
add filter test
okay, let's try duplicating CellSetStructure.
okay
inching...
change to wedge in CellSetListTag
Means changing these to support it.
switch back to wedge from generic
compiles and runs
remove ExtrudedType
need vtkm_worklet
vtkm_worklet needs to be included
fix segment count for wedge specialization
need to actually save the index
for the other constructor.
specialize on Explicit
clean up warning
angled brackets not quotes.
formatting
All C++11 compilers support _Pragma to insert pragmas inline into code
and within macros. All compilers, that is, except for visual studio
because Microsoft has to be contrarian and make life miserable for all
programmers. Instead, you have to use __pragma with visual studio.
It is very easy to cause ODR violations with DeviceAdapterTagCuda.
If you include that header from a C++ file and a CUDA file inside
the same program we an ODR violation. The reasons is that the C++
versions will say the tag is invalid, and the CUDA will say the
tag is valid.
The solution to this is that any compilation unit that includes
DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled
must be invoked by the cuda compiler.
We previously had to mark the make_FunctionInterface function as
host/device as it could be used in either place. The ramifications
of this is that each time we launched a worklet any input parameter
had to either suppress cuda exceptions, or had to rely on the
DispatcherBase to suppress the warnings.
By making make_FunctionInterface only host callable ( as it is ),
we can remove all of our unneccesary suppression logic and better
expose real issues with code that is marked host/device but can't
be due to calling things such as std::abort
This adds an ExecutionSignature tag named Device that passes the
DeviceAdapterTag as an argument to the worklet's operator(). This allows
worklets to specialize their code based on the device.
Mask objects allow you to specify which output values should be
generated when a worklet is run. That is, the Mask allows you to skip
the invocation of a worklet for any number of outputs.
