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.
This change adds a new type of cache (cache by type descriptor) to the protocol conformance lookup system. This optimization is beneficial for generic types, where the
same conformance can be reused across different instantiations of the generic type.
Key changes:
- Add a `GetOrInsertManyScope` class to `ConcurrentReadableHashMap` for performing
multiple insertions under a single lock
- Add type descriptor-based caching for protocol conformances
- Add environment variables for controlling and debugging the conformance cache
- Add tests to verify the behavior of the conformance cache
- Fix for https://github.com/swiftlang/swift/issues/82889
The implementation is controlled by the `SWIFT_DEBUG_ENABLE_CACHE_PROTOCOL_CONFORMANCES_BY_TYPE_DESCRIPTOR`
environment variable, which is enabled by default.
This reapplies https://github.com/swiftlang/swift/pull/82818 after it's been reverted in https://github.com/swiftlang/swift/pull/83770.
This change adds a new type of cache (cache by type descriptor) to the protocol conformance lookup system. This optimization is beneficial for generic types, where the
same conformance can be reused across different instantiations of the generic type.
Key changes:
- Add a `GetOrInsertManyScope` class to `ConcurrentReadableHashMap` for performing
multiple insertions under a single lock
- Add type descriptor-based caching for protocol conformances
- Add environment variables for controlling and debugging the conformance cache
- Add tests to verify the behavior of the conformance cache
- Fix for https://github.com/swiftlang/swift/issues/82889
The implementation is controlled by the `SWIFT_DEBUG_ENABLE_CACHE_PROTOCOL_CONFORMANCES_BY_TYPE_DESCRIPTOR`
environment variable, which is enabled by default.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
resolveWitnessViaLookup() was only called from one place and didn't
need to force anything at all, and resolveSingleWitness() now only
forces the type witnesses actually referenced by the requirement.
An old crasher test case that was considered "fixed" when we started
to diagnose it now type checks correctly.
`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 commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
See the comment at the top of ConcreteContraction.cpp for a detailed explanation.
This can be turned off with the -disable-requirement-machine-concrete-contraction
pass, mostly meant for testing. A few tests now run with this pass both enabled
and disabled, to exercise code paths which are otherwise trivially avoided by
concrete contraction.
Fixes rdar://problem/88135912.
If we find multiple conformances for the same protocol, we generate a
warning. This works fine for Swift types, but for Objective-C types
it's possible that while generating the warning we might find that the
type description is NULL.
Fix by using swift_getTypeName().
rdar://86368350
It looks like commit 46580d43fc70d migrated the flags from llvm::cl to
OptTable. As a result, the flag behaviour changed. Commit
e29e30b1397f3e50f3487491f8a77ae08e4e3471 from 2019 went through and
changed the llvm tests to consistently use the double-dash for long
options so it was undetected.
With this info, I'm just going to go ahead and fix these tests cases to
get them going again.
Apparently it's necessary to list all the files used in %target-run, otherwise
when we're running the tests remotely on a device, they might not be copied.
rdar://80283113
Added a test that builds two dynamic libraries and sets up a redundant protocol
conformance (we use dynamic libraries because the compiler will normally reject
redundant conformances), then checks that when we rely on it, we get a warning
message.
Our LLVM backend is supposed to have a build-time optimization where we
hash the IR and do not proceed with LLVM code generation if the hash
matches the one we last used to emit any products. This has never quite
worked for a variety of reasons - we fixed a number of those reasons in
https://github.com/apple/swift/pull/31106 but this test remained flaky
for its entire lifetime.
It's really not worth all the trouble to keep investigating this, so I'm
removing this test.
rdar://77654695
This was disabled due to timing issues on the bots. Now that everything
is on APFS/ext/NTFS, we should have the resolution necessary to turn
this back on.
rdar://62338337
Formal access alone does not take into account @testable imports of
internal types. This prevented otherwise valid conditional conformances
of these types from compiling.
rdar://72875683
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
EmittedMembersRequest needs a stable order for synthesized members
to ensure that vtable layout is computed consistently across frontend
jobs. This used to use the mangled name as the sort key.
However, the mangling includes the type of all outer contexts, and if
an outer type is a closure, we would need to compute the type of the
closure. Computing the type of a closure might require type checking
its body though, which would in turn type check the local class, which
would invoke EmittedMembersRequest, introducing a cycle.
Instead, let's use the DeclName and string-ified type as the sort key.
This is simpler to compute than th mangled name, and breaks the cycle.
Fixes <rdar://problem/67842221>.
Otherwise, we would generate inconsistent vtable layouts for classes
with static properties that have attached wrappers. The reason is that
we normally force synthesis of the backing storage and storage wrapper
for each instance property wrapper as part of computing the lowered
stored properties.
However, there was no such forcing for static properties. But since a
static stored property (with an attached wrapper or otherwise) must be
'final', the real fix is to just ensure that the 'final' bit propagates
to the storage wrapper as well.
The backing storage property was already always final, so the issue
did not arise there.
Fixes <rdar://problem/59522703>, <https://bugs.swift.org/browse/SR-12429>.
