-
-
Notifications
You must be signed in to change notification settings - Fork 224
Generate documentation from doc comments #748
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i've actually also worked a little bit on this too, but i dont think this as written is the best solution. i'll try to avoid nitcpicking since it's a draft pr, but i think the better way of doing this is:
Proc macros
- gets the doc-comments
- parses markdown (using the markdown crate or something)
- converts the parsed markdown into xml, but not the top-level
<class>
xml since that will need to happen later - registers plugins using the plugin system
There will then be two doc-plugins, one for the #[derive(GodotClass)]
and one (or two if we can add documentation to overridden virtual methods?) for the #[godot_api]
.
We could probably just add the doc-plugins to the existing Struct
and InherentImpl
plugins.
Godot-core
- gathers up these plugins
- puts the documentation into a
<class>
tag - calls the registration method
feaadc1
to
6ebf19d
Compare
0c5d8ea
to
9b73845
Compare
449749d
to
19bf2bb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I think this implementation is good for now, there are things that arent supported however. Like linking to other classes with [classname]
syntax for instance. Could you maybe add a comment somewhere about what is explicitly not supported?
Additionally you should write some documentation on the relevant derive macros (GodotClass
and godot_api
) about how this documentation works. This could be a good place to document what isn't supported.
Also what happens if you try to use this in godot 4.2? Do you get a nice error message? does it just silently do nothing?
Also you're lacking much in terms of testing, could you add some explicit tests of this functionality? it'd be ideal if we could actually test that the documentation as registered with godot actually corresponds to what we expect. I think some of this can actually be unit tested as well which would be great.
Most of my comments are about code-style/organization, im sorry if it's a bit much. feel free to take your time going through it.
efc5749
to
1f7e32e
Compare
Actually |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should try to more thoroughly test the possible markdown syntaxes, to ensure that it doesn't break anything and to know what the output is gonna be. This will also ensure that if we later update our converter to better handle these cases then we'll already have a test that will cover those cases.
headings:
/// # Some heading
lists:
/// - lists
/// - like this
/// * maybe with `*` as well
links with back-references:
/// Blah blah [foo]
/// [foo]: https://example.org
footnotes:
/// We cannot florbinate the glorb[^florb]
/// [^florb]: because the glorb doesn't flibble.
task lists:
/// We must ensure that we've completed
/// - [ ] task 1
/// - [x] task 2
tables:
/// | Header1 | Header2 |
/// |---------|---------|
/// | abc | def |
images:
/// 
blockquotes:
/// > Some cool quote
numbered lists:
/// 1. thing one
/// 2. thing two
horizontal rules:
/// Something here
/// ---
/// And here
smart punctuation
/// test --- a -- b ... foo "asd" or 'hi'
maybe also some custom html somewhere
|
||
#[godot_api] | ||
impl INode for ExtremelyDocumented { | ||
fn init(base: Base<Node>) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this function should also be documented imo, to check that it's not exported to godot either
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is exported to godot actually although right now it doesnt register properly
Quite a few of those things arent supported by godot / this implementation but ill test the others. |
sure but we'd ideally not want people's code to break just because they add documentation that isn't supported by godot. so at least testing that they dont break things would be useful imo. |
What does the current state of the docs look like in the editor btw? especially with all the If you could include a side-by-side of the rustdoc output and the godot documentation that'd be really useful too. |
godot-macros/src/docs.rs
Outdated
fn params<'a, 'b>(params: impl Iterator<Item = (&'a Ident, &'b TypeExpr)>) -> String { | ||
params | ||
.enumerate() | ||
.fold(String::default(), |mut acc, (index, (name, ty))| { | ||
use std::fmt::Write; | ||
_ = write!( | ||
acc, | ||
r#"<param index="{index}" name="{name}" type="{ty}" />"#, | ||
ty = ty.to_token_stream() | ||
); | ||
acc | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here, I think a let mut result = String::new();
followed by a for
loop is easier to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the best way is a map to a format! and then a join
is easiest to read, but clippy doesnt like it, should i just #[allow]?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does clippy not like or suggest instead?
This review would be so much faster if you could provide the relevant information without us always having to ask for it 😔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you need #[allow]
, then rather use the variant with for
loop. It might also need fewer allocations if a single string is extended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clippy suggests this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it wont be more efficient as we still need a format!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clippy suggests replacing a good old for loop with a fold()
call? I find that hard to believe.
Can you not keep the simplest possible procedural code?
Also here, I think a
let mut result = String::new();
followed by afor
loop is easier to understand.
// bbcode supports lists but docs dont | ||
List(_) | BlockQuote(_) | FootnoteReference(_) | FootnoteDefinition(_) | Table(_) => { | ||
"unsupported".into() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// bbcode supports lists but docs dont | |
List(_) | BlockQuote(_) | FootnoteReference(_) | FootnoteDefinition(_) | Table(_) => { | |
"unsupported".into() | |
} | |
// BBCode supports lists, but Godot docs don't. | |
List(_) | BlockQuote(_) | FootnoteReference(_) | FootnoteDefinition(_) | Table(_) => { | |
"unsupported".into() | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, should we not try to keep the original as much as possible, even if unformatted?
Or what's the idea of replacing them with "unsupported" literal?
4c67a82
to
4839237
Compare
adc3595
to
fbd8f52
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this great addition and the patience during review!
List(_) | BlockQuote(_) | FootnoteReference(_) | FootnoteDefinition(_) | Table(_) => { | ||
"".into() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: we still need to implement this at some point (at least unformatted) 🙂
Generate documentation from doc comments
closes #178