- replacing "relationhips" with "relationships"
- emitting the "pathComponents" property on symbols
- emitting the "accessLevel" property on symbols
dang on Apr 4 2022, 9:21 AM.Authored by
After a quick scan comparing the current output of these symbol graphs with the primary library used for reading them, the last thing i can spot that's "off" is that the "function signature" is currently being serialized under a parameters field instead of the required functionSignature.
Hmm, I was looking at the format specification at https://github.com/apple/swift-docc-symbolkit/blob/0a45209833f4a151212c1aa38e13cfc03b9462e4/openapi.yaml#L307, and I searched the term functionSignature in the spec but found no property with that name (except for the FunctionSignature schema that the parameters property is referring to). But anyway this should be a easy fix.
It seems like the specification and implementation have diverged. The parser in swift-docc-symbolkit is looking for a functionSignature field by virtue of how it names its "coding key". By comparison, here is the functionSignature emitter in the Swift symbol-graph generator.
Yeah we should fix that I will do it as part of this patch since it seems like a small change.
I like the idea of using the RAII context/guard to manage the path components stack. I have one non-blocking comment about the rest of the patch now.