Branch: refs/heads/master
Revision: 7054b5e
Author: bradcray
Log Message:
Merge pull request #16452 from bradcray/arr-to-extern-sans-cptr-plus-local-check
Tighten up passing of Chapel arrays to extern ‘: [] …’ arguments; c_ptrTo for arrays
[reviewed by @e-kayrakli, under duress]
This makes some minor adjustments to the logic we use to pass
Chapel arrays to external arguments that are declared to
have array type (using Chapel array syntax) as well as to c_ptrTo()
as applied to arrays:
-
When a Chapel array is passed to an extern proc’s array argument,
the compiler inserts ause CPtr;
call now that thec_ptr
types
used by such routines are no longer available by default. This is a
follow-on to Engin’s work on issue #16451. The extern docs are
also updated to note this change. -
It moves the logic that converts the array to a C pointer from
CPtr’s ‘c_ptrTo()’ to a new utility routine in ChapelArray.chpl.
The motivation here is to customize the error messages for
this case, distinct from the error messages inc_ptrTo()
and
to slightly simplify the code generated by the compiler. -
It removes
use CPtr;
from tests of passing Chapel arrays
to external array arguments since, from the user’s perspective
there is no dependence on CPtr, and the first item in this list
takes care of adding it. This keeps code from 1.22 working
without changes after #16451. -
It adds stricter checking to the c_ptrTo() routine to check
for obvious cases that would not be handled well (some of
which, the previous docs suggested were handled, but seemed
not to be). -
It adds a number of new tests to check against error cases
that this PR added checks for.
Some future things we might consider here:
-
should we be supporting all DR array views in this code logic, or
only those that are contiguous at execution time? -
Similarly, should distributed arrays be permitted if they happen to
be local to a single locale at execution time? -
should we get away from supporting ‘: []’ as an extern proc’s formal
argument type on the argument that external routines are C code, so
shouldn’t be described using Chapel syntax (historical
counter-argument: but since it’s Chapel code, it’s nice to use
Chapel types sometimes for convenience; e.g., ‘real’ rather than
‘c_double’). -
If we were to stop supporting such formals, would we also stop
supporting c_ptrTo() on arrays? Related: Should c_ptrTo() share
more implementation with the new helper routine? (I didn’t do it
here since c_ptrTo() is publicly documented as having specific
behavior for arrays, though it’s hard for me to believe that it’s
accurate at a glance…).
Modified Files:
A test/extern/bradc/blockToExtern.chpl
A test/extern/bradc/blockToExtern.good
A test/extern/bradc/remoteArrToExtern.chpl
A test/extern/bradc/remoteArrToExtern.good
A test/extern/bradc/remoteArrToExtern.numlocales
A test/extern/bradc/remoteArrToExtern.skipif
A test/types/cptr/c_ptrToBlock.chpl
A test/types/cptr/c_ptrToBlock.good
A test/types/cptr/c_ptrToRemote.chpl
A test/types/cptr/c_ptrToRemote.good
A test/types/cptr/c_ptrToRemote.numlocales
A test/types/cptr/c_ptrToRemote.skipif
A test/types/cptr/c_ptrToSparse.chpl
A test/types/cptr/c_ptrToSparse.good
M compiler/passes/expandExternArrayCalls.cpp
M doc/rst/technotes/extern.rst
M modules/internal/CPtr.chpl
M modules/internal/ChapelArray.chpl
M test/extern/bradc/multidimArrToExtern.chpl
M test/extern/bradc/sparseToExtern.chpl
M test/extern/bradc/sparseToExtern.good
M test/extern/diten/externVoidFnWithArray.chpl
M test/extern/diten/externVoidFnWithArray.good
M test/extern/diten/externVoidFnWithArrayNoUse.chpl
M test/extern/kbrady/extern_array_call.chpl
M test/extern/kbrady/extern_void_array_call.chpl
M test/extern/passArrays/passViewToExtern.chpl
M test/studies/shootout/k-nucleotide/bharshbarg/knucleotide-associative.chpl
M test/studies/shootout/k-nucleotide/bharshbarg/knucleotide-chaining.chpl
M test/users/ibertolacc/void_extern_proc_array.chpl
Compare: https://github.com/chapel-lang/chapel/compare/ed22770e2af7...7054b5e829f7