GitLab

It make senses since it allows for providing different iteration orders
for new array types.

No need to use allocators, instead we simply let the array implement
AllocateTuples/ReallocateTuples.

Converting some pure virtual methods to non-pure viz.
RemoveLastTuple/RemoveFirstTuple now simply call RemoveTuple with
appropriate index.

The default NULL value for UpdateExtent(const int extent[6]) was a typo.

Changed some parameters to be by reference,
instead of by value, including some public API.

This removes the Kaapi and Simple backends, as they are no longer supported.
OpenMP and TBB are the supported backends.

Defines a macro "VTK_SMP_<Backend-Name>" and macro VTK_SMP_BACKEND which
expands to a string containing the back-end name.

When C++ args with default parameter values are wrapped, those same
parameters should have the same default values in Python.

The call to ResizeTableForSpecialColors resizes the Table array,
invalidating the pointers 'table' and 'tptr', leading to crashes:

https://open.cdash.org/testDetails.php?test=414805862&build=4211477

The way algorithms were updated (made to execute) with
request meta-data (such as update extent) was very error
prone and counter-intuitive. Added new methods to make
updating with meta-data easier. I also deprecated a number
of methods to set request meta-data. This will encourage
developers to migrate to the new API which is less error-
prone.

Find/replace of:

with C++ counterparts.  Changed only vtk*.cxx files.
Didn’t touch .h or .c or any 3rd party.

If the number of colors is zero, then we force the out-of-range colors
to be used because there are no lookup table colors to use instead.

Table values may be set by accessing the WritePointer() directly.
When this pointer is accessed, there is no mechanism to update
the special values in the table automatically before the lookup
table is used. vtkLookupTable::BuildSpecialColors() must be
invoked explicitly in this case.

In vtkLookupTableMapData(), the special colors were set in the lookup
table prior to doing the mapping. This can lead to a race condition if
multiple threads call this function at the same time. Normally, this
shouldn't be a problem, because if the vtkLookupTable used to fill in
the table values is the same, each thread will write the same values
to each entry in the table. Some verification tools, however, will
note that more than one thread is writing to the same memory location
at a time.

Avoid this by setting the special colors when the lookup table is built
or when custom table values are set.

This allows removing other clamp macros in various files,
which caused clang-tidy misc-macro-parentheses warnings,
due to their lacks of parens in the macro implementations.
It was also an unneeded duplication of code.

Added asserts to some of the various clamping methods
to confirm that min <= max.  Some of them had these asserts
already, now all do.

Also searched and replaced some identical clamp functions
in various places.

Added unit test.

This tool warns where macros should be using parens.
Fixed many issues it pointed out by either:
 - adding parens (which it can do automatically)
 - removed unused (or rarely used) macros
 - replacing macros with functions, notably vtkMath stuff

Cleaned up and modernized vtkSortDataArray. Using std::sort and
threaded the sort operation (with vtkSMPTools). Removed static
variable that made it non-thread-safe. Added the ability to sort
in ascending as well as descending order. Expanded and improved
the test TestSortDataArray.

Note that the code handles vtkStdString and vtkVariant.

Note also: various types of arrays, including the vtkIdList, needed
to be expanded so the SetArray() (or equivalent operation to
specify the under-the-hood array to use). This is so the sort
can swap out the data once the data is shuffled.

when testing for ogl support capture warning and error
output messages

This fix is in reference to issue #0002698. During the execution of method
vtkMath::SolveLeastSquares, if a matrix inversion failed then the method
would exit without dealocating locally allocated memory. This Fix corrects
this behavior.

Reviewed-by and Acked-by copied by hand due to a rebase.

Reviewed-by: @utkarsh.ayachit
Acked-by: @ben.boeckel
Acked-by: @robertmaynard

Move `VTK_TYPE_*` and `VTK_SIZEOF_*` macros from `vtkConfigure.h.in`
over to `vtkType.h` and define them using KWIML instead of configuring
the values from CMake.

target_compile_features doesn't support the compilers and older versions
of compilers that VTK needs to support.

Revise vtkTypedArray.h.in to select the implementation type with
preprocessor conditions.  This reduces the amount of type size and
signedness information that we need at CMake time.

VTK no longer supports any compilers that do not provide this type.
Therefore all code conditional on VTK_TYPE_USE_LONG_LONG can be made
unconditional.  Leave the macro defined to tell dependent projects that
APIs using the type are available in case they still support versions of
VTK that make it conditional.

VTK no longer supports any compilers that have `__int64` but not a
`long` or `long long` that is 64-bit.  Therefore all code that is
conditional on VTK_TYPE_USE___INT64 is never used and can be dropped.

This commit adds the VTK_USE_CXX11_FEATURES variable for newer versions
of CMake (>=3.3).  This turns on target_compile_features for override,
final and nullptr on vtkCommonCore and adds a detection header to create
macros for these for use throughout VTK.  VTK_OVERRIDE, VTK_NULLPTR and
VTK_FINAL can now be used.  This new header is included in
vtkConfigure.h so these should be available everywhere.