(WIP/Experiment) Add docstrings

[reez]

Description

The UDL file supports docstring comments.

So I wanted to test it out to see how/if it worked properly, any "gotchas", etc. And also to test it against CI.

This doesn't have to be merged or anything, I'm sure we want to discuss together when we want to start adding these docstrings as we get closer to 1.0.0-beta.

I just started from the top of the .udl file and worked my way down about 150 lines so I could run into a bunch of different scenarios.

Once I made the changes one-by-one I had a sample Xcode project open to look at and test the bdk-swift bindings that were generated.

Notes to the reviewers

Things I've tried to notice and make consistent:

• Always started with a capital letter.
• Always ended with a period.
• Always formatted a reference to code properly.

General open questions:

• How long is too long of a line (2 sentences? 100 characters? etc) before breaking it into another line?
• TxBuilder has a code example that I left out, do we want to leave those in (and if so how do we want to format those so they look best)?

Screenshots

Here's an example screenshot of what Xcode looks like for the Wallet docstrings:

Changelog notice

Checklists

All Submissions:

• [x] I've signed all my commits
• [x] I followed the contribution guidelines
• [x] I ran cargo fmt and cargo clippy before committing

New Features:

• [ ] I've added tests for the new feature
• [ ] I've added docs for the new feature

Bugfixes:

• [ ] This pull request breaks the existing API
• [ ] I've added tests to reproduce the issue which are now passing
• [ ] I'm linking the issue being fixed by this PR

Summary by CodeRabbit

• New Features
  • Introduced a new error type for handling specific transaction errors.
  • Added new dictionaries and interfaces enhancing wallet functionalities such as address derivation, balance categorization, transaction output details, and fee rate calculation.
  • Enhanced transaction building with new interfaces and policies for change output and wallet updates.

[coderabbitai[bot]]

Walkthrough

The recent update to bdk-ffi involves significant enhancements aimed at improving Bitcoin wallet functionalities. New features include various data structures for managing addresses, balances, and transactions, alongside interfaces for transaction building and wallet updates. Additionally, error handling and policy management for transaction outputs have been refined.

Changes

File Path	Changes Summary
bdk-ffi/src/bdk.udl	Added Alpha3Error, KeychainKind, AddressInfo, AddressIndex, Balance, LocalOutput, TxOut, CanonicalTx, FeeRate, ChangeSpendPolicy, Wallet, Update, TxBuilder interfaces and enums. Enhanced error handling for TxGraph::calculate_fee.

---

Recent Review Details

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 54f32352540a1be2afb2e02f4a9e598efe0ad60a and a04a7cc749bfdcfe87d48ab43307da210cf1bd1c.

Files selected for processing (1)

• bdk-ffi/src/bdk.udl (6 hunks)

Additional comments not posted (12)

bdk-ffi/src/bdk.udl (12)

7-7: The docstring for Alpha3Error is clear and concise. It effectively communicates that this is a temporary error type for the alpha version of bdk-ffi.

---

13-13: The docstring for CalculateFeeError is informative, explaining the context in which these errors occur. However, consider adding more detail about the conditions that lead to each specific error for better clarity.

---

118-118: The KeychainKind enum is well-defined. The docstring is succinct and the values are appropriately named, reflecting their usage clearly.

---

124-124: The AddressInfo dictionary is well-structured and the docstring provides a good level of detail. However, ensure that the address field is defined somewhere in the UDL or is a known type in the context of this project.

Verification successful

---

The verification process has confirmed that the Address type is indeed defined within the project, specifically in the bdk-ffi/src/bdk.udl file as an interface. This aligns with the requirements mentioned in the review comment to ensure that the address field in the AddressInfo dictionary is a known type in the context of this project.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that the `Address` type is defined elsewhere in the UDL or in the project.
rg --type udl 'interface Address|dictionary Address'

Length of output: 82

---

---

Script:

#!/bin/bash
# Search for the definition of the `Address` type across all files, as the previous attempt with a specific file type failed.
rg 'interface Address|dictionary Address'

Length of output: 218

---

131-131: The AddressIndex interface is clearly documented. The use of an enum for selection strategies is a good design choice, making the API easier to understand and use.

---

139-139: The Balance dictionary is comprehensive and covers various types of balances which could be associated with a wallet. The fields are well-named and the overall structure is logical.

---

154-154: The LocalOutput dictionary is crucial for managing unspent outputs. The inclusion of the is_spent boolean is a thoughtful addition for tracking the state of each output.

---

185-185: The FeeRate interface is well-defined. The methods provided offer flexibility in handling fee rates. Consider adding a brief explanation in the docstring about when to use each constructor method.

---

200-200: The ChangeSpendPolicy enum is clearly defined. The values are self-explanatory which is good for ease of use.

---

207-207: The Wallet interface is central to the functionality of the bdk-ffi. The constructor's parameters are well thought out, covering essential aspects needed to instantiate a wallet. Ensure that all types used, such as Descriptor, are defined within the UDL or are known types within the project.

Verification successful

---

The verification process has confirmed that the Descriptor type is indeed defined within the bdk-ffi/src/bdk.udl file. This aligns with the review comment's requirement to ensure that all types used, such as Descriptor, are defined within the UDL or are known types within the project.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that the `Descriptor` type is defined elsewhere in the UDL or in the project.
rg --type udl 'interface Descriptor|dictionary Descriptor'

Length of output: 88

---

---

Script:

#!/bin/bash
# Search for 'interface Descriptor' or 'dictionary Descriptor' in .udl files
rg 'interface Descriptor|dictionary Descriptor' -g '*.udl'

Length of output: 255

---

250-250: The Update interface is succinctly defined. However, the docstring could be expanded to explain more about what constitutes an update in this context.

---

254-254: The TxBuilder interface is well-documented and provides a comprehensive set of methods for building transactions. This is a critical component for transaction management in the wallet.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

Note: Auto-reply has been disabled for this repository by the repository owner. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[reez]

Wait for beta 2 and https://github.com/bitcoindevkit/bdk-ffi/pull/582

[reez]

waiting for 1.0 final to do this-