Replacing (C-not exported) in the docs

[munjesi]

This PR fixes #2105. Before (C-not exported) statements were appearing in the docs but now are replaced with "This is not exported to bindings users" . This PR replaces and also ensures that any of these comments are on freestanding lines (i.e. come after a blank /// line).

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: -0.01 ⚠️

Comparison is base (12d799e) 91.15% compared to head (702d5bc) 91.14%.

📣 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             @@
##             main    #2110      +/-   ##
==========================================
- Coverage   91.15%   91.14%   -0.01%     
==========================================
  Files         101      101              
  Lines       48868    48868              
  Branches    48868    48868              
==========================================
- Hits        44545    44542       -3     
- Misses       4323     4326       +3     

Impacted Files	Coverage Δ
lightning-background-processor/src/lib.rs	78.29% <ø> (ø)
lightning-invoice/src/lib.rs	80.59% <ø> (ø)
lightning-invoice/src/ser.rs	91.59% <ø> (ø)
lightning-rapid-gossip-sync/src/lib.rs	85.13% <ø> (ø)
lightning/src/chain/keysinterface.rs	84.79% <ø> (ø)
lightning/src/chain/transaction.rs	100.00% <ø> (ø)
lightning/src/ln/chan_utils.rs	93.75% <ø> (ø)
lightning/src/ln/channelmanager.rs	88.86% <ø> (ø)
lightning/src/ln/features.rs	97.83% <ø> (ø)
lightning/src/ln/mod.rs	95.00% <ø> (ø)
... and 11 more

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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

[TheBlueMatt]

Sadly syn, the tool the bindings generator uses to parse the source tree, ignores comments entirely, so we cannot remove these from the docs entirely. Further, I do think they're vaguely useful to humans - many of our bindings users do read the docs on crates.io, and its useful to tell them that certain methods are missing and why. Now, that said, we can change the string arbitrarily, it doesn't need to say (C-not exported) it can just as well say "This is not exported to bindings users " and the bindings generator could match on that.

[munjesi]

Sadly syn, the tool the bindings generator uses to parse the source tree, ignores comments entirely, so we cannot remove these from the docs entirely. Further, I do think they're vaguely useful to humans - many of our bindings users do read the docs on crates.io, and its useful to tell them that certain methods are missing and why. Now, that said, we can change the string arbitrarily, it doesn't need to say (C-not exported) it can just as well say "This is not exported to bindings users " and the bindings generator could match on that.

Thank you for shedding more light on this, let me incorporate the shared suggestions and make the necessary changes

[tnull]

Also, note that the main intent of #2105 to ensure that any of these comments are on freestanding lines (i.e. come after a blank /// line), as otherwise they might end up in the description column of module/crate overviews in the docs.

[munjesi]

@TheBlueMatt @tnull thank you for the review, I've addressed all the review comments in the new commit.

[tnull]

@TheBlueMatt @tnull thank you for the review, I've addressed all the review comments in the new commit.

Ah, it seems there has been a slight mixup. Excuse if I haven't been entirely clear before:

1. If any functions only have the (C-not exported) or (This is not exported to bindings users) it is fine to leave it as is.
2. If there is a prior paragraph in the comments, this paragraph needs to be separated by a blank comment line, e.g.:

/// Here is some comment on below function
///
/// (C-not exported) ...
pub fn below_function(&self) -> bool {

[TheBlueMatt]

If we're gonna change the text, there's no reason to keep the () around the text.

[munjesi]

I've cleaned up and made the recommended changes, also have rebased with the latest code.