-
Notifications
You must be signed in to change notification settings - Fork 412
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
Generated docs with Symbolgraph includes internal extensions #1291
Comments
Can you add a bit more detail on the code structure that's going wrong for you? If I do: class Fred {}
extension Fred {
func barney() {}
} ... then I don't see an extension. But If I change Jazzy is asking symbolgraph for everything it knows, then sorting out and reporting on the ACL implications at its level. I think this was mostly for feature parity with the SourceKit version, and maybe some special case to do with (ironically) protocol conformances. Debugging, the bug looks to be here where |
I suspect it's similar, the protocol conformances that I'm seeing are all of the form:
|
Thanks for looking into this so quickly! |
It looks like this issue is back. In our use case, we have an internal class where we create an extension with a public protocol. And this extension does show up in the generated documentation (not the class) Env:
I'm happy to create a new issue if preferred. |
Yes, open a new issue with your example & how you're driving jazzy. |
When using Jazzy to generate documentation with
--swift-build-tool symbolgraph
I'm finding that the output contains a number of extensions to module internal classes.I can see that the additional symbols are included in the output of
swift symbolgraph-extract
if I pass in-minimum-access-level private
, but excluded (as expected) with-minimum-access-level public
.This is clearly the explicit intended behaviour: https://github.com/realm/jazzy/blob/master/lib/jazzy/symbol_graph.rb#L57-L60 but I'm not sure what the reason behind this was?
If it fits in more broadly, I'd be happy to open a PR with a change that allows the
minimum-access-level
to be passed in as a build-tool-argument. It seems possible that there might have been a change in behaviour since Swift 5.3 that introduced this issue.The text was updated successfully, but these errors were encountered: