The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
This allows a previously-working case of Objective-C forward-declaring
a type in a /different/ Swift module to continue working, as long as
the Swift context being compiled manages to import the other module
properly (including its generated header). This isn't really our
recommended pattern---that would be to @import the module in the
bridging header and forego the forward declaration---but it doesn't
cost much to keep it working. It's also a place where textual and
precompiled bridging headers behaved differently, because precompiled
ones are processed much earlier.
https://bugs.swift.org/browse/SR-3798
So when sorting, don't just jump directly to the Clang decl and get
its name, because there might not be a Clang decl; instead, use the
'objc' attribute if there is one and the protocol's base name if
not. We're not using ProtocolType::compareProtocols because we'd
rather not depend on knowing for sure which Clang module a protocol
lives in.
This wasn't caught until now because it required adopting a protocol
in Objective-C that itself adopted (directly or indirectly) at least
two protocols, at least one of which originally came from Swift.
rdar://problem/26232085
