This patch aims to add initial support for multiple address spaced destructors.
Currently this parses fine and the destructors are correctly added to the class,
but there is no logic to choose the correct destructor for a variable in a specific address space.
Currently it always picks the first destructor defined in the source code, regardless of the
address space of the variable.
This is not aiming to be a complete implementation, as destructors are used in a very large
number of locations, and so doing all of it in one patch would be very difficult to review and code.
The goals for this patch is thus to add basic support for destructors, and to build a framework for
additional work to be done on this front.
Since this feature won't be completed in this patch, I have attempted to ensure that no C++
functionality is changed, to ensure that the changes will only affect C++ for OpenCL.
This also has the effect that whenever destructors aren't correctly implemented it will fallback
to default behaviour, which is exactly the same currently happens.
In summary destructors in C++ for OpenCL are currently unusable for multiple destructors. With
this patch the feature will be usable in the most common situation, and every bug that currently
exists that isn't covered by the changes I have made here will continue to be bugs. The hope is that
this patch therefore is almost entirely a positive, since while it doesn't fix every bug, it will make the
feature actually work, and will create a base to fix the other bugs as they are discovered.
This is why it's mostly implemented through default parameters, as that will allow this change to
remain as small as it is, while also allowing further fixes to come along later.
The feature is also C++ for OpenCL specific to let the fast path remain when not utilizing the
address spaces, as this new implementation will be slower than the bitfields that C++ currently
uses, but I hope this can also be optimized in the future if it turns out to be very slow.
According to the current OpenCL strategy, we only declare implicit members in default address space (i.e. __generic). It might be that we can declare them for all concrete address spaces but we are not there yet to start adding this feature. So it would make sense, for now, to simplify this logic and only add implicit dtors in the generic address space.
This implies that objects in concrete address spaces would still be able to use such implicit dtors but the compiler would add an implicit conversion to __generic for the implicit object parameter.