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.
