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.
Matt Corallo [Fri, 23 Sep 2022 16:18:55 +0000 (16:18 +0000)]
Use trait, not impl, definition for X_as_Trait functions
When we map a trait impl block, we historically didn't know how to
resolve the types in the trait context, so we just used the impl
context definitions and assumed the types were the same. Sadly, if
we have an associated type that is bounded by a trait, we need to
use the trait bound to figure out what to write for the X_as_Trait
method declarations.
Since we now have the ability to generate full trait-context type
resolvers, we do so here.
Matt Corallo [Mon, 19 Sep 2022 10:16:38 +0000 (10:16 +0000)]
Support mapping `Readable` `impl`s outside of the `lightning` crate
In order to map `Readable` `impl` blocks in crates other than the
`lightning` main crate we simply have to update the type references
to include crate name, which we do here.
Matt Corallo [Fri, 23 Sep 2022 16:12:46 +0000 (16:12 +0000)]
Prefer `Option_` mappings for more types over transparent mappings
In general, the explicit `Option_` mappings are easier for
downstream bindings to match against, and clearer for users anyway.
Sadly, originally we were trying to avoid them where possible, so
some types default to transparent mappings. Here we swap the
default, at least for manually-mapped types, with a few explicit
exceptions (that probably should be changed as well).