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.
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.
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.
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.
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.
