Revised for implicit internal: Add redundant internal and fileprivate analysis to go alongside redundant public analysis #1042
Conversation
Co-authored-by: Ian Leitch <ian@leitch.io>
This reverts commit 882e58d.
Fix the scanning logic for that, and update the tests to reflect that.
…can` results in no warnings
|
Lovely. Apparently some tests aren't passing here even though they passed on my machine. Stand by... |
This commit fixes false positive warnings where internal declarations were incorrectly flagged as "not used outside of file" when they were actually being used in test files via @testable import. This only appeared using the --bazel flag on github. Fix a linux-only warning. Also, handle @usableFromInline to avoid false positives. Updated bazel.json and linux-bazel.json to suppress 3 new Bazel-specific false positives. When Bazel builds modules independently, each module's index store doesn't capture cross-module usage, leading to false "unused" warnings. The baseline suppresses these known artifacts while preserving detection of genuine issues. Updated the build script to clean SwiftPM cache before build to prevent occasional CI failure.
|
@ileitch One thought I had - I'm concerned that this is opening up a bunch of new runtime flags. This one defines 2 new flags ( I don't know if you would be OK with changing an existing flag but what if we were to remove/deprecate |
…and adding test cases.
1 participant
Original Description from PR #976: It's useful to make your swift types be as private as possible, to encourage encapsulation. This improvement adds new checks for types that are fileprivate or (implicitly/explicitly) internal, and lets you know if they could be made more private then they are currently.
This new PR fixes a big gap in the previous PR where I had missed out on implicit internal declarations! This now works with implicit internal declarations, and fixes a bunch of false positives once that got enabled. A bunch of new test cases to cover all of these corner cases.
Second-most-recent commit, 35357b8, is just a bunch of changes to the periphery code base, cleaning up based on the results of
mise r scanwith the current codebase. So it might be easier to look at the diff of the commit just before that, so you don't have to get distracted by the trivial changes to accessibility.Update: OK that took some effort to clear the CI hurdles — see last commit, 9868cdd. Especially since scanning via bazel on my Mac produced very different warnings from the CI's logs. I left behind a hint as a comment in case somebody else wants to temporarily put in some debug output to see the USR of whatever symbols are causing warnings when scanning via Bazel.