In derivatives of loops, no longer allocate boxes for indirect case payloads. Instead, use a custom pullback context in the runtime which contains a bump-pointer allocator.
When a function contains a differentiated loop, the closure context is a `Builtin.NativeObject`, which contains a `swift::AutoDiffLinearMapContext` and a tail-allocated top-level linear map struct (which represents the linear map struct that was previously directly partial-applied into the pullback). In branching trace enums, the payloads of previously indirect cases will be allocated by `swift::AutoDiffLinearMapContext::allocate` and stored as a `Builtin.RawPointer`.
Rather than performing actor isolation checking as part of
"miscellaneous" diagnostics on an expression, do it on the whole
function at once. This should not change behavior by itself.
When a completion handler parameter has a selector piece that ends with
"WithCompletion(Handler)", prepend the text before that suffix to the
base name or previous argument label, as appropriate. This ensures that
we don't lose information from the name, particularly with delegate names.
We used to diagnose references to unavailable declarations in
two places:
- inside Exprs, right after type checking the expression
- inside TypeReprs, from resolveType()
In broad terms, resolveType() is called with TypeReprs
stored inside both Stmts and Decls.
To handle the first case, I added a new overload of
diagAvailability() that takes a Stmt, to be called from
typeCheckStmt(). This doesn't actually walk into any Exprs
stored inside the statement; this means it only walks
Patterns and such.
For the second case, a new DeclAvailabilityChecker is
now defined in TypeCheckAccess.cpp. It's structure is
analogous to the other three walkers there:
- AccessControlChecker
- UsableFromInlineChecker
- ExportabilityChecker
The new implementation of availability checking for types
introduces a lot more code than the old online logic
it replaces. However, I hope to consolidate some of the
code duplication among the four checkers that are defined
in TypeCheckAccess.cpp, and do some other cleanups that
will make the benefit of the new approach apparent.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
Enforce the actor-isolation constraint that an actor-isolated member
(e.g., a non-async instance method or an instance property) cannot be
used to conform to a protocol requirement.
Implement a basic set of isolation rules for actors, which includes:
* Asynchronous actor methods can be invoked on any actor instance.
* All mutable instance properties and synchronous instance methods are
only accessible via "self" or "super" within the context of the actor.
* Closures defined within an actor method are considered to be a
context distinct from the actor itself, are therefore are subject to
the same restrictions as above.
Together with a scheduler that ensures that asynchronous invocations
for a particular actor are serialized (at least up until they hit a
suspension point or return), this serves to isolate the actor's
instance state in a shallow manner: references to shared mutable state
can still be passed among actors, code can access global variables,
and one can still form and pass around unsafe pointers.
Pair this with some basic checking within actor contexts that
identifies a few obvious potential kinds of race conditions:
* References to captured mutable local variables from within closures.
* References to mutable global and static/class variables.
The latter are warnings, for which we currently don't have a great
suppression mechanism. That, and a lot of tuning, are still to come.
* [AST] Add 'FloatingPoint' known protocol kind
* [Sema] Emit a diagnostic for comparisons with '.nan' instead of using '.isNan'
* [Sema] Update '.nan' comparison diagnostic wording
* [Sema] Explicitly check for either arguments to be '.nan' and tweak a comment
* [Test] Tweak some comments
* [Diagnostic] Change 'isNan' to 'isNaN'
* [Sema] Fix a bug where firstArg was checked twice for FloatingPoint conformance and update some comments
* [Test] Fix comments in test file
* [NFC] Add a new 'isStandardComparisonOperator' method to 'Identifier' and use it in ConstraintSystem
* [NFC] Reuse argument decl extraction code and switch over to the new 'isStandardComparisonOperator' method
* [NFC] Update conformsToKnownProtocol to accept DeclContext and use it to check for FloatingPoint conformance
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
If we're matching the trailing closure at the end but haven't seen any
mismatches yet, consider the trailing closure to be a mismatch.
This function probably needs to be rewritten in terms of
matchCallArguments(), because it is performing an incorrect
approximation of label matching that doesn't work for multiple
trailing closures.
The VDUC was missing a class of AST nodes that can bind variables:
patterns in switch statements. For these, it was falling back to
requesting a simple replacement of the bound variable name with _. But
for patterns, this means there's a two-step dance the user has to go
through where the first fixit does this:
.pattern(let x) -> .pattern(let _)
Then a second round of compilation would emit a fixit to do this:
.pattern(let _) -> .pattern(_)
Instead, detect "simple" variable bindings - for now, variable patterns
that are immediately preceded by a `let` or `var` binding pattern - and
collapse two steps into one.
Resolves rdar://47240768
VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
This change makes:
* #file compatible with #fileID in “Swift 6 mode”
* #file compatible with #filePath and #fileID in Swift 5 mode
* #file in Swift 5 mode code compatible with #file in “Swift 6 mode” code
This should keep anyone from seeing XCTAssert-wrapping noise until they adopt “Swift 6 mode” (whatever version that ends up actually being).
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
```
class Generic<T> {
@objc dynamic func method() {}
}
extension Generic {
@_dynamicReplacement(for:method())
func replacement() {}
}
```
The standard mechanism of using Objective-C categories for dynamically
replacing @objc methods in generic classes does not work.
Instead we mark the native entry point as replaceable.
Because this affects all @objc methods in generic classes (whether there
is a replacement or not) by making the native entry point
`[dynamically_replaceable]` (regardless of optimization mode) we guard this by
the -enable-implicit-dynamic flag because we are late in the release cycle.
* Replace isNativeDynamic and isObjcDynamic by calls to shouldUse*Dispatch and
shouldUse*Replacement
This disambiguates between which dispatch method we should use at call
sites and how these methods should implement dynamic function
replacement.
* Don't emit the method entry for @_dynamicReplacement(for:) of generic class
methods
There is not way to call this entry point since we can't generate an
objective-c category for generic classes.
rdar://63679357
Reverse the polarity of the "checked in context" bit for ClosureExpr
to "separately checked", which simplifies the AST walker logic (to
"should we walk separately type-checked closure bodies?") and
eliminates single-expression closures as a separate case to consider.
Rather than using various "applied function builder" and "is single
expression body" checks to determine whether a closure was
type-checked in its enclosing expression, record in the closure
expression whether it actually *was* type-checked as part of its
enclosing expression.
The parser used to rewrite
if let x: T
into
if let x: T?
This transformation is correct at face value, but relied on being able
to construct TypeReprs with bogus source locations. Instead of having
the parser kick semantic analysis into shape, let's perform this
reinterpretation when we resolve if-let patterns in statement
conditions.
Register DynamicSubscriptExpr's index expression
as a call argument in MiscDiagnostics to avoid it
being diagnosed as a single element labelled tuple.
Resolves SR-12799.
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
