Prevents a cycle where a general access to all top level decls lead the
deserialization to call ClangImporter which triggered more
deserialization. It crashed the compiler in a complex case so only
limiting what is deserialized should be enough to fix this for now.
rdar://problem/57118844
These include memberwise initializers for pointer properties and enum
case constructors for pointer payloads. In both cases, the pointer is
being immediately escaped, so don't allow the user to pass a temporary
pointer value.
Christopher Rogers' (good) work in 49fd5acbb2 caught places where
the Swift compiler was allowing a @class to resolve to a Swift class
even if that class had a conflicting Objective-C name, or wasn't
intended to be exposed to Objective-C at all. Unfortunately, this
broke source compatibility in projects where people were relying on
this. Restore that functionality, but only as a fallback; matching the
Objective-C name is better than matching the Swift name.
rdar://problem/56681046
Previously we only did this for factory methods, but there's no reason
why we can't do it for regular init methods too, and doing so
simplifies the signature of SwiftDeclConverter::importConstructor.
Also remove some indirection through helper functions in ClangAdapter.
These were more useful back when Swift looked directly at API notes
instead of relying on Clang turning them into attributes; now they're
just an extra hop for no reason.
The code does naive lookup of Swift types using the type name, but sometimes the Swift type we're looking for only has that name in its @objc attribute. This change makes the compiler exclude certain Swift declarations from matching even if the Swift name is the same (namely, not being available in Obj-C or having a mismatched `@objc` name) and continue to find the correct declaration without using lookup by name.
Fixes SR-4827
This is an amalgam of simplifications to the way VarDecls are checked
and assigned interface types.
First, remove TypeCheckPattern's ability to assign the interface and
contextual types for a given var decl. Instead, replace it with the
notion of a "naming pattern". This is the pattern that semantically
binds a given VarDecl into scope, and whose type will be used to compute
the interface type. Note that not all VarDecls have a naming pattern
because they may not be canonical.
Second, remove VarDecl's separate contextual type member, and force the
contextual type to be computed the way it always was: by mapping the
interface type into the parent decl context.
Third, introduce a catch-all diagnostic to properly handle the change in
the way that circularity checking occurs. This is also motivated by
TypeCheckPattern not being principled about which parts of the AST it
chooses to invalidate, especially the parent pattern and naming patterns
for a given VarDecl. Once VarDecls are invalidated along with their
parent patterns, a large amount of this diagnostic churn can disappear.
Unfortunately, if this isn't here, we will fail to catch a number of
obviously circular cases and fail to emit a diagnostic.
Since getSpecifier() now kicks off a request instead of always
returning what was previously set, we can't pass a ParamSpecifier
to the ParamDecl constructor anymore. Instead, callers either
call setSpecifier() if the ParamDecl is synthesized, or they
rely on the request, which can compute the specifier in three
specific cases:
- Ordinary parsed parameters get their specifier from the TypeRepr.
- The 'self' parameter's specifier is based on the self access kind.
- Accessor parameters are either the 'newValue' parameter of a
setter, or a cloned subscript parameter.
For closure parameters with inferred types, we still end up
calling setSpecifier() twice, once to set the initial defalut
value and a second time when applying the solution in the
case that we inferred an 'inout' specifier. In practice this
should not be a big problem because expression type checking
walks the AST in a pre-determined order anyway.
By requestifying the raw value accessor and pushing the semantic check
into IRGen, we are now partially validating enums that are
synthesized by the clang importer and deserialization - something that
we were not doing before. The previous check would only skip
the auto-incrementer step when this was the case. We now also skip the
uniqueness check.
Resolves rdar://56037318
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
At one point in the past we probably needed to set this explicitly,
but now it seems to be handled for us or derived somewhere.
No functionality change.
And similar for importFunctionParamsAndReturnType and
importAccessorParamsAndReturnType. In all cases the return type isn't
a FunctionType, and there's also a ParameterList out-parameter.
No functionality change.
A typedef might get imported as an alias for a bridged type (String)
or for the original type (NSString), and a few parts of the importer
need to account for this. Simplify this logic based on how it's used
today.
Computing the interface type of a typealias used to push validation forward and recompute the interface type on the fly. This was fragile and inconsistent with the way interface types are computed in the rest of the decls. Separate these two notions, and plumb through explicit interface type computations with the same "computeType" idiom. This will better allow us to identify the places where we have to force an interface type computation.
Also remove access to the underlying type loc. It's now just a cache location the underlying type request will use. Push a type repr accessor to the places that need it, and push the underlying type accessor for everywhere else. Getting the structural type is still preferred for pre-validated computations.
This required the resetting of a number of places where we were - in many cases tacitly - asking the question "does the interface type exist". This enables the removal of validateDeclForNameLookup
Removes duplicated logic from the implementations of
FileUnit::lookupValue, and simplifies the interface to
ModuleDecl::lookupValue, where everyone was passing an empty
(non-filtering) access path anyway /except/ during actual lookup from
source code. No functionality change.
Explicitly apply the std::move as the signature of the callee is:
void swift::Evaluator::cacheOutput<swift::ExtendedNominalRequest, _>(const Request &, swift::NominalTypeDecl *&&)
The second formal parameter here is a `swift::ClassDecl` which is a
subclass of NominalTypeDecl, however, the cast will construct a
`swift::NominalTypeDecl *`. This is a lvalue and cannot be bound to a
r-value reference. Explicitly construct the r-value reference via
`std::move`.
This memoizes the result, which is fine for all callers; the only
exception is open existential types where each new open existential
now explicitly gets a unique generic environment, allocated by
calling GenericEnvironment::getIncomplete().
Since we started saving the nominal in the .swiftmodule, changing the other
call-sites in ClangImporter to save the value means that we can rely on
the typeRepr being non-null except when the syntax tree was ill-formed.
