The underlying C++ code expects a non-null `Instruction*` or `SILArgument*` pointer, and
most of the contextual information in a verifier error is derived from these arguments,
so it doesn't really make sense for the Swift level interface to present these arguments
as optional.
This reverts commit 6852bc9834.
In addition to the original change, this makes sure that C++ `std::string` and Swift `String` are given distinct score, in order to prevent ambiguity which was causing build failures in some projects.
rdar://158439395
A previous commit introduced the usage of buildContextManglingForSymbol
in buildContextDescriptorMangling, which was not quite correct, since
type nodes needed extra handling, which was done in the other version of
buildContextDescriptorMangling. This patch factors out the handling of
building context descriptors mangling from symbols, and updates both
call sites to use the new function instead.
rdar://165950673
There is an existing cache which is built when looking up
FieldDescriptors. collectAllConformances ignored this cache and would
parse every FieldDescriptor again. Use the existing cache mechanism.
rdar://166098516
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
This serves as the backing request for both InitAccessorPropertiesRequest
and MemberwiseInitPropertiesRequest, ensuring the former does not
care about the init accessor is included in the memberwise initializer.
Store the original VarDecl in the same map we use for tracking the
original wrapper var for property wrappers. This will allow us to
use the same logic to determine the original var for both.
rdar://163631865
Under certain circumstances the same symbol can be used for different implementations of the forwarders.
The forwarders themselves are already emitted with "internal" LLVM linkage, but some particularities in
the mapping from SILLinkage to LLVM linkage caused async function pointers to partial apply forwarders
to be emitted with linkonce_odr instead, which caused the wrong forwarder to be called at runtime, causing
unexpected behavior and crashes.
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
Add a note to missing explicit `Sendable` conformance warning
(produced by `-Wwarning ExplicitSendable`) and a fix-it with
a suggestion to suppress `Senable` conformance via `~Sendable`.
If the MemoryReader can provide a symbol for the context descriptor, use
that instead of building the mangle tree from metadata. This shouldn't
hurt other clients, and would have a few benefits for LLDB:
- Small but numerous memory reads can be expensive for LLDB, building
the mangle tree from a string should be much faster.
- For types with private discriminators, this allows LLDB to provide the
same private discriminator that's in DWARF and in the swiftmodule (as
opposed to using the memory address where the context descriptor lives
at). This means that these private types would have the same mangled
name in every run. LLDB persistently caches field descriptors by name,
but since private discriminators aren't guaranteed to have the same
mangled name over multiple runs, LLDB would often need to invalidate
its entire cache and rebuild it. Using the stable UUID would solve
that issue.
rdar://165950673
