Exposing lib bindings in macro API outside of methods

[straight-shoota]

You shouldn't document those (at least from an API point of view) because you are not supposed to directly expose them. You should wrap them with Crystal constructs, and document those.

I would be fine with this if macros worked for lib but they don't. Why should someone have to write out potentially hundreds of functions to wrap them? lib methods need a special "LibMethod" type in Macros that has the Crystal method name, C function name, args, and return type.

Originally posted by @sol-vin in #6721 (comment)

[straight-shoota]

That's already the case. The only issue is that because of some semantic intricacies, they are only accessible inside methods:

def foo
  {% p LibC.class.methods %}
end

foo

Originally posted by @asterite in #6721 (comment)

[straight-shoota]

Inside methods doesn't help for creating an API wrapper automatically 🤷

I believe it might be possible to pull up the availability of reflection data for lib types. The interfaces are fixed. There is no impact from type inference.

[asterite]

I believe this can be done, but it will be tricky. A fun is different from a def in that it always have types, and these are eagerly checked, and they produce an External node.

I tried moving that logic to an earlier phase a few times in the past, and I always failed. But maybe someone finds a way to do it! 😄