When `MemberImportVisibility` is enabled and a declaration from a cross import
overlay is diagnosed because it has not been imported, suggest imports of the
declaring and bystanding modules instead of the cross import overlay module
(which is an implementation detail).
Resolves rdar://149307959.
Cross-import overlays are imported automatically if the declaring
module and the bystanders modules are also imported. In theory,
one could import the declaring module and bystanders without using
them and use only the overlay in API. Let’s make sure we track these
indirect uses to avoid superfluous warning.
rdar://129779460
Add support for access-level on imports and `@_spiOnly imports` to cross
import overlays. The overlay inherits the most restrictive import
access-level of the declaring module and the bystander module.
rdar://129606112
In some cases this import may be superfluous as it's also
`@_exported` imported by the overlay. However, when the overlay
is hidden and the import not printed, the import can go entierly
missing.
Teach dependency scanner to pass cross import overlay file to
swift-frontend for main module compilation. This allows swift-frontend
not to repeat the file system search for overlay files when loading
modules.
This also fixes the issue when caching is enabled, the cross import
doesn't work when the first module is a clang module because the module
built with caching using clang include tree does not preserve
DefinitionLoc which is used to inferred the modulemap location for cross
import overlay search.
rdar://127844120
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
This normalizes the path so that we always have the mapping in normal
form. This fixes a bug in the cross-module import tracing, allowing us
to finally enable the test on Windows.
In the Windows VS 2017 CI machines, the path for certain tests end up
being very long. rewrite-module-triples.py was aware and was using
extended length paths for the copy and remove operations in Windows
but it was not using it for the os.walk invocation, so when a folder
that was longer than MAX_PATH was encountered, the walk stopped
drilling into it, missing some module-triple-here substitutions and
making some test fail.
The changes remove the special treatment of the copy and remove
operations and move it into os.walk, which carries the prefix to
every path.
This should fix the problems seen in the SourceKit test in the
Windows VS 2017 machine:
- SourceKit/InterfaceGen/gen_swift_module_cross_import_common.swift
- SourceKit/DocSupport/doc_cross_import_common.swift
- SourceKit/CursorInfo/cursor_info_cross_import_common_case.swift
PD: Misc/stats_dir_profiler.swift is something else. It seems as if
an glob was not being expanded by lit for some reason.
Unloaded implicit imports (e.g. the `-import-module` flag) will now be processed by import resolution, and will be fully validated and cross-imported. Preloaded imports, like the standard library import, are still not run through full import resolution, but this is a definite improvement over the status quo.
This also folds `-import-underlying-module` and `@_exported import <ParentModule>` into a single code path, slightly changing the diagnostic for a failed overlay-style underlying module import.
If a clang module declares a cross-import overlay, but it also has a traditional overlay, we want the cross-import overlay to be registered with the SourceFile as sitting atop the traditional overlay. Otherwise module-qualified name lookups will bypass the cross-import overlay.
Fixes rdar://62139656.
The path that the tests are using here are extremely long, and can
easily exceed the 261 character limit on Windows. Apply some
workarounds to support long paths.
It turns out that, if you pull in any nontrivial module, there are thousands of submodules and none of them could possibly have a cross-import overlay. Avoid evaluating them.
These are mostly harmless, except that they make the two module names synonymous in qualified lookup. A hard error seems too aggressive for something that could easily be caused by uncoordinated changes to two modules, so warn instead.
