Matt Corallo [Sun, 30 Jul 2023 03:36:56 +0000 (03:36 +0000)]
Include a `struct` before trait return fields
EIther `struct Type` or `Type` work fine because of our type
declarations, but cbindgen uses `struct Type` everywhere so its
easiest if we match it, especially for downstream code.
Matt Corallo [Sat, 22 Jul 2023 20:03:11 +0000 (20:03 +0000)]
Allow generation of manual types in reference options
The limiting of supported types in `write_template_generics` isn't
super useful as its only called once per type - later uses of the
same type with the reference flag set or wiped doesn't change
anything. Still, it is relied on somewhat, so we can't drop it
entirely.
Now that we've moved more of the `[u8; 32]` newtypes to option
wrappers, failing for non-primitive references spuriously breaks.
Instead, we just allow it for manually-mapped types and let the
compiler complain if we do something invalid.
Matt Corallo [Thu, 20 Jul 2023 22:51:01 +0000 (22:51 +0000)]
Handle all traits in type resolution, including no-export ones
In the previous commit, we set up handling of no-export traits with
only a single implementor. In order to utilize that, we need such
traits to participate in type resolution, which we add support for
here.
Matt Corallo [Mon, 17 Jul 2023 02:16:01 +0000 (02:16 +0000)]
Handle no-export traits which are only implemented once as the implementor
If we have a trait marked no-export, and there's a single
implementor, we can just pretend its always the implementor. This
makes sense in LDK, for example, for the `APeerManager` trait,
which is implemented for all `PeerManager`s, but doesn't make sense
in bindings.
Matt Corallo [Thu, 27 Jul 2023 20:00:25 +0000 (20:00 +0000)]
Fix strict-aliasing violation on traits holding inner fields
When we map a trait method which returns a reference to a struct,
we map it by storing said struct in the trait implementation
struct. Then, we create a setter method which ensures the new field
is set. Sadly, because the original Rust trait method may take a
non-mutable reference to self, we have to update the field without
a mutable reference to the trait implementation struct.
Previously we did this by simply unsafe-casting a pointer to
mutable, which violates the aliasing rules in Rust. In a recent
rustc (at least on macOS), this broke.
Here, we convert the stored struct to wrap it in an `UnsafeCell`,
which fixes the issue.
Matt Corallo [Tue, 25 Apr 2023 17:14:37 +0000 (17:14 +0000)]
Replace type resolution assertions with failures
Type resolution now supports failing, but some assertions are still
left over from when it didn't. Replace some of those which now fail
on LDK 0.0.115.
Matt Corallo [Mon, 27 Feb 2023 21:25:27 +0000 (21:25 +0000)]
Support supertraits-of-supertraits
If we have a supertrait that requires an in-crate supertrait, we
handle that here by writing the required impls. We don't support
a supertrait-of-a-supertrait-of-a-supertrait.
Matt Corallo [Mon, 27 Feb 2023 18:51:59 +0000 (18:51 +0000)]
Support passing `Option<&OpaqueStruct>` to C
Luckily the solution is trivial - just treat the conversion for the
inner pointer as `ptr_for_ref`, because we ultimately want a
pointer on the inside, not on the outside.
Matt Corallo [Sat, 24 Dec 2022 18:14:37 +0000 (18:14 +0000)]
Set the C target to wasm32-wasi rather than wasm32
We need at least a partial C stdlib anyway, so there's no real
difference going ahead and linking wasm32-wasi on the C side vs
only on the Rust side. This fixes compilation on Debian testing
with OS packages installed.
Matt Corallo [Thu, 27 Oct 2022 00:18:18 +0000 (00:18 +0000)]
Handle multiple `impl`s of the same trait in the same file
This should be easy, but we end up with redundant `use` statements.
Thus, we instead track which use statements we want and put them at
the end when generating new files
Matt Corallo [Thu, 27 Oct 2022 00:15:31 +0000 (00:15 +0000)]
(Partially) support supertraits with generic bounds
If we extend a supertrait where the supertrait is generic, we will
ultimately need to genericize the supertrait into a derived object.
This doesn't implement that part, but it does implement the
subtrait-writing code to make it compatible with such a future.
Matt Corallo [Mon, 19 Sep 2022 12:51:02 +0000 (12:51 +0000)]
Allow liftime bounds on generic bounds
While liftime bounds require bindings users to ensure liftime
requirements are met, they're important for allowing us to export
lock wrappers. Thus, we relax the simple-bounds assertions checks
here.