Parsed declarations would create an untyped 'self' parameter;
synthesized, imported and deserialized declarations would get a
typed one.
In reality the type, if any, depends completely on the properties
of the function in question, so we can just lazily create the
'self' parameter when needed.
If the function already has a type, we give it a type right there;
otherwise, we check if a 'self' was already created when we
compute a function's type and set the type of 'self' then.
Before this patch, we used to define tooling-specific diagnostics. With adding more
checking logics, we found this mechanism hard to extend. This patch
eliminates the home-made diagnostics model to use the one from compiler, which provides
several benefits: less boiler-templates, better integration with DiagnosticConsumer,
and easy ordering of detected issues.
If all of the solutions in the set have a single fix, which points
to the common anchor, attempt to diagnose the failure as an
ambiguity with a list of candidates and their related problems as notes.
Having richer message like that helps to understand why something is
ambiguous e.g. if there are two overloads, one requires conformance
to some protocol and another has a same-type requirement on some type,
but neither matched exactly, having both candidates in the diagnostic
message with associated errors, instead of simplify pointing to related
declarations, helps tremendously.
SE-0155 makes an empty associated value list in an enum element
declaration illegal. Warn about this in legacy Swift mode, and reject
it otherwise. This offers two fixes:
1) Remove the empty associated value list
2) Insert a 'Void' associated value
This allows an elegant design in which we can still allocate RawSyntax
nodes using a bump allocator but are able to automatically free that
buffer once the last RawSyntax node within that buffer is freed.
This also resolves a memory leak of RawSyntax nodes that was caused by
ParserUnit not freeing its underlying ASTContext.
Rather than using RequirementRequest::visitRequirements() for its side
effects, then reading from the TypeLocs left behind, start eliminating
TypeLoc-based APIs so we pass Type and TypeRepr separately.
Add some utilities to dig into a possibly-null RequirementRepr* and dig
out the appropriate TypeReprs.
Introduce a new form of request that produces the ith Requirement of the
where clause of a given entity, which could be a protocol, associated type,
or anything with generic parameters. The requirement can be evaluated
at any type resolution stage; the “interface” type stage will be cached
in the existing RequirementReprs.
Fixes SR-8119 / rdar://problem/41498944.
Move the checking of generic parameter inheritance clauses into the
DeclChecker, getting it out of signature computation and out of the
TypeChecker instance.
Extend the inputs to InheritedTypeRequest, SuperclassTypeRequest, and
EnumRawTypeRequest to also take a TypeResolutionStage, describing what
level of type checking is required. The GenericSignatureBuilder relies
only on structural information, while other clients care about the
full interface type.
Only the full interface type will be cached, and the contextual type
(if requested) will depend on that.
I needed this for materializeForSet remission, but it makes inherited
variadic initializers work, too.
I tried to make this a reasonable starting point for a real language
feature. Here's what's still missing:
- syntax
- semantic restrictions to ensure that the expression isn't written in
invalid places or arbitrarily converted
- SILGen support for expansions that aren't the only variadic argument
rdar://16331406
Previously, TBDGen skipped emitting lazy initializers for globals that
appeared in any file with an entry point. This breaks, however on files
that have an NSApplicationMain/UIApplicationMain class in them, where
the entry point is synthesized but top-level globals are not locally
scoped. This change re-uses SILGen's check and only skips variable
declarations that appear at top level in a script mode file.
Resolves rdar://43549749
In-place initialization means the class has a symbol we can reference
from the category, so there's nothing to do on the IRGen side.
For JIT mode, we just need to realize the class metadata by calling an
accessor instead of directly referencing the symbol though.
Introduce an enum to describe the “stage” of type resolution that should
be performed, which is a notion that loosely exists within the type
checker already. Encapsulate the notion of a stage + the DeclContext
in which a type-check occurs into a new TypeResolution class, which
will replace the current GenericTypeResolver hierarchy.
Make sure the implementation can handle a key path with zero components by removing inappropriate assumptions that the number of components is always non-empty. Identity key paths also need some special behavior:
- Appending an identity key path should be an identity operation for the other operand
- Identity key paths have a `MemoryLayout.offset(of:)` zero
- Identity key paths interop with KVC as key paths to `@"self"`
To be able to exercise and test this behavior, add a `Builtin.identityKeyPath()` function and `WritableKeyPath._identity` accessor in lieu of finalized syntax.
The only real bug here is that we were looking specifically for `apply`
instructions, so we failed to diagnose `try_apply` calls to mutating
throwing functions on immutable existentials. Fixing this is a
source-compatibility break, but it's clearly in the "obvious bug" category
rather than something we need to emulate. (I found this bug because DI
stopped diagnosing a modification of a property of a `let` existential
when it started being done with `modify`, which of course is called with
`begin_apply`.)
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
