[code-reflection] RFR: More systematic binary op tests

[Paul Sandoz]

On Tue, 19 Mar 2024 19:21:41 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> I added a second variant, where we use `@CodeReflection`-annotated methods as a base and transform them for different types. This probably makes the distinction between model and test input clearer. But for now, I'm not 100% happy with either solution.

I feel the same way, preferring second variant because of the distinction. I also like that it is leveraging a transformation, replacing the types. This pushes on an area i don't think we have fully worked out. Not all operations derive their result type from their operands types. In general transforming to replace types is i think challenging but can work well in these cases.

As an experiment it seems worth perusing further even if it is not generally applicable as i think we might learn things on the way. We could lean into the second variant, and you can probably drop `ensureAllBinOpsCovered`.

There might be a way in JUnit to annotate the code reflected method as a test template and then annotate the test class with `@ExtendWith`, such that we extend JUnit to execute the code reflected method as we wish similarly to the dynamic approach, but without needing to reflectively enumerate all the methods under test. 

  https://junit.org/junit5/docs/current/user-guide/#extensions
  https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestTemplateInvocationContextProvider.html

> Btw, I noticed that `FuncOp#resultType()` always `JavaType.VOID`. Is that intended? (At least I was surprised)

Yes, my thinking was that function declaration operations don't return something that can be interacted with directly and cannot be passed around as values. We can however produce a symbol table of function name to function (e.g., for functions that are grouped into a module) and there is an operation to call a function by name (which will have stack effects). Functions are not intended to be part of some block of code and they do not capture values (we refer to the body as isolated). They are intended to model Java methods. Lambda and closure operations can be embedded in code and both can capture, the former returns an instance of a functional interface, and the latter returns an instance of a function type (which has no direct correlation to Java source).

-------------

PR Comment: https://git.openjdk.org/babylon/pull/40#issuecomment-2010811169
PR Comment: https://git.openjdk.org/babylon/pull/40#issuecomment-2021412035