Support sorting arrays of bitsets

[degawa]

To support sorting arrays of bitsets, type(bitset_64) and type(bitset_large) are added as arguments of procedures in the stdlib_sorting.

The tasks done are summarized as follows:

• Added bitset types to ALT_NAME in the stdlib_sorting modules.
• Added some tests.
• Updated and fixed API-doc and spec related to the stdlib_sorting module.
  • The overview of sorting was not updated to respect the original intent.

    The Fortran Standard Library therefore provides a module, stdlib_sorting, with procedures to sort arrays of simple intrinsic numeric types

  • Performance benchmarks were not updated because the same computer environment was not available.
• Added an example.
• Changed the argument's intent from out to inout in the procedure for overloading the assignment operator for bitset types.
  • This change avoids assignment failure when an assignment such as array(1)=array(1) is performed.
  • Executed examples that were using the bitset types and confirmed those finished successfully.

closes #720

[jvdp1]

Thank you. On overall LGTM. Here are a few comments.

[jvdp1]

Why is this needed?
And if it is needed, I guess the corresponding interfaces should be also modified for bitset_64.
It might be wise to open another PR with these changes only related to stdlib_bitset

[jvdp1]

Should the corresponding specs be modified too?

[degawa]

This change and the change you mentioned below have been done to fix unexpected behavior when assigning the bitset_large type.

Without this fix, the tests for sorting bitset_large in the following environment will fail:

• msys2-build (MSYS, x86_64) in ci_windows.yml
• msys2-build (MINGW32, i686) in ci_windows.yml
• msys2-build (MINGW32, i686) in ci_windows.yml
• Build (macos-latest, 11, cmake) in CI.yml
• Build (macos-latest, 12, cmake) in CI.yml

As you said, opening a new issue for further discussion is better.

---

I share the reason for those modification.

The component blocks of set1 with the intent(out) attribute is not allocated at the beginning of the assignment procedure. Therefore, when size( set2 % blocks, kind=bits_kind ) is executed, an error occurs that blocks have not been allocated. To avoid this error, I modified the intent attribute from intent(out) to intent(inout).

Although I could not find a direct description of this situation in the Fortran Standard, the following statements are relevant:

The INTENT attribute for an allocatable dummy argument applies to both the allocation status and the
definition status. An actual argument that corresponds to an INTENT (OUT) allocatable dummy argument
is deallocated on procedure invocation (9.7.3.2).

When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated. If an error condition occurs during deallocation, it is processor dependent whether an allocated allocatable subobject is deallocated.

The INTENT (OUT) attribute for a nonpointer dummy argument specifies that the dummy argument becomes undefined on invocation of the procedure, except for any subcomponents that are default-initialized (7.5.4.6).

An error still occurred in the assignment procedure after the modification.
allocate( set1 % blocks( size( set2 % blocks, kind=bits_kind ) ) ) gives the error "set1%blocks is already allocated" when the same variable of the bitset_large type was specified on both sides of the assignment operator. This sometimes happens when the array indices for the bitset array to be sorted are the same.
Since set1 and set2 are the same when the same array element is now specified on both sides of the assignment operator, it is natural that this error occurs.
Therefore, the automatic allocation functionality is used instead of explicit allocation.

Similar modifications are not required for type(bitset_64). This is because type(bitset_64) uses an integer corresponding integer(int64) for storing bitset and thus uses a built-in assignment operation.

[jvdp1]

Ok. Thank you for the explanation. A new PR with a test replicating this issue would be useful.
Otherwise, this PR looks good to me.

[degawa]

I followed your comment and opened another issue #726 with replication instructions because discussing it in more detail would be better.

[degawa]

I removed the user-defined assignment operator for the bitset_large type. Then I included the test @jvdp1 added in the pull request #727 and confirmed that all the tests passed.
These commits solve the issue of the self-assignment for the bitset_large type.

[jvdp1]

I removed the user-defined assignment operator for the bitset_large type. Then I included the test @jvdp1 added in the pull request #727 and confirmed that all the tests passed. These commits solve the issue of the self-assignment for the bitset_large type.

Nice that it solves the issue.
To keep "one idea, one PR", this change should be merged in #727 first.

[degawa]

Nice that it solves the issue.
To keep "one idea, one PR", this change should be merged in #727 first.

I understand the review policy, but I have already merged the changes made in #727. How should I handle those?
Should I ask to remove the assign_large procedure in #727 for solving the self-assignment problem?
Many thanks for your advice.

[jvdp1]

I understand the review policy, but I have already merged the changes made in #727. How should I handle those? Should I ask to remove the assign_large procedure in #727 for solving the self-assignment problem? Many thanks for your advice.

Sorry for the confusion. #727 should be merged first, with the remove assign_large procedure (I just included it in the PR. Could you review it, please?). Then you can rebase your branch against the master branch.

[jvdp1]

thank you @degawa the PR #727 has been merged. I will now merge your PR, which became much simpler and with a single aim.