The MemoryBuffer loader is used by LLDB during debugging to import binary Swift
modules from .swift_ast sections. Modules imported from .swift_ast sections are
never produced from textual interfaces. By disabling resilience the expression
evaluator in the debugger can directly access private members.
rdar://79462915
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
The new flag will be used to track whether a borrow scope corresponds to
a source-level lexical scope. Here, the flag is just added to the
instruction and represented in textual and serialized SIL.
A type dependencies are used at deserialization to drop a protocol early
when a dependency is not deserializable. Dependencies on protocols via a
protocol composition were not taken into account. This lead to the
deserialization process failing later. Fix the serialization process to
write protocol dependencies too.
rdar://78631465
This makes sure that all analysis will get the `notifyAddedOrModifiedFunction` notifications.
This fixes a crash in CallerAnalysis, which relies that it's notified for all newly created functions.
This is related to following bug reports for cross-module-optimization:
https://bugs.swift.org/browse/SR-15048
rdar://81701218
Although I believe that there are more bugs involved which need to be fixed.
Unfortunately I don't have a test case for this fix.
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
We'd like to support factor initializers
for distributed actor types that are
synthesized by SILGen.
We already do something similar for
memberwise initializers for structs.
Thus, this patch generalizes that
concept into a new BodyKind for
AbstractFunctionDecls called
BodyKind::SILSynthesize.
In addition, to help differentiate the
kinds of AFDs that are SILSynthesized
into different families for SILGen to
recognize, we also have a new enum
SILSynthesizeKind to indicate whether it
is a memberwise init, etc.
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
7856f2d83d only partially skipped writing
out destructors when they were invalid, ie. it skipped writing the decl
itself but not the records common to all decls. This would cause any
records on the destructor to be applied on the next serialized decl.
Make sure to skip serializing anything to do with the destructor when
it's invalid and does not have a class context.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Designated types were removed from the constraint solver in #34315, but they are currently still represented in the AST and fully checked. This change removes them as completely as possible without breaking source compatibility (mainly with old swiftinterfaces) or changing the SwiftSyntax tree. Designated types are still parsed, but they are dropped immediately and a warning is diagnosed. During decl checking we also still check if the precedence group is really a designated type, but only so that we can diagnose a warning and fall back to DefaultPrecedence.
This change also fixes an apparent bug in the parser where we did not diagnose operator declarations that contained a `:` followed by a non-identifier token.
When looking up a conformance to Sendable fails, implicitly create a
"missing" builtin conformance. Such conformances allow type checking
to continue even in the presence of Sendable-related problems.
Diagnose these missing conformances when they are used in an actual
program, as part of availability checking for conformances and when we
are determining Sendability. This allows us to decide between an
error, a warning, and suppressing the diagnostic entirely without
affecting how the program is compiled. This is a step toward enabling
selective enforcement of Sendable.
Part of rdar://78269348.
The dependency scanner's cache persists across different queries and answering a subsequent query's module lookup with a module not in the query's search path is not correct.
For example, suppose we are looking for a Swift module `Foo` with a set of search paths `SP`.
And dependency scanner cache already contains a module `Foo`, for which we found an interface file at location `L`. If `L`∉`SP`, then we cannot re-use the cached entry because we’d be resolving the scanning query to a filesystem location that the current scanning context is not aware of.
Resolves rdar://81175942
Allowing errors is attempting to create a module regardless of any
potential failures, so do our best to continue rather than crash (even
if a corresponding build would then crash).
Instead of a new attribute `@completionHandlerAsync`, allow the use of
the existing `renamed` parameter of `@available` to specify the
asynchronous alternative of a synchronous function.
No errors will be output from invalid names as `@completionHandlerAsync`
had, but if a function is correctly matched then it will be used to
output warnings when using the synchronous function in an asynchronous
context (as before).
Resolves rdar://80612731
