[flang] Add a semantics test for co_min

[rouson]

Summary

This patch checks for valid and invalid forms of calls to the collective subroutine co_min.

[craig.rasmussen]

I'm guessing that this won't pass "git clang-format" (although I don't know if test files are checked. I'll check and let you know offline.

[rouson]

I couldn’t get "git clang-format" to work on my system after installing it with homebrew. Any advice on how using clang-format is welcome.

[PeteSteinfeld]

In D113077#3106924, @rouson wrote:

I couldn’t get "git clang-format" to work on my system after installing it with homebrew. Any advice on how using clang-format is welcome.

I just build clang. One of the executables that gets built is clang-format. I don't use git clang-format. Note that the official version of clang-format is from release 12.

[ktras]

Does git clang-format make any changes to fortran code? Or just c/c++ code?

[PeteSteinfeld]

In D113077#3107007, @ktras wrote:

Does git clang-format make any changes to fortran code? Or just c/c++ code?

It's specific to C/C++. But I usually run it on both the source code and on any tests written in C/C++ (like some of the runtime tests).

[ktras]

In D113077#3107039, @PeteSteinfeld wrote:

In D113077#3107007, @ktras wrote:

Does git clang-format make any changes to fortran code? Or just c/c++ code?

It's specific to C/C++. But I usually run it on both the source code and on any tests written in C/C++ (like some of the runtime tests).

I see, that makes sense. Since Damian's test is in Fortran, the tool won't make any changes then. Does that mean that the style and formatting of code in Fortran tests in llvm-project does not have to match any particular style or formatting?

[PeteSteinfeld]

In D113077#3107084, @ktras wrote:

In D113077#3107039, @PeteSteinfeld wrote:

In D113077#3107007, @ktras wrote:

Does git clang-format make any changes to fortran code? Or just c/c++ code?

It's specific to C/C++. But I usually run it on both the source code and on any tests written in C/C++ (like some of the runtime tests).

I see, that makes sense. Since Damian's test is in Fortran, the tool won't make any changes then. Does that mean that the style and formatting of code in Fortran tests in llvm-project does not have to match any particular style or formatting?

I personally would much prefer that it matches existing tests. But, as far as I know, there are no automated tools that will flag Fortran formatting inconsistencies.

[klausler]

In D113077#3107091, @PeteSteinfeld wrote:

I personally would much prefer that it matches existing tests. But, as far as I know, there are no automated tools that will flag Fortran formatting inconsistencies.

I completely disagree. The more variations of style that the tests can present to parsing and semantics, the more test coverage we get.

[rouson]

1. Add co_min test to expectedly failed list.
2. Replaced non-ASCII characters.
3. Correct expected error message.
4. Update run directive to use test_errors.py.

[ktras]

LGTM

[rouson]

1. Expand the coverage of argument types to include characters.
2. Vary the types of argument 'a' more throughout the test.
3. Group like calls into blocks with a leading comment describing the block.

[rouson]

Update co_min test to be uniform with co_max test:

1. Expand types tested for argument 'a'.
2. Vary the types tested more throughout the test.
3. Replace several "to be determined" error messages.
4. Fix typo: remove extraneous comma.
5. Clarify the "To Do" comment.

[ktras]

Latest diff improves the breadth of the test. LGTM.

flang/test/Semantics/collectives02.f90

+! RUN: %S/test_errors.sh %s %t %flang_fc1
+! REQUIRES: shell
+! Check for semantic errors in co_min() function calls
+
+module test_co_min
+  implicit none
+
+contains
+
+  subroutine test
+  
+    integer i, status
+    real vector(1)
+    real array(1,1,1, 1,1,1, 1,1,1, 1,1,1, 1,1,1)
+    character(len=1) string, message
+  
+    ! correct calls, should produce no errors
+    call co_min(i)
+    call co_min(i,   1)
+    call co_min(i,   1,              status)
+    call co_min(i,   1,              stat=status)
+    call co_min(i,   1,                           errmsg=message)
+    call co_min(i,   1,              stat=status, errmsg=message)
+    call co_min(i,   result_image=1, stat=status, errmsg=message)
+    call co_min(a=i, result_image=1, stat=status, errmsg=message)
+
+    call co_min(array,  result_image=1, stat=status, errmsg=message)
+    call co_min(vector, result_image=1, stat=status, errmsg=message)
+    call co_min(string, result_image=1, stat=status, errmsg=message)
+  
+    ! the error is seen as an incorrect type for the stat= argument
+    !ERROR: Actual argument for ‘stat=’ has bad type ‘CHARACTER(KIND=1,LEN=1_8)’
+    call co_min(i, 1, message)
+
+    ! the error is seen as too many arguments to the co_min() call
+    !ERROR: too many actual arguments for collective subroutines 'co_min'
+    call co_min(i,   result_image=1, stat=status, errmsg=message, 3.4)
+  
+    ! keyword argument with incorrect type
+    !ERROR: unknown keyword argument to intrinsic 'co_min'
+    call co_min(fake=3.4)
+  
+  end subroutine
+
+end module test_co_min