Chapel: Avoid the need to write 'borrowed' in testing functions' formals

Created on 15 Aug 2019  路  4Comments  路  Source: chapel-lang/chapel

Currently a UnitTest test must include borrowed in the formal's type:

proc myTestProc(test: borrowed Test) ....

whereas it would be simpler to write:

proc myTestProc(test: Test) ....

This is because PRIM_GATHER_TESTS looks for functions that are not generic. proc myTestProc(test: Test) is now generic, so PRIM_GATHER_TESTS would not include it in the set of tests to be executed.

See also:

  • #13720 -- it discusses --no-legacy-nilable-classes
  • #13447 -- it changed most tests under test/library/packages/UnitTest/ to accept borrowed Test
Libraries / Modules Design Feature Request

All 4 comments

Speaking about a function that the user wants to be considered as a "test" by the testing framework:

I propose to require that the function argument's type be given directly as in arg: Test.

Otherwise program behavior may differ between normal execution and execution under the testing framework. This difference will occur only in corner cases afaik.

Indeed, suppose we want the following function to be considered as a "test" :

proc typeFun() type return Test;  // same concern if it returns 'borrowed Test'
proc myProc(arg: typeFun()) ......

At the point when PRIM_GATHER_TESTS is called, which is at the start of main(), we need to resolve typeFun to see whether it returns a Test. Likewise we need to resolve the types of all formals of potential test functions early on during program compilation.

This means that some formals' types will be resolved "out of order", i.e. in a different order than when the program is compiled without PRIM_GATHER_TESTS. Different behavior may result.

An alternative is to forego resolving typeFun() in such cases. This means that myProc above will not be counted as a "test". Which essentially is my proposal.

@ben-albrecht @mppf what do you think?

[Added:] The current implementation does "out of order" resolution described above.

I propose to require that the function argument's type be given directly as in arg: Test.

I think that would be reasonable, but we'll want to support arg: borrowed Test for a while for compatability.

The reason I would do this is that it is really not obvious to a reader that proc myProc(arg: typeFun()) should behave as a test. Part of the "find tests with arguments matching" strategy is the assumption that these tests will be identifiable to users.

This means that some formals' types will be resolved "out of order", i.e. in a different order than when the program is compiled without PRIM_GATHER_TESTS. Different behavior may result.

I kinda view this as a problem for the person who wrote the file, rather than us as compiler developers or authors of the UnitTest framework. If a file behaves differently at compilation time, doesn't that mean it should be better written? There may very well be reasonable cases I'm not thinking of, though.

I think I buy the argument that Test should be explicitly written into the type signature of the argument.

Also, please tag @krishnadey30 :)

PRIM_GATHER_TESTS can handle the case when we remove borrowed as it expects the argument type to be passed using which it finds the functions that accept the passed argument type( In our case borrowed Test ).

var testObjGather: owned Test = new Test();
// gather all the tests
param n = __primitive("gather tests", testObjGather.borrow());

If we change the argument type we just need to change the argument type to be checked.

var testObjGather: Test = new Test();
// gather all the tests
param n = __primitive("gather tests", testObjGather);

Indeed, suppose we want the following function to be considered as a "test" :

proc typeFun() type return Test;  // same concern if it returns 'borrowed Test'
proc myProc(arg: typeFun()) ......

For this, I agree with @lydia-duncan. UnitTest functions should simply mention the argument type so that the framework can identify it and pass the arguments when the function is ran.

Was this page helpful?
0 / 5 - 0 ratings