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.
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.
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.
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.
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.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
...even if the base decl isn't.
This isn't normally possible, but it can come up when an imported type
is import-as-member'd onto an internal Swift declaration. This isn't
even such an unreasonable thing to do, since internal Swift
declarations are exposed in the generated header for an app.
rdar://problem/43312660
This patch removes the need for Request objects to provide a default
cycle-breaking value, instead opting to return llvm::Expected so clients
must handle a cycle failure explicitly.
Currently, all clients do the 'default' behavior, but this opens the
possibility for future requests to handle failures explicitly.
There's already a field for this in GenericContext, which ProtocolDecl
indirectly inherits. Protocols may have slightly different treatment
of their where-clauses, but not enough to justify a separate field.
No functionality change.
This is mostly NFC; the output of the api-digester test changed because
the interface type of an enum element now has parentheses around the
'Self' parameter type. This is more consistent with everything else
(and in the future, all function types will have "parentheses").
The verifier asserts that declarations whose interface type contains an error
are invalid, so let's just mark them invalid when we set the interface type,
instead of needlessly duplicating this logic all over the declaration checker.
This allows us to dump it in the generated interface, though it's
still not syntax-highlighted. This is necessary for textual module
interfaces, but it's also just a longstanding request for Xcode's
"Generated Interface" / "Jump to Definition" feature.
rdar://problem/18675831
Use the declaration-based name lookup facilities to re-implement
ProtocolDecl::getInheritedProtocols(), rather than dynamically selecting
between the requirement signature and the inherited types. This reduces
dependencies for this computation down to basic name lookup (no semantic
analysis) and gives us a stable result.
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
Introduce a request for ExtensionDecl::getExtendedNominal() that
uses TypeRepr-based resolution to find the extended nominal
type declaration without going through type resolution.
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
Introduce three new requests for name lookup operations that avoid performing
type checking/semantic analysis. They work using syntactic information
(e.g., TypeReprs) and AST-level name lookup operations that will (eventually)
avoid and calls back into type checking. The new requests are:
* Retrieve the superclass declaration of a protocol or class declaration. Use
this request for ClassDecl::getSuperclassDecl() and
ProtocolDecl::getSuperclassDecl().
* Retrieve the types “directly referenced” by a particular location in
an inheritance clause. This query is based on looking at the TypeReprs
and performing fairly-minimal lookup, so it does not involve any Type
computations.
* Retrieve the types “directly referenced” by the underlying type of
a typealias. This query allows us to desugar a typealias without forming
a type.
Along with these is a core operation to transform a set of TypeDecl*s
into a set of NominalTypeDecl*s, looking through typealiases, and
without involving Type at all. The superclass-decl request does this
to find a ClassDecl; other requests will eventually do this to (e.g.)
find all of the protocols mentioned in an inheritance clause.
In an upcoming patch we're going to start calling computeType() on
constructors and destructors parsed outside type context, so let's
just bail out if we're not in type context, instead of crashing.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
