Support void* (Pointer[None]) parameters in bare lambdas and functions

[stefandd]

Unlike conventional FFI functions, bare lambdas @{(...)} do so far not support Pointer[None] parameters, Pony's equivalent of void*, despite the fact that like the former these lambdas are strictly intended for use with FFI calls and callbacks.
Therefore, code like this failed to compile:

use @wglGetProcAddress[@{()}](name: Pointer[U8] tag)

class GlExt
    let glBufferData: @{(GLenum, GLsizeiptr, Pointer[None] tag, GLenum)}

    new create() =>
        glBufferData = @wglGetProcAddress[@{(GLenum, GLsizeiptr, Pointer[None] tag, GLenum)}]("glBindBuffer".cstring())

...

let maxParticles: ISize = 1000
var particles: Array[F32] = [] // holds Vector3f {float, float, float} particles
//fill particle array
for i in Range[ISize](0, maxParticles) do
    particles.push(sr.frand()) // x
    particles.push(sr.frand()) // y
    particles.push(sr.frand()) // z
end
...

glExt.glBufferData(GLArrayBuffer(), maxParticles * ISize(12), particles.cpointer(), GLStaticDraw()) // <- type error

This commit adds to the bare lambdas and functions the same lenience that conventional FFI functions enjoy: it allows the declaration of Pointer[None] parameters that can accept any of the Pony Pointer[A] types.

[ponylang-main]

Hi @stefandd,

The changelog - fixed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4152.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

[SeanTAllen]

Please change the test to a ponyc-run test. We only do error messages tests now that aren't ponyc-run.

Let me know if you need any help getting oriented with the ponyc-run tests.

[ergl]

Like Sean mentioned, can you add the test to the runner? It would also make sense to test that partial application also works with this change, like so:

use @printf[I32](fmt: Pointer[None] tag, ...)

actor Main
  new create(env: Env) =>
    let cb = this~print()
    cb("Hello, world!\n".cstring())

  fun @print(fmt: Pointer[None]) =>
    @printf(fmt)

[stefandd]

Like Sean mentioned, can you add the test to the runner? It would also make sense to test that partial application also works with this change, like so:

use @printf[I32](fmt: Pointer[None] tag, ...)

actor Main
  new create(env: Env) =>
    let cb = this~print()
    cb("Hello, world!\n".cstring())

  fun @print(fmt: Pointer[None]) =>
    @printf(fmt)

Thanks for the test. It does run and print hello world. I am not familiar enough with the test suite to know if the actual output needs to be captured here or if I should simply add an exit code that matches the .txt file. Also, I struggled a bit to understand

We only do error messages tests now that aren't ponyc-run.

The compile test I had proposed was not an error message test, was it? Should I simply add an exit code test for that one too, i.e., move both tests to the libponyc-run suite?

[ergl]

@stefandd No need to capture the output. Take a look at how I did the runner test for my other PR here: https://github.com/ponylang/ponyc/tree/4f64cc5a87ae3e9641e1596d7dddb4f15d737395/test/libponyc-run/ffi-return-arg-reachable

The ideal test would show that you're able to any pointer to C using bare lambdas, and that you get something back that makes sense.

Edit:

The compile test I had proposed was not an error message test, was it? Should I simply add an exit code test for that one too, i.e., move both tests to the libponyc-run suite?

So, for runner tests, we're interested in that the code compiles, and that it does what is supposed to. That's why I mentioned the bit about verifying that the C code works as expected.

[stefandd]

@ergl I combined the test you suggested for the bare functions with one for bare lambdas. It only produces the expected exit code if both pass. Ok so?

EDIT: I realize the tests should be in seperate folders for bare lamdas and bare functions...

[ergl]

I realize the tests should be in seperate folders for bare lamdas and bare functions...

@stefandd I don't think this matters too much. I'll be okay with you putting them all in the same test.

[SeanTAllen]

I'd prefer separate tests

[ergl]

Looks good to me except for some wording and spacing nits.