fix(graindoc): Add all function parameters to the table, even if missing documentation#2293
fix(graindoc): Add all function parameters to the table, even if missing documentation#2293marcusroberts wants to merge 5 commits intomainfrom
Conversation
marcusroberts
requested review from
alex-snezhko,
ospencer and
phated
as code owners
|
Take care when merging #2292 which makes changes to Graindoc. |
spotandjake
left a comment
spotandjake
left a comment
There was a problem hiding this comment.
Looks like the stdlib needs to be regened npm run stdlib doc, I think we still want to maintain the errors from before to ensure docs are well structured, and alert people when they mistype params.
spotandjake
force-pushed
the
marcus/issue_2281
branch
from
81e6843 to
f202019
Compare
|
We should be good to fully close #2281, the implementation now adds any missing items to the table and gives a warning that they are missing. |
| | ToStringUnsafe(string) | ||
| | ArrayIndexNonInteger(string); | ||
| | ArrayIndexNonInteger(string) | ||
| | ParameterDocumentationMissing(string); |
There was a problem hiding this comment.
I don't think we want to add this as a warning to the compiler proper. We should start a set of Graindoc warnings.
There was a problem hiding this comment.
As a noted in discord until #2343, I don't think there's an easy way todo this while using the same handler and printing logic we use in the compiler. I think it's ideal we use the same printing logic so any printing improvements there get reflected back in the grain doc warnings.
Maybe for #2342 the warning handler could be a functor that takes the error types and printing handler allowing us to use it in all of our tooling.
There was a problem hiding this comment.
As a noted in discord until #2343, I don't think there's an easy way todo this while using the same handler and printing logic we use in the compiler. I think it's ideal we use the same printing logic so any printing improvements there get reflected back in the grain doc warnings.
Maybe for #2342 the warning handler could be a functor that takes the error types and printing handler allowing us to use it in all of our tooling.
Unless you have a better idea I think we should keep the error handling here for now and move with #2342, we can renumber our errors then which shouldn't be a problem as we don't reference the numbers anywhere currently.
3 participants
Partially Fixes #2281
Add all function parameters to the documentation table in the order they are defined.
Add an empty documentation field for any that are missing user supplied documentation in the comment above.
(New and Updated tests to follow)