Without this when constructing an InstModCallback it is hard to distinguish
which closure is meant for which operation when passed to the constructor of
InstModCallback (if this was in Swift, we could use argument labels, but we do
not have such things in c++).
This new value type sort of formulation makes it unambiguous which callback is
used for what when constructing one of these.
I recently have been running into the issue that many of these APIs perform the
deletion operation themselves and notify the caller it is going to delete
instead of allowing the caller to specify how the instruction is deleted. This
causes interesting semantic issues (see the loop in deleteInstruction I
simplified) and breaks composition since many parts of the optimizer use
InstModCallbacks for this purpose.
To fix this, I added a notify will be deleted construct to InstModCallback. In a
similar way to the rest of it, if the notify is not set, we do not call any code
implying that we should have good predictable performance in loops since we will
always skip the function call.
I also changed InstModCallback::deleteInst() to notify before deleting so we
have a default safe behavior. All previous use sites of this API do not care
about being notified and the only new use sites of this API are in
InstructionDeleter that perform special notification behavior (it notifies for
certain sets of instructions it is going to delete before it deletes any of
them). To work around this, I added a bool to deleteInst to control this
behavior and defaulted to notifying. This should ensure that all other use sites
still compose correctly.
Not-filtering solutions causes unacceptable slownesses in some cases.
For now, filter solutions as normal typechecking does to restore the
performance.
rdar://76714968
* [SR-13929][AutoDiff]: Enable [ossa] for Differentiation/Thunk.cpp:getOrCreateSubsetParametersThunkForLinearMap and promoteCurryThunkApplicationToDifferentiableFunction
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
Also, do this for the initial slab for the task's allocator itself.
This avoids memory allocations for async-lets.
In case the async-task's memory demand does not exceed the initial slab size, it is now completely malloc-free.
The refcount bits of an async-let task are initialized to "immortal" so that ARC operations don't have an effect on the task.
This patch restructures how we emit the effect errors for missing
awaits. As we're traversing the expressions, we collect all of the
locations where a missing await is, and metadata about the reason for
the error, as well as the "anchor".
The anchor is where the await should actually be placed in the
expression to fix things. The error is emitted for the whole
sub-expression instead of for the exact synchronization/call-site of the
async function. This avoids the erroneous message for
```
_ = 32 + asyncFunc()
```
The old behaviour was to put the `await` between the `+` operator and
the call to `asyncFunc()`, but this is not a valid place to put effects.
Note; this issue is also present in the fix-it for `try` insertions and
also needs to be fixed. Instead, the anchor points between the
assignment expression and 32, labelling the whole right-side of the
assignment as being the asynchronous function. We emit notes for each
uncovered async point in the entire expression though, so that someone
can see why the expression is async.
Actor inheritance was removed in the second revision of SE-0306. Remove
the ability to inherit actors.
Note that this doesn't fully eliminate all vestigates of inheritance
from actors. There are simplifications that need to be performed
still, e.g., there's no need to distinguish
designated/convenience/required initializers. That will follow.
This changes how ReflectionContext reads machO reflection sections by reading them individually instead of as one big memory block spanning from the first to the last section (and including whatever else is in between). This change will enable an optimization on LLDB's side where, if we're reading read-only data, we read from the file-cache instead of the child process, which should speed up debugging when working with remote processes.
In theory we could map opened archetypes per module because opened archetypes _should_ be unique across the module.
But currently in some rare cases SILGen re-uses the same opened archetype in multiple functions.
The fix is to add the SILFunction to the map's key.
That also requires that we update the map whenever instructions are moved from one function to another.
This fixes a compiler crash.
rdar://76916931
Add a feature for this new attribute, and make sure we use the feature
guard for functions that use it, e.g., the new `async`.
Finishes rdar://76927008.
In case the compiler is used with concurrency features enabled (by-default or otherwise), and an older SDK is used which does not include the `_Concurrency` module, do not load this module implicitly. Instead, emit a diagnostic indicating that no such module is found.
rdar://76967260
SWIFT_CLASS_IS_SWIFT_MASK is optionally defined to a global variable _swift_classIsSwiftMask, which allows the runtime to choose the appropriate mask when running on OS versions earlier than macOS 10.14.4. This is no longer a supported target for newly built runtimes (Swift apps built with such a target will embed a copy of the back deployment runtime, which is separate) and this global is no longer useful. Instead, unconditionally define SWIFT_CLASS_IS_SWIFT_MASK to 2 on Apple platforms, which is the correct value for current OS versions.
rdar://48413153
