[APIGen] Account for access scopes of declarations

[zixu-w]

Correctly account for access scopes of declarations visited by APIGen:
Mark declarations with non-public access scopes as private SPIs.

Resolves rdar://159701853

[cyndyishida]

This change generally makes sense to me. A couple questions.

1. What happens if, or is it possible, for S/L/PF libraries to have public access level APIs? I assume so, but what is a resulting sdkdb info?

2. Why not record non-exported decls? Is it because that information may not be used or it can't actually ever be represented as SPI?

[zixu-w]

1. What happens if, or is it possible, for S/L/PF libraries to have public access level APIs? I assume so, but what is a resulting sdkdb info?

Private frameworks and the access scope keywords in Swift are orthogonal. S/L/PF libraries would definitely have declarations with public access scope. Access scope controls the visibility of declarations outside the Swift module, not the public/private in terms of access level. All APIs and SPIs should have public access scope. SPIs would also have a @_spi or @_spi_available attribute.

It's also possible for private frameworks to have public access level APIs (public not as in access scope, but in terms of public/private. e.g., a declaration without the @_spi attribute). And we would want to treat them as private. But that's a different issue that we should address in a separate change. This change only covers the access scope handling.

2. Why not record non-exported decls? Is it because that information may not be used or it can't actually ever be represented as SPI?

These decls couldn't ever be used as interfaces provided by the module, including API and SPI. From the documentation of isExposedToClients that I used for the filtering, non-exportable decls means there's no way to access the decl from outside the module (also see https://docs.swift.org/swift-book/documentation/the-swift-programming-language/accesscontrol/).

[cyndyishida]

It's also possible for private frameworks to have public access level APIs (public not as in access scope, but in terms of public/private. e.g., a declaration without the @_spi attribute). And we would want to treat them as private. But that's a different issue that we should address in a separate change. This change only covers the access scope handling.

This is precisely my question. what is the resulting sdkdb entry for this case & does it change with this patch independently of whether theres a better fix for this in a future patch.

These decls couldn't ever be used as interfaces provided by the module, including API and SPI. From the documentation of isExposedToClients that I used for the filtering, non-exportable decls means there's no way to access the decl from outside the module (also see https://docs.swift.org/swift-book/documentation/the-swift-programming-language/accesscontrol/).

I don't know that I fully understand the difference between exposed vs exported. e.g. inlined functions could be not-exported symbols but clients could still use it right?

[cyndyishida]

LGTM. Should the PR description/ultimate merged commit message be updated though?

[zixu-w]

@swift-ci please test

[zixu-w]

@swift-ci please test

[zixu-w]

@swift-ci please smoke test macOS

[zixu-w]

@swift-ci please test Windows