use dynamic trampoline for all getters and setters

[davidhewitt]

This is an extension to the "trampoline" changes made in #2705 to re-use a single trampoline for all #[getter]s (and similar for all #[setters]). It works by setting the currently-unused closure member of the ffi::PyGetSetDef structure to point at a new struct GetSetDefClosure which contains function pointers to the getter / setter implementations.

A universal trampoline for all getter, for example, then works by reading the actual getter implementation out of the GetSetDefClosure.

Advantages of doing this:

• Very minimal simplification to the macro code / generated code size. It made a 4.4% reduction to test_getter_setter generated size, which is an exaggerated result as most code will probably have lots of bulk that isn't just the macro code.

Disadvantages:

• Additional level of complexity in the getter and setter trampolines and accompanying code.
• To keep the GetSetDefClosure objects alive, I've added them to the static LazyTypeObject inner.
• Very slight performance overhead at runtime (shouldn't be more than an additional pointer read). It's so slight I couldn't measure it.

Overall I'm happy to either merge or close this based on what reviewers think!

[davidhewitt]

Ok, I've pushed a commit which removes the use of unreachable_unchecked. It does this by moving the logic constructing the getters & setters into a builder / enum in create_type_object.rs, and picking an appropriate trampoline / closure pair inside match arms.

I've added some TODO where we could add some validation that only one #[getter] per property etc, which can be a future PR.

[davidhewitt]

• To keep the GetSetDefClosure objects alive, I've added them to the static LazyTypeObject inner.

I think this is no longer a disadvantage, as I've added the "name" and "doc" members to this too, which addresses an older TODO to avoid naively leaking those things.

[adamreichold]

bors r+

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• conclusion