Although technically supported, this version of the visual studio likes
to put the warnings where templates are defined (rather than
instantiated). That makes it impossible to suppress a warning when, for
example, when a deprecated class is legitmately used in an std template
to implement other deprecated functionality.
To prevent this, disable deprecations on MSVC compilers before 2019. I
doubt any developers are using this compiler anywhere but the dashboard,
and the warnings should legitimately appear elsewhere.
There appears to be a bug in GCC where if you mixed C++ attributes like
`[[deprecated]]` with GNU attributes like `__attribute__(())`, you will
get a compile error. This can be a problem when using attributes to both
set the export (i.e. visibility) of an item and deprecating the same
item.
This problem has been encountered before. Commit
34b0bba84207a89e8fddfe62e7a1ff30b1b53a18 fixed the problem by using
`[[gnu::visibility()]]` instead of `__attribute__()` in the export
macros. This works fine for export macros defined by VTK-m headers such
as `VTKM_ALWAYS_EXPORT`. Unfortunately, we have little control over the
export macros that CMake automatically creates. Rather than rewrite the
CMake export code, we go the other way and use `__attribute__()` for all
exports _and_ the depreciated attribute.
The nvcc compiler under visual studio seems to give the error `attribute
does not apply to any entity` when you try to use the `[[deprecated]]`
attribute. So disable for this compiler configuration.
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.
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.
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.
