[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: %python %S/test_errors.py %s %flang_fc1
+! XFAIL: *
+! This test checks for semantic errors in co_min() subroutine calls based on
+! the co_min interface defined in section 16.9.48 of the Fortran 2018 standard.
+! To Do: add co_min to the evaluation stage
+
+program main
+  implicit none
+
+  integer i, status
+  real vector(1)
+  real coindexed[*]
+  real array(1,1,1, 1,1,1, 1,1,1, 1,1,1, 1,1,1)
+  character(len=1) string, message
+
+  complex complex_type
+  logical logical_type
+  type derived_t
+  end type
+  type(derived_t) derived_type
+
+  ! 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)
+
+  ! incorrect type for the first argument
+  !ERROR: Actual argument for 'a=' has bad type 'LOGICAL(4)'
+  call co_min(logical_type, 1)
+
+  ! incorrect type for the first argument
+  !ERROR: Actual argument for 'a=' has bad type 'COMPLEX(4)'
+  call co_min(complex_type, 1)
+
+  ! incorrect type for the first argument
+  !ERROR: Actual argument for 'a=' has bad type 'derived_t'
+  call co_min(derived_type, 1)
+
+  ! 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)
+
+  ! too many arguments to the co_min() call
+  !ERROR: too many actual arguments for intrinsic '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)
+
+  ! the standard prohibits coindexed arguments in co_min
+  !ERROR: (message to be determined)
+  call co_min(coindexed[1])
+
+end program