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).
Matt Corallo [Wed, 22 Jun 2022 19:59:45 +0000 (19:59 +0000)]
Add locally defined crates as "dependencies" without `extern crate`
We later use the `dependency` set when doing type resolution to
decide if `::asdf::T` means `current_crate::asdf::T` or `asdf::T`,
which will resolve incorrectly if we don't ensure all possible
crates are in the `dependencies` list.
Matt Corallo [Sat, 18 Jun 2022 19:39:59 +0000 (19:39 +0000)]
Use new `Type`-based generic resolution in `write_rust_path`
This gives us better generic resolution, but because we determine
whether to include a `crate::` prefix or not based on generic
resolution it means we have to pipe through the "type is a generic that
was resolved" flag from `write_rust_type`. We also take this opporunity
to do better decision making for the `crate::` prefix entirely, which
is important for enums that contain trait instances.
Matt Corallo [Fri, 17 Jun 2022 21:01:14 +0000 (21:01 +0000)]
Pass `with_ref_lifetime` through to rust-type-printing from C-path printing
If we get to `write_c_path_intern` with `c_ty` unset, we delegate to
`write_rust_path`, however it would lose the `with_ref_lifetime`
flag, causing us to miss `'static` when printing references in
generic arguments. Here we simply pipe it through.
Matt Corallo [Thu, 23 Jun 2022 16:13:06 +0000 (16:13 +0000)]
Generate mutable references in `default_generics` when relevant
As we move towards resolving generics via the new `Type`-based
interface instead of the string-based one, we need to ensure we
retain the mutability flag when resolving references, which we do
here.
Matt Corallo [Fri, 24 Jun 2022 01:20:33 +0000 (01:20 +0000)]
Do not make `Deref<T>` generic params always a `&T` for traits.
We never expect traits to be passed by reference, so when using
the new-style generic resolution, we shouldn't force all `Deref`s
to `&T`, at least if the `T` is a trait.
Matt Corallo [Tue, 28 Jun 2022 02:14:20 +0000 (02:14 +0000)]
Add a note in output documentation for fields with refs to opaques
Because we (probably shouldn't, but do) map "opaque" structs with
an `is_owned` field instead of having a dedicated reference type,
fields which are a `Deref<Struct>` are simply mapped as
`OpaqueMappedStruct`. This is confusing for downstream `lightning.h`
consumers as they cannot differentiate between a field that expects
to own a `Struct` and one which expects to own a reference to it.
This is worked around here by adding documentation which can be
matched on, though ultimately structs should move towards full
ownership.
Matt Corallo [Fri, 24 Jun 2022 01:16:46 +0000 (01:16 +0000)]
Correctly set the `ptr_for_ref` arg on `write_c_type` calls in enum printing
This avoids adding references to opaque structs in enum fields,
where we should, of course, map them as owned opaque structs.
It does generate some difficult-to-parse-by-downstream-bindings
code, which is addressed in a later commit by adding documentation.
Note that it also relies on the types being mapped differently
being opaque as it now needs logic to map a reference to a
non-reference with `is_owned` unset.
Matt Corallo [Mon, 30 May 2022 23:51:54 +0000 (23:51 +0000)]
Include the `where` clause from a "real" type when mapping type aliases
ie if we have a
```
struct A<T: Deref> where T::Target: Trait {}
pub type B<T> = A<T>;
```
this includes the `where` clause so that we end up calling
`writeln_opaque` for `struct B<T: Deref> where T::Target: Trait {}`
instead of `struct B<T: Deref> {}`.
Matt Corallo [Wed, 22 Jun 2022 19:30:05 +0000 (19:30 +0000)]
Add where-clause generic params to `default_generics` map
This moves yet more generic resolution to being able to rely on the
`default_generics` map for full-`Type` resolution rather than
string-based name resolution.