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) ...pubfn 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.

[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) ...pubfn 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.

[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) ...pubfn 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.

[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) ...pubfn 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.

[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) ...pubfn 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.

[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) ...pubfn 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.

[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) ...pubfn 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.

[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) ...pubfn 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.