-
Notifications
You must be signed in to change notification settings - Fork 414
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
Parse __attribute__((deprecated("Message")))
and show it in the documentation
#843
Comments
any chance of |
The Objective-C sourcekitten json output already contains keys for deprecated/unavailable and any message from Supporting the headerdoc keyword is a bit different but is plausible once the presentation part is done. |
Currently it looks like the deprecated/unavailable keys ( __attribute__((deprecated("message"))
// and
__deprecated_msg("message") So I think for this to work SourceKitten would need some additions for both Objective-C and Swift. Related: jpsim/SourceKitten#214 |
Closing this one because the ObjC part is done - can use good old #11 to track the Swift part for now. |
Objective-C methods marked as deprecated are currently not shown in the documentation generated by Jazzy as such. Everything needed for documenting this properly is already in the source code, even if there is no
@deprecated
attribute in the documentation, so Jazzy should parse this and make the user browsing the documentation aware of the fact that a method is deprecated.Ideally Jazzy would show a yellow~ish box with a "Deprecated" title and the message from the deprecated attribute and also strike through the method name in the list. The latter would be very great but I would consider that as optional. It would already be a huge benefit for a developer to see that a method is deprecated when actually reading its documentation.
Another addition would be that if a
@deprecated
keyword is available in the comment for the methods, this should probably take precedence over the deprecated attribute in the source as the@deprecated
keyword is explicitly there for documentation purpose, so I'd say this reasoning is valid.When a complete class is marked as deprecated, the same box should be visible at the class documentation.
The text was updated successfully, but these errors were encountered: