Skip to content
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

Fix rust beta docs for lightning-invoice crate. #1490

Merged
merged 1 commit into from
May 23, 2022

Conversation

arik-so
Copy link
Contributor

@arik-so arik-so commented May 19, 2022

No description provided.

@TheBlueMatt
Copy link
Collaborator

Do we not need/can we add the ; after the let elements... line and assert_eq line...

TheBlueMatt
TheBlueMatt previously approved these changes May 19, 2022
jkczyz
jkczyz previously approved these changes May 19, 2022
lightning-invoice/src/lib.rs Outdated Show resolved Hide resolved
@codecov-commenter
Copy link

codecov-commenter commented May 19, 2022

Codecov Report

Merging #1490 (f500711) into main (36817e0) will decrease coverage by 0.00%.
The diff coverage is n/a.

❗ Current head f500711 differs from pull request most recent head f9d3576. Consider uploading reports for the commit f9d3576 to get more accurate results

@@            Coverage Diff             @@
##             main    #1490      +/-   ##
==========================================
- Coverage   90.90%   90.90%   -0.01%     
==========================================
  Files          77       77              
  Lines       42201    42201              
  Branches    42201    42201              
==========================================
- Hits        38364    38362       -2     
- Misses       3837     3839       +2     
Impacted Files Coverage Δ
lightning-invoice/src/lib.rs 87.39% <ø> (ø)
lightning/src/util/events.rs 33.56% <0.00%> (-0.35%) ⬇️
lightning/src/ln/functional_tests.rs 97.08% <0.00%> (-0.04%) ⬇️
lightning-net-tokio/src/lib.rs 76.21% <0.00%> (+0.30%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 36817e0...f9d3576. Read the comment docs.

TheBlueMatt
TheBlueMatt previously approved these changes May 19, 2022
@arik-so arik-so requested a review from jkczyz May 19, 2022 18:28
@TheBlueMatt
Copy link
Collaborator

Oof, looks like we need it to use defined types....matbe lets just not make it a code doc?

@jkczyz
Copy link
Contributor

jkczyz commented May 19, 2022

Oof, looks like we need it to use defined types....matbe lets just not make it a code doc?

I think use Enum::*; is the problem. IIUC, you can't do this for enum variants. They need to be fully qualified as Enum::A, etc.

@arik-so
Copy link
Contributor Author

arik-so commented May 19, 2022

Oh lol, I have already started figuring out how to fix this

@jkczyz
Copy link
Contributor

jkczyz commented May 19, 2022

Oh, and find_extract and find_all_extract aren't being found. Hmm... maybe need to exported (conditionally) and have something like use crate::find_extract? Not sure, but should be able to test locally using cargo +beta test -p lightning-invoice.

@@ -796,17 +796,18 @@ impl SignedRawInvoice {
///
/// The following example would extract the first B.
/// ```
/// use Enum::*;
/// use lightning_invoice::{find_extract, find_all_extract};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: only need to import one of them here and below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not technically true. Both need to be imported here, but find_all_extract is indeed sufficient below.

/// ```
#[macro_export]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we want to export these though... Is there a way to do it conditionally for tests?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we just need to make it a non-``` comment so that rustc doesn't try to run it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried #[cfg_attr(test, macro_export)], but that's not working. It'd be a shame to make the code not be evaluated, as it's verifying the accuracy of the comment though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's even wilder. When I explicitly say #[cfg_attr(not(test), macro_export)] as a sanity check, it works!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you've found the attribute Google wouldn't show me. Yet alas, also no.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So question. If the docs show how to use the macro, wouldn't that require the macro be public? Otherwise the docs are simply inaccurate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was more to test that the macros works as expected and to show internal developers how to use it. It's possible to generate docs for private items, too.

Suppose it could have be a normal test. Maybe already covered by other tests, though. I'd say just remove the ticks as Matt suggested.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I gave up on the macros and reverted everything except the semicolons.

/// assert_eq!(find_extract!(elements.iter(), Enum::B(ref x), x), Some(3u16))
/// ```
/// assert_eq!(find_extract!(elements.iter(), Enum::B(ref x), x), Some(3u16));
/// ``
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does double ticking do anything? Thought that would just be the empty string formatted in markdown.

/// ```
/// use Enum::*
/// ``
/// use Enum::*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May as well have kept the fully-qualified enum variants as I don't think this was ever valid rust. 😛

Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTRM - please squash!

@jkczyz jkczyz merged commit 75ca50f into lightningdevkit:main May 23, 2022
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.

None yet

4 participants