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

javadoc: allow space before parameter direction indication #244

Merged
merged 1 commit into from
Aug 28, 2024

Conversation

jnikula
Copy link
Owner

@jnikula jnikula commented Aug 27, 2024

Having whitespace between @param and [direction] fails to match the param regex:

@param[in] works
@param [in] fails

This is detected but not handled properly, leading to a backtrace about mo.group() being called when mo is None.

Fix the regex and, to an extent, the error handling.

This is just the simplest and quickest fix. There should be better error handling with proper error messages all around, as well as testing.

@jnikula jnikula requested a review from BrunoMSantos August 27, 2024 11:17
Having whitespace between @param and [direction] fails to match the
param regex:

 @param[in] works
 @param [in] fails

This is detected but not handled properly, leading to a backtrace about
mo.group() being called when mo is None.

Fix the regex and, to an extent, the error handling.

This is just the simplest and quickest fix. There should be better error
handling with proper error messages all around, as well as testing.
@jnikula jnikula force-pushed the javadoc-param-direction-fix branch from dbffab8 to 1aad1bf Compare August 28, 2024 11:28
Copy link
Collaborator

@BrunoMSantos BrunoMSantos left a comment

Choose a reason for hiding this comment

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

Agree that there should be testing and better error handling, but this is still an improvement and it is a 'side-feature' after all. I think it's fair to merge the regex fix.

self.rest())
if mo is None:
# FIXME
yield ''
return
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can't we suppress the yield then? In fact, why are we using yield in this function at all?

Copy link
Owner Author

@jnikula jnikula Aug 28, 2024

Choose a reason for hiding this comment

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

I guess the design (or lack thereof) is based on this loop:

def _process_docstring(app, lines, transform, options):
    if transform != app.config.hawkmoth_javadoc_transform:
        return

    lines[:] = [line for line in _convert(app=app, lines=lines)]

By having _convert() and anything it calls yield the stuff just works nicely, because the conversion of a single line may result in more than one line.

And rst being rst, it's better to emit the blank line if the conversion fails.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, my brain's fried right now tbh, but we only ever yield once per call of header(), right? Does yielding yield any gain in that case (pun intended)?

Copy link
Owner Author

Choose a reason for hiding this comment

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

No, header() yields 1-4 lines, depending on the class.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, I see, though I don't think it makes a difference if we were to return in the cases where it yields only once. Anyway, the code is correct, and I get the argument of following a pattern 👍

@jnikula jnikula merged commit dc8d572 into master Aug 28, 2024
5 checks passed
@jnikula jnikula deleted the javadoc-param-direction-fix branch August 28, 2024 22:19
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.

2 participants