Revert "Revert "add ivar and macro to the known symbol kinds" (#24)"
#26
Conversation
…iftlang#24)" This reverts commit 3cd58e7.
|
@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.
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.
+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.
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 (swiftlang/swift-docc#126) is required to land quickly afterward.