[ScanDependency] Do not use public/private swiftinterface in the same package

[cachemeifyoucan]

When scanning finds a dependency in the same package, do not load public/private swiftinterface since they do not have the package level decl to compile the current module. Always prefer package module (if enabled), or use binary module.

This also does some clean up to sync up the code path between implicit and explicit module finding path.

rdar://122356964

[cachemeifyoucan]

@swift-ci please smoke test

[elsh]

getPackageInterfacePathIfInSamePackage already checks package name, so return its value if non-null.

[cachemeifyoucan]

So that is a different interface file (package vs. public, double verification).

The test failure tells me the current approach doesn't quite work yet because how subInvocation handles package name. I am thinking through all the cases to see if I can find a better solution.

[cachemeifyoucan]

Note to reviewer. The current approach doesn't quite work because:
If package A imports a module from package B, package B interface still builds with package name B, even the parent is package A. So the check for if package name is the same as embedded will always return true.

I am thinking if the build should be something like: if the module building has a package name, the dependency will have a package name it is equal or no package name if not equal. That is not the same as the current behavior so I need to think through because on the other hand, we want the diagnostics about mis importing interface in the same package to work (which relies on the package name embedded in swiftmodule, which means the module needs to built with -package-name)

[cachemeifyoucan]

After some more thinking, I think the thing that is missing from this approach is that when you build a swift interface file, that action will always have -package-name option, but if it is building a public/private module, we should allow loading non-package interface. If the action is a main module compilation or a package module compilation (?), it should only allow binary module or package interface if within the same package.

[cachemeifyoucan]

@swift-ci please smoke test

[elsh]

This is not the behavior we want. The original diagnostics should still happen here.

[cachemeifyoucan]

So... this is tricky. The reason for the diagnostics do not happen is after the change, the private swiftinterface is not considered a valid dependency for the source, thus it is not doing an implicit module build to create a module that cannot be imported with the error.

You can still construct a case that trigger the warning but you have to produce the wrong module first before running the implicit build. That behavior is verified in test/Sema/accessibility_package_import_interface.swift

[cachemeifyoucan]

@swift-ci please smoke test macOS platform

[xymus]

LGTM

[elsh]

Where are these input types specified? In deps.json as in the test below?

[cachemeifyoucan]

This is the type of the input on the command-line, determined by file extension. The only time something can import public/private interface when in the same package is building a public/private interface from the same package, hence checking the input type.

[cachemeifyoucan]

@swift-ci please smoke test