Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
When a Swift function shadows a clang function of the same name, the
assumption was that Swift code would refer only to the Swift one.
However, if the Swift function is `@usableFromInline internal` it can be
called only from the local module and inlined automatically in other
clients. Outside of that module, sources see only the clang function, so
their inlinable code calls only the clang function and ignores the Swift
one. This configuration passed type checking but it could crash the
compiler at inlining the call as the compiler couldn't see the clang
function.
Let's update the deserialization logic to support inlined calls to the
shadowed or the shadower. Typical shadowing is already handled by the
custom deserialization cross-reference filtering logic which looks for
the defining module, scope and whether it's a Swift or clang decl. We
can disable the lookup shadowing logic and rely only on the
deserialization filtering.
rdar://146320871
https://github.com/swiftlang/swift/issues/79801
