-
-
Notifications
You must be signed in to change notification settings - Fork 11k
util/find-doc-nits: more precise option and function name checker #10073
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
The checks for our uses of 'B<' and 'I<' for options, and possibly function names, was over-reaching quite a bit. So we fine-tune it a bit: - by only checking for options in man1 pages, and only in SYNOPSIS and *OPTIONS sections. - by only checking for function names in man3 pages. The man1 option checker has the additional check that options found in *OPTIONS are also found in SYNOPSIS andd vice versa. In all cases, this also handles options and function names with additional markup, such as 'B<-I<cipher>>' and 'B<sk_I<TYPE>_push>'.
|
Note that Travis will fail, because there is plenty of incomplete option documentation. That's actually a good thing, it shows that this script does its job right. |
richsalz
left a comment
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.
hey, i even still understood my script after these changes :)
|
And it would be good to see this merged soon, since all builds are currently broken. |
do we want to do that? there are a LOT of undocumented flags. breaking all travis jobs until they're fixed doesn't seem quite right. And BTW, look at the "-c" flag to find-doc-nits. Either remove that, or disable the reporting you do, we should only do it once. |
I agree - we should get travis fixed asap. |
|
[sigh] I have a separate PR where I'm fixing up doc/man1. I'm sure you've noticed. |
|
please don't lose the last line of my #10073 (comment) |
My check does something different, it detects inconsistencies between SYNOPSIS and OPTIONS, i.e. if an option is given in one of them but not the other. So this has absolutely nothing to do with options not being documented at all. |
Got it, thanks. I still think that it is very wrong to check in code that knowingly breaks CI builds. OpenSSL has enough instances of doing it by mistake. |
I agree - we should avoid doing that. Does #10065 address the new issues that this PR finds? |
|
No. They were broken by #10041, which broke find-doc-nits handling some new syntax. This PR fixes that issue, but then continues to break the build by adding a new type of error, the synopsis/options inconsistency mentioned above. |
|
Does merging this PR leave doc-nits builds still broken? Yes, because of the new check you added which you are planning on fixing in another PR. |
|
What I have done in other PR's, and what I think should be done here, is that the errors at lines 318 and 323 should be commented out and enabled in #10065. Fix the bugs/nits, and enhance find-doc-nits to report issues so it doesn't happen again, in the same PR. |
That seems like a sensible approach. |
|
I find it incredibly interesting that y'all don't want a script that is designed to show where our documentation is wrong, to actually show where the documentation is wrong (or at the very least, inconsistent). A major reason to have it in a separate PR is for demonstration purposes, i.e. demonstrate that it actually does the work it purports to do. If I would put it in #10065, you would have no way to see that without doing extra work. But tell you what, when the changes in this script look acceptable, I can always rebase #10065 on top of this, and we can all see the effect it will have there. Deal? |
|
What I described is what I have always done for doc nits before. We have never needed "proof" that it works" You can get that by making one commit enable the doc-nits changes, and then a separate commit include the fixes. You can put "if $debug" tests around the errors here, and then enable them for production in the other PR. I am only a contributor, but I find it horrible to knowingly check in code that breaks the build. |
We want a fixed travis build more. Only then do we want to see more errors. |
|
That way, we only get to see that it can approve of what's there, but not that it can find faults that are there, at least in the PR that changes it. But like I said, when you have no more issues with the changes here, I will rebase #10065 on top if it, and final approval can happen there. |
|
There were still some malformed options, even thought I removed the SYNOPSIS<->OPTIONS inconsistency check (I'll add it back in another PR), so there are a few affected man-pages. |
|
Why the inclusion of version.sh? |
Mistake. I have no idea how it ended up in here. Fixed. |
|
I think I've answered all outstanding issues |
|
CIs are happy. Are you? |
|
I am happy. :) Thanks for listening. |
|
I'm glad you are ;-). I hope someone with approval power is as well ... |
mattcaswell
left a comment
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.
LGTM
The checks for our uses of 'B<' and 'I<' for options, and possibly function names, was over-reaching quite a bit. So we fine-tune it a bit: - by only checking for options in man1 pages, and only in SYNOPSIS and *OPTIONS sections. - by only checking for function names in man3 pages. The man1 option checker has the additional check that options found in *OPTIONS are also found in SYNOPSIS andd vice versa. In all cases, this also handles options and function names with additional markup, such as 'B<-I<cipher>>' and 'B<sk_I<TYPE>_push>'. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #10073)
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #10073)
The checks for our uses of
B<andI<for options, and possiblyfunction names, was over-reaching quite a bit.
So we fine-tune it a bit:
SYNOPSISand
*OPTIONSsections.The man1 option checker has the additional check that options found in
*OPTIONSare also found inSYNOPSISand vice versa.In all cases, this also handles options and function names with
additional markup, such as
B<-I<cipher>>andB<sk_I<TYPE>_push>.