Skip to content

0.0.115 Bindings Updates #2227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

TheBlueMatt
Copy link
Collaborator

The usual minor tweaks here and there, no major changes from 114 but one commit dropped.

@TheBlueMatt TheBlueMatt marked this pull request as draft April 25, 2023 17:19
@TheBlueMatt TheBlueMatt force-pushed the 2023-04-0.0.115-bindings branch from f5c0dba to 5f83f01 Compare April 26, 2023 00:13
@TheBlueMatt
Copy link
Collaborator Author

Sorry for the delay, missed a few things, also rebased on #2229 so we actually do an initial export of some of the bolt12 structs.

@codecov-commenter
Copy link

codecov-commenter commented Apr 26, 2023

Codecov Report

Patch coverage: 73.33% and project coverage change: -0.01 ⚠️

Comparison is base (b734735) 91.55% compared to head (5f83f01) 91.55%.

❗ Current head 5f83f01 differs from pull request most recent head 8d7615b. Consider uploading reports for the commit 8d7615b to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@                 Coverage Diff                  @@
##           0.0.115-bindings    #2227      +/-   ##
====================================================
- Coverage             91.55%   91.55%   -0.01%     
====================================================
  Files                   104      104              
  Lines                 51749    51758       +9     
  Branches              51749    51758       +9     
====================================================
+ Hits                  47379    47387       +8     
- Misses                 4370     4371       +1     
Impacted Files Coverage Δ
lightning-invoice/src/lib.rs 80.02% <ø> (ø)
lightning-invoice/src/payment.rs 89.11% <ø> (ø)
lightning-invoice/src/utils.rs 96.97% <ø> (ø)
lightning-rapid-gossip-sync/src/lib.rs 85.13% <ø> (ø)
lightning/src/chain/channelmonitor.rs 94.46% <ø> (ø)
lightning/src/ln/mod.rs 95.00% <ø> (ø)
lightning/src/ln/msgs.rs 86.91% <0.00%> (-0.25%) ⬇️
lightning/src/ln/peer_handler.rs 62.57% <ø> (ø)
lightning/src/offers/invoice.rs 90.18% <ø> (ø)
lightning/src/offers/invoice_request.rs 93.40% <ø> (ø)
... and 11 more

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

TheBlueMatt and others added 11 commits April 26, 2023 17:38
This will allow us to pass in that state to the callbacks in the
next commit.
If a `Notifier` has an internal `FutureState` which gathers some
sleeper callbacks, but is never actaully woken, those callbacks
will leak due to a circular `Arc` reference when the `Notifier` is
`drop`'d.

Because `Notifier`s are rarely `drop`'d in production this isn't a
huge deal, but shows up materially in bindings tests as they spawn
many nodes over the course of a short test.

Fixes lightningdevkit#2232
...as the bindings generation does not currently have the ability
to map a reference to a `NodeId` inside a tuple.
.. as the current C bindings generator isn't capable of handling
type aliases in generics in type alias definition currently.
Bindings can't handle references in return types, so reduce the
visibility to pub(crate).
Currently `Writeable` is mapped manually, making it impossible to
automatically map a trait method that is parameterized by
`Writeable` (as is true for the `write` method on `KVStore`).

Ultimately we'll want to move to automatically mapping `Writeable`
like any other trait (only manually mapping the std `Write` and
`Read` traits), so this is only a candidate for the bindings branch,
not upstream. That may take a few releases, however.
Re-exports in Rust make `use` statements a little shorter, but for
otherwise don't materially change a crate's API. Sadly, the C
bindings generator currently can't figure out re-exports, but it
also exports everything into one global namespace, so it doesn't
matter much anyway.
The bindings currently get confused by the implicit `Sign` type, so
we temporarily remove it on the `impl` here.
Re-exports in Rust make `use` statements a little shorter, but for
otherwise don't materially change a crate's API. Sadly, the C
bindings generator currently can't figure out re-exports, but it
also exports everything into one global namespace, so it doesn't
matter much anyway.
Having struct fields with references to other structs is tough in
our bindings logic, but even worse if the fields are in an enum.
Its simplest to just take the clone penalty here.
These really could be handled in the bindings, but for lack of
immediate users there's not a strong reason to, so instead we just
disable them for now.
@TheBlueMatt TheBlueMatt force-pushed the 2023-04-0.0.115-bindings branch from 5f83f01 to 8d7615b Compare April 26, 2023 17:38
@TheBlueMatt TheBlueMatt marked this pull request as ready for review April 26, 2023 17:38
@TheBlueMatt
Copy link
Collaborator Author

Okay, should be good to go, now includes #2229 and #2233.

@TheBlueMatt
Copy link
Collaborator Author

CI? Never heard of it.

@TheBlueMatt TheBlueMatt merged commit 7785df3 into lightningdevkit:0.0.115-bindings Apr 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants