Haven't changed AlgorithmProxy as that class will be deleted in the next PR

and fix a unit test for not having a list limit

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Runs clang-tidy pass by ref across the codebase to fix-up various
warnings we are seeing in cppcheck

Hand-fixes some cppcheck warnings, this was work prior to fixing the
cppcheck target.

Also updated class_maker.py

Apply change to insert export macros into class definition using cmake GenerateExportHeader
feature to 3 more projects: API, Crystal and CurveFitting
Have replaced DllExport with the cmake macro except in these places:

a) class templates - the definitions of class template member functions need to be in the
same unit as the declaration so dllimport gives a compilation error in the client code
(C2491 in VS) eg SingleValueParameter, SingleValueParameterParser
b) headers which are in a project but aren't included by any .cpp units in the project
eg IBackgroundFunction.h, ICatalogInfoService.h. In these cases I've removed the DLLExport
attribute completely

For the API target there were a couple of special cases\extras:

API has some conditional use of the extern keyword to control instantiation of template
classes. This has been inserted into the automatically created dllconfig.h using a cmake
switch that allows some custom content to be appended to the end of the file. Few of the
targets require this so I've added a boolean parameter to the wrapper function to handle
this GENERATE_MANTID_EXPORT_HEADER

I also had to add explicit include directories to PythonInterfaceCore where it imports an
API target header (in the unit ExtractWorkspace.h) without having API as a dependency

Replaces the deprecated scheduler_init with global_control. This should
future proof us, and completely avoids all the threading issues we were
seeing previously.

The TBB_PREVIEW_GLOBAL_CONTROL macro is required until TBB 2019U4, or 11
internally. So for simplicity we will make platforms using an older
version of TBB (RHEL7 and Ubuntu at writing) switch to scheduler init

Fixes the following assertion thrown by TBB:

	Attempt to terminate non-local scheduler instance

This took a significant amount of time to track down due to a number of
factors. If your looking for a quick fix; set your
tbb::task_scheduler_init to use thread local storage.

This is caused by using Python multi-processing (in our case for the
system tests). The process will spawn correctly (Windows), however
Python will helpfully create seperate thread(s). I assume to observe. In
this case the task_scheduler_init handle would then belong to one of
these threads, as the act of importing our Python module would init the
framework and TBB implicitly.

When the tests run and TBBs scheduling is required it will "sign_on" in
tbb's governor.cpp to handle scheduling. This works because the
scheduler_init handle
is process wide. However internally they then use thread local storage
(TLS) for tracking the scheduler.

As the main process goes to destruct it assumes that we must have
a scheduler instance, since at process level we have done the init.

But we cannot see any schedulers since they belong to a different
thread. We have been getting away with this as the TLS returns NULL
which effectively nops the destruction. But the assert correctly points
out were getting this wrong.

Marking each handle to the scheduler as thread local effectively ties
the destruction of the thread to its init status. For most threads this
effectively means we create a unique_ptr which isn't used. But for our
main threads and weird edge case worker threads it keeps the thread
state consistent.

We've used a unique_ptr since we have an API which allows us to change
the number of threads TBB can spin up. However, anyone else facing this
issue would probably be fine with a thread local object allocated on the
stack.

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

Signed-off-by: Steven Hahn <hahnse@ornl.gov>

when creating a new algorithm
re #28093

re #28093

This change fixes a problem in Workbench when setting columns to YErr
Previously this only worked if all Y columns had an associated YErr column. If that
wasn't the case then the associations between Y and YErr cols got mixed up
I have saved the link between the YErr and Y column into the C++ table workspace
object via changes to ITableWorkspace and the Column class
I've also modified the model\view\presenter for the table workspace to set and get
the link via the ITableWorkspace interface
The code in marked_columns.py has been modified to remove the _add function because
the logic required for adding x, y and yerr was sufficiently different that trying
to push them through a common _add function was obscuring the code
Finally I've removed the labelindex from the ErrorColumn object in the python code
because it can be worked out on the fly (and I didn't want to have to save this also
into the C++ table workspace in addition to the linked column index)

As part of the test updates I have removed the test
TableWorkspaceDisplayModelTest.test_initialise_marked_columns_yerr_before_y_doesnt_mark_yerr
because we do require the ability to add a yerr column before the corresponding y column
The model gets refreshed whenever the C++ table workspace is updated (eg when the type of a column
is updated) as part of a replace_workspace call. The model __init__ function builds up the column
set left to right and a user may have set up a Y err column which is to the left of the corresponding
Y column.