-
Notifications
You must be signed in to change notification settings - Fork 34
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
Revert "Revert "add ivar
and macro
to the known symbol kinds" (#24)"
#26
Conversation
@swift-ci Please test |
@@ -23,6 +23,8 @@ extension SymbolGraph.Symbol { | |||
case `func` | |||
case `operator` | |||
case `init` | |||
case ivar |
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.
Should we consider converting these to statically defined properties to avoid API breakage like this in the future?
It doesn't seem like we should be promising a totally stable API here via enum cases.
It will be API breaking either way since clients will need to add a new default
case but at least we'll avoid breaking API in the future.
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.
+1 here. I think we need to add a default unknown kind to avoid these sorts of breakages.
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 like this suggestion! I imagine we'll want to add more symbol kinds in the future, and implying that consumers can exhaustively match them is perhaps a little misleading, if we want to properly support any symbol kind that a potential symbol graph could offer (cf. #7).
Could we change Swift-DocC to use case default
branches first, though? It should still work with an enum, and the DocC code defaults to an .unknown
symbol kind anyway. Then we could land this type definition change to KindIdentifier
here without breaking DocC or toolchain builds.
Based on @ethan-kusters's comment and offline discussion, i'm closing this series of PRs in favor of an alternate implementation path that should avoid breaking Swift CI. |
This reverts commit 3cd58e7.
Bug/issue #, if applicable: rdar://91166981
This PR re-applies the changes from #21. A corresponding change in Swift-DocC (apple/swift-docc#126) is required to land quickly afterward.