While the use of a local property from within its own accessors is a
bit dubious, Swift 3 only warned on it, so model the existing lookup
behavior in the scope map.
The scope map relies fairly deeply on having reasonable source ranges
for AST nodes. Fix the construction and query of source ranges in a
few places throughout the parser and AST to provide stronger
invariants.
Semantic analysis produces implicit accessors that can show up before initializers (e.g., for initializers), and it’s reasonable for ill-formed code to do this as well, so be more tolerant of ordering issues here.
ExprHandle is a relic from a horrible time when expressions made their
way into the type system via default arguments. It's been unnecessary
for a long time, so get rid of it.
We were optimizing away unused pattern binding initializer contexts in
both the parser and in semantic analysis, which led to a
somewhat-unpredictable set of DeclContexts in the AST. Normalize
everything by always creating these contexts.
Now that SILFunctions no longer reference a GenericParamList, we
don't need to de-serialize cross-module references to archetypes
anymore.
This was the last remaining usage of AllArchetypes, so we can
finally rip it out.
This patch is rather large, since it was hard to make this change
incrementally, but most of the changes are mechanical.
Now that we have a lighter-weight data structure in the AST for mapping
interface types to archetypes and vice versa, use that in SIL instead of
a GenericParamList.
This means that when serializing a SILFunction body, we no longer need to
serialize references to archetypes from other modules.
Several methods used for forming substitutions can now be moved from
GenericParamList to GenericEnvironment.
Also, GenericParamList::cloneWithOuterParameters() and
GenericParamList::getEmpty() can now go away, since they were only used
when SILGen-ing witness thunks.
Finally, when printing generic parameters with identical names, the
SIL printer used to number them from highest depth to lowest, by
walking generic parameter lists starting with the innermost one.
Now, ambiguous generic parameters are numbered from lowest depth
to highest, by walking the generic signature, which means test
output in one of the SILGen tests has changed.
A GenericEnvironment stores the mapping between GenericTypeParamTypes
and context archetypes (or eventually, concrete types, once we allow
extensions to constrain a generic parameter to a concrete type).
The goals here are two-fold:
- Eliminate the GenericTypeParamDecl::getArchetype() method, and
always use mapTypeIntoContext() instead
- Replace SILFunction::ContextGenericParams with a GenericEnvironment
This patch adds the new data type as well as serializer and AST
verifier support. but nothing else uses it yet.
Note that GenericSignature::get() now asserts if there are no
generic parameters, instead of returning null. This requires a
few tweaks here and there.
Rather than having Sema provide a default implementation of
Error._code when needed, introduce a runtime function to extract the
default code, so that we can provide a default implementation via a
protocol extension in the standard library.
This is the first, and most trivial, usage of the new
GenericSignature::getSubstitutions() method.
Note that getForwardingSubstitutions() now takes a
GenericSignature, which is slightly awkward.
However, this is in line with our goal of 'hollowing out'
GenericParamList by removing knowledge of the finalized
generic requirements.
Also, there is now a new getForwardingSubstitutionMap()
function, which returns an interface type substitution
mapping. This is used in the new getForwardingSubstitutions()
implementation, and all also be used elsewhere later.
Finally, in the SILFunction we now cache the forwarding
substitutions, instead of re-computing them every time.
I doubt this makes a big difference in performance, but
it's a simple enhancement and every little bit helps.
Simplify e.g., ASTContext::getBridgedToObjC(), which no longer needs
the optional return.
Eliminate the now-unused constraint kind for checking bridging to
Objective-C.
This was causing issues where the compiler rejected overrides of
imported members as being non-ObjC-compatible, even though the type
was exactly the same as what the Clang importer was using.
https://bugs.swift.org/browse/SR-2344
- Make sure VarDecls have an associated TypeLoc, like ParamDecls do, then use it for printing the VarDecl's type.
This is done by moving ParamDecl's TypeLoc up to the VarDecl.
This is useful for being able to display the parameter names of function types embedded in VarDecls.
- Use the result TypeLoc of functions for printing. This enables printing parameter names of function types embedded in return types.
- Make sure to annotate attributes while they are printed.
Previously, if a generic type had a stored property with
a generic type and an initializer expression, we would
emit the expression directly in the body of each designated
initializer.
This is a problem if the designated initializer is defined
within an extension (even in the same source file), because
extensions have a different set of generic parameters and
archetypes.
Also, we've had bugs in the past where emitting an
expression multiple times didn't work properly. While these
might currently all be fixed, this is a tricky case to test
and it would be best to avoid it.
Fix both problems by emitting the initializer expression
inside its own function at the SIL level, and call the
initializer function from each designated initializer.
I'm using the existing 'variable initializer' mangling for this;
it doesn't seem to be used for anything else right now.
Currently, the default memberwise initializer does not use
this, because the machinery for emitting it is somewhat
duplicated and separate from the initializer expressions in
user-defined constructors. I'll clean this up in an upcoming
patch.
Fixes <https://bugs.swift.org/browse/SR-488>.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
(in preparation for the private/fileprivate split)
An "access scope" is the outermost DeclContext where a particular
declaration may be referenced: for a 'fileprivate' declaration it's
the enclosing file, and for an 'internal' declaration it's the module.
'public' corresponds to a scope of "everything", represented by a null
DeclContext.
This model extends naturally to the (not-yet-implemented) SE-0025
notion of 'private', where the access scope is a declaration's
immediately enclosing DeclContext.
Complicating this model is the revised rules that allow, e.g., a public
declaration to be declared within an internal type. The access scope
for this declaration is still just the module, not "everything".
This commit reworks formal access control checking in terms of this
model, including tightening up some of the handling for '@testable'.
This implements the rule that you must be able to access a declaration's
type everywhere you can reference the declaration.
This was not intended to change compiler behavior, but in practice it
has made cross-file dependency tracking a bit more conservative
(unnecessarily), caught a mistake in diagnosing access violations,
and fixed a fuzzer-based crasher (see test changes).
Progress on SE-0025 ('private' and 'fileprivate')
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
In Swift, default arguments are associated with a function or
initializer's declaration---not with its type. This was not always the
case, and TupleType's ability to store a default argument kind is a
messy holdover from those dark times.
Eliminate the default argument kind from TupleType, which involves
migrating a few more clients over to declaration-centric handling of
default arguments. Doing so is usually a bug-fix anyway: without the
declaration, one didn't really have
The SILGen test changes are due to a name-mangling fix that fell out
of this change: a tuple type is mangled differently than a non-tuple
type, and having a default argument would make the parameter list of a
single-parameter function into a tuple type. Hence,
func foo(x: Int = 5)
would get a different mangling from
func foo(x: Int)
even though we didn't actually allow overloading.
Fixes rdar://problem/24016341, and helps us along the way to SE-0111
(removing the significance of argument labels) because argument labels
are also declaration-centric, and need the same information.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
For historical reasons, the "name shadowing" computation is only
looking at the type---not even the interface type!---of
declarations. For variables and subscripts, this means that the
context (e.g., a constrained extension) wasn't been considered at all,
leading to declarations from other imported modules being
ignored. Patch up a little bit of this by using the overload
signature's type for variables and subscripts, because I need it for
ErrorProtocol's default implementations.
Longer-term, we should be using the overload signature (or something
very like it) for shadowing, consistently.
(and any other member with higher access control than its enclosing type)
There's no effect, but it is now considered legal and the compiler will
no longer warn about it. This allows an API author to prototype their
API with proper access levels and still limit the top-level type.
If the new getEffectiveAccess computation turns out to be expensive, we
can cache the result.
Note that the compiler will still warn when putting a public member
inside an extension explicitly marked internal, because the extended
type could be public and then including a public member would be valid.
It is also still an error to put a public member inside a constrained
extension of an internal type, though I think this one is safe to
relax later.
Progress on SE-0025 ('private' and 'fileprivate')
trying to set the superclass on classes in such situations by setting the superclass of an invalid decl to the error type.
This fixes a bunch of compiler crashes, and also changes some errors in other tests where the main error is the invalid declaration and now the
downstream errors can be a bit different because the decl has been invalidated.
Previously getInterfaceType() would punt to getType() if no
interface type was set. This patch changes getInterfaceType()
to assert if no interface type is set, and updates various
places to set the interface type explicitly.
This brings us a step closer to removing PolymorphicFunctionType.
First, enforce that the superclass of a class is an interface type.
Previously, Swift classes used interface types but imported
Objective-C generics used archetypes.
When the superclass type is always an interface type, we
can use the recently-added gatherAllSubstitutions() instead of
rolling our own parent type walk.
Also, this exposed an issue in name lookup where we would call
getSuperclass() on a type whose parent was an unbound generic.
This doesn't make sense, so generalize the existing check there.
There are many places where we do the 'if inside a protocol, get the
Self type parameter, otherwise, use the declared type' dance.
We actually have really handy utility methods that encapsulate this,
so let's use them more.
It sounds good on paper, but in practice we ended up breaking Core Data
projects (because people name their boolean properties 'isFoo' rather
than the Objective-C 'foo'), forcing an Objective-C-side change when
a mixed-source project upgrades to Swift 3, and causing collisions when
there are properties named both 'foo' and 'isFoo'. If people care about
their Swift boolean properties strictly following the Objective-C Cocoa
naming conventions, they'll have to specify them manually.
(We do have a bug to make it easier to rename the getter of a stored
property exposed to Objective-C: rdar://problem/21261564.)
This reverts commit 6fe6266c99.
rdar://problem/26847223
We're now correctly checking for inheritance, adding @objc methods,
and adding @objc protocols for both CF types and objc_runtime_visible
classes (those without visible symbols). The latter is used for some
of the types in Dispatch, which has exposed some of the classes that
were considered implementation details on past OSs.
We still don't properly implement using 'as?' to check conformance to
a Swift protocol for a CF or objc_runtime_visible type, but we can do
that later.
rdar://problem/26850367
This flag tracks whether we have a special kind of imported class
that has limitations in what you can do with it. Currently it's
used for two things: CF classes, and the magic "Protocol" class used
to represent Objective-C protocol metadata. I'm planning to add a
third to handle classes with the recently-added objc_runtime_visible
attribute, which describes an Objective-C class whose runtime symbols
are hidden (forcibly preventing categories and subclassing). This is
used for some of the types in Dispatch, which has exposed some of the
classes that were considered implementation details on past OSs.
I'm splitting the flag into an enum rather than just marking the
Dispatch classes with the existing flag because we still need to
be able to /cast/ to the Dispatch types (which you can't do with CF
types today) and because they deserve better than to be lumped in
with CF for diagnostic purposes.
Groundwork for rdar://problem/26850367, which is that Swift will
happily let you extend the new Dispatch classes but then fails to find
the symbols at link-time.
Consider this code:
struct A<T> {
struct B {}
struct C<U> {}
}
Previously:
- getDeclaredType() of 'A.B' would give 'A<T>.B'
- getDeclaredTypeInContext() of 'A.B' would give 'A<T>.B'
- getDeclaredType() of 'A.C' would give 'A<T>.C'
- getDeclaredTypeInContext() of 'A.C' would give 'A<T>.C<U>'
This was causing problems for nested generics. Now, with this change,
- getDeclaredType() of 'A.B' gives 'A.B' (*)
- getDeclaredTypeInContext() of 'A.B' gives 'A<T>.B'
- getDeclaredType() of 'A.C' gives 'A.C' (*)
- getDeclaredTypeInContext() of 'A.C' gives 'A<T>.C<U>'
(Differences marked with (*)).
Also, this change makes these accessors fully lazy. Previously,
only getDeclaredTypeInContext() and getDeclaredIterfaceType()
were lazy, whereas getDeclaredType() was built from validateDecl().
Fix a few spots where the return value wasn't being checked
properly.
These functions return ErrorType if a circularity was detected via
the generic parameter list, or if the extension did not resolve.
They return Type() if the extension cannot be resolved *yet*.
This is pretty subtle, and I'll need to do another pass over
callers of these functions at some point. Many of them should be
moved over to use getSelfInContext(), getSelfOfContext() and
getSelfInterfaceType() instead.
Finally, this patch consolidates logic for diagnosting invalid
nesting of types.
The parser had some code for protocols in bad places and bad things
inside protocols, and Sema had several different bail-outs for
bad things in protocols, nested generic types, and stuff nested
inside protocol extensions.
Combine all of these into a single set of checks in Sema. Note
that we no longer give up early if we find invalid nesting.
Leaving decls unvalidated and un-type-checked only leads to
further problems. Now that all the preliminary crap has been
fixed, we can go ahead and start validating these funny nested
decls, actually fixing some crashers in the process.
There was a weirdness with ProtocolType::get() that was causing me grief
while trying to refactor getDeclaredType() and related code in another
patch.
Instead of caching the result like we do elsewhere, this would directly
store the new type into the ProtocolDecl. This is smelly, so let's not
do that.
If a behavior has storage that can be initialized out-of-line, generate code in SILGen that uses stores to mark_uninitialized_behavior for eventual analysis by DI.
This is incomplete, particularly, it's missing code generation of glue thunks for accessors that require reabstraction, but I wanted to make sure the progress here didn't bitrot.
