Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
Framework authors may move a type along with its extensions from
a high-level framework to a low-level one. We should compare
alternative module names for them to check if they should be considered from
the same module to preserve ABI stability.
rdar://65889766
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.
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.
We can synthesize the default init() and the implicit deinit in a class in
any order, depending on the order of primary files and how that class was
used in other primary files.
Make sure that EmittedMembersRequest puts the destructor at the end with
all other synthesized members, so that we produce the same object file in
any case.
'-dump-parse' for the following code used to hit an assertion failure:
struct MyStruct {}
_ = { (val: MyStruct) in }
Because 'isNonEphemeral()' on 'val' parameter unintentionally causes
'InterfaceTypeRequest::evaluate()'. Since 'isNonEphemeral()' inference
based on the interface type is not possible after type checking, return
'false' unless 'hasInterfaceType()'
Also:
* Dump parameter list on 'EnumElementDecl' as well
* Adjust the position of 'range=...' in parameter list dumping
When a nominal type and its extensions coexist in the same module, mangling may
use the nominal type as the context for extension members. We should preserve this
mechanism for types marked as @_originallyDefinedIn to maintain ABI stability.
rdar://64538537
Now that the previous commits have removed the data dependencies on TypeLoc, remove the TypeLoc and replace it with a TypeRepr. This makes RequirementRepr a purely syntactic object once again.
```
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
The fact that a declaration has `@_show_in_interface` shouldn't be
used to decide whether something has underscored naming, which
is just one specific kind of check regarding naming only.
Move the check for this attribute out one level.
rdar://63120829
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
Previously, whenever name lookup returned two declarations with the same
name, we would compute the canonical type of each one as part of the
shadowing check.
The canonical type calculation is rather expensive for GenericFunctionTypes
since it requires constructing a GenericSignatureBuilder to canonicalize
type parameters that appear in the function's signature.
Instead, let's first shard all declarations that have the same name by
their generic signature. If two declarations have the same signature, only
then do we proceed to compute their canonical type.
Since computing a canonical GenericSignature is cheaper than computing a
canonical GenericFunctionType, this should speed up name lookup of
heavily-overloaded names, such as operators.
Fixes <rdar://problem/56800097>.
Allow a protocol requirement for a function or property to declare
a function builder. A witness to such a protocol requirement will
infer that function builder when all of the following are two:
* The witness does not explicitly adopt a function builder
* The witness is declared within the same context that conforms to the
protocol requirement (e.g., same extension or primary type declaration)
* The witness's body does not contain a "return" statement (since those
disable the function builder transform).
* [Typechecker] Emit a specialized diagnostic for redeclaration errors when the declaration is synthesized
* [Test] Update existing tests
* [Typechecker] Diagnose the original wrapped property instead of the nearest non-implicit decl context
* [Test] Update existing tests
* [Typechecker] Do not diagnose redeclarations when both declarations are implicit
* [Test] Update a AutoDiff test
For accessors: make `AbstractFunctionDecl::getDerivativeFunctionConfigurations`
resolve configurations from parent storage declaration `@differentiable`
attributes.
Fixes "no `@differentiable` attribute" non-differentiability error for accessors
whose parent storage declaration `@differentiable` attributes have not been
type-checked (e.g. because the storage declarations are in another file).
Add protocol requirement and class member storage declaration tests.
Resolves TF-1234.
Annotate the covered switches with `llvm_unreachable` to avoid the MSVC
warning which does not recognise the covered switches. This allows us
to avoid a spew of warnings.
In `AbstractFunctionDecl::getDerivativeFunctionConfigurations`, type-check
`@differentiable` attributes. This is important to populate derivative
configurations for original functions in other files.
Resolves TF-1271.
Exposes TF-1272: fix derivative configurations for cross-file `@derivative`
attributes. This is a more difficult issue.
