Allow instance properties and methods to be referenced from
within a lazy property initializer, with or without explicit
'self.' qualification.
The old behavior in Swift 3 was an incredible combination
of odd quirks:
- If the lazy property had an explicitly-written type, it was
possible to reference instance members from the initializer
expression by explicitly prefixing 'self.'.
- However, if the lazy property type is inferred, it would
first be type checked in the initializer context, which
has no 'self' available.
- Unqualified references to instance members did not work
at all, because name lookup thought the "location" of the
lookup was outside of the body of the getter.
- Unqualified references to static properties worked, however
unqualified references to static methods did not, and
produced a bogus diagnostic, because one part of the name
lookup code thought that initializers were "instance
context" and another thought they were "static context".
This patch improves on the old behavior with the following
fixes:
- Give PatternBindingInitializers associated with lazy
properties an implicit 'self' declaration for use by
name lookup.
- In order to allow "re-parenting" the initializer after it
has been type checked into the body of the getter, "steal"
the initializer's 'self' when buiding the getter.
- Fix up name lookup and make it aware of the implicit
'self' decl of a PatternBindingInitializer.
This improves upon an earlier fix for this issue by Doug Gregor
which only worked with ASTScope enabled; the new fix is more
general and shares logic between the two name lookup
implementations.
Fixes <rdar://problem/16888679>, <https://bugs.swift.org/browse/SR-48>,
<https://bugs.swift.org/browse/SR-2203>,
<https://bugs.swift.org/browse/SR-4663>, and the countless other
dupes of this issue.
Protocol requirements involving same-type-to-Self constraints cannot
be witnessed by declarations in non-final classes that have the same
form of same-type requirement to the corresponding class type, because
it creates a soundness hole with subclasses:
protocol Q {
func foo<T: P>(_: T, _: T.T) where T.T == Self
}
class C: Q {
func foo<T: P>(_: T, _: C) where T.T == C {}
}
class D: C {
// in D, T.T == D does not hold
}
Warn about this in Swift 3 compatibility mode, error on it in Swift 4
mode. When possible, provide a note + Fix-It suggesting that the
same-type constraint might be weakened to a superclass constraint
(which works with subclassing).
Fixes rdar://problem/30398503.
The AST verifier was causing deserialization of generic environments,
which slows things down considerably and affects our ability to test
for laziness in deserialization. Prevent it from doing so---and only
do the extra checkig if something else deserialized the generic
environment already.
... except there are some cases where it happens through means that
are harder to control (e.g., the AST walker for patterns) that need
more thought.
The GenericSignatureBuilder requires `finalize()` to be called before a
generic signature can be retrieved with `getGenericSignature()`. Most of the former isn’t strictly needed unless you want a generic signature, and the
latter is potentially expensive. `computeGenericSignature()` combines the two
operations together, since they are conceptually related. Update most of the
callers to the former two functions to use `computeGenericSignature()`.
This isn't an inherent limitation of the language---in fact, it would
be a problem for library evolution if you had to know a superclass's
full vtable contents to generate the vtable for a subclass. However,
that's exactly where we are today, and that's not going to change for
Swift 4.
One small hole in the Swift 3 / Swift 4 story.
More rdar://problem/31878396
As such, we no longer insert two placeholders for initializers that
need two vtable slots; instead we record that in the
MissingMemberDecl. I can see MissingMemberDecl growing to be something
we'd actually show to users, that can be used for other kinds of
declarations that don't have vtable entries, but for now I'm not going
to worry about any of that.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This lets us serialize that decision, which means we can conceivably
/change/ the decision in later versions of the compiler without
breaking existing code. More immediately, it's groundwork that will
eventually allow us to drop decls from the AST without affecting
vtable layout.
This isn't actually a great answer; what we really want is for SIL
vtables to be serialized consistently and treated as the point of
truth. But that would be more change than we're comfortable taking in
the Swift 4 timeframe.
First part of rdar://problem/31878396.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
(which can happen if an imported class has un-importable initializers)
Our initializer model guarantees that it's safe to inherit convenience
initializers when a subclass has implemented all designated
initializers, since each convenience initializer will be implemented
by calling one of the designated initializers. If one of the
designated initializers /can't/ be implemented in Swift, however,
then inheriting the convenience initializer would not be safe.
This is potentially a source-breaking change, so the importer will
only actually record that it failed to import something in when
compiling in Swift 4 mode.
rdar://problem/31563662
Rather than detecting recursion and bailing early, delay requirements
that would form recursive types. Note that we aren't actually
processing them later.
* Use the presence of an argument type to check for associated values
hasOnlyCasesWithoutAssociatedValues returns true for any serialized
enum declaration whether or not it has cases. This never really came
up because it's mostly relevant to Sema's proto-deriving mechanism. Fix
this by using the presence of the case's argument type instead.
* Separate checks for presence of cases and enum simplicity
Necessary because the old behavior was an artifact of the
implementation.
Whether a protocol composition requires a class is no longer
solely a property of what protocols it contains; now, a
protocol composition consisting of a non-class constrained
protocol and a superclass should return true from requiresClass().
This is done by looking at the ExistentialLayout, instead of
walking the members directly.
Two problems:
1) We were tearing down the type checker too early, before all
relevant decls in other files had been type checked, so there
was no LazyResolver available for use in the ASTContext.
This might explain the crashes coming through
diagnoseUnintendedObjCMethodOverrides().
2) When a lazy resolver was set in the ASTContext, we were not
using it in the case where nullptr was passed in as the
'resolver' parameter to inheritsSuperclassInitializers().
This might fix the crashes where we were coming in from other
code paths, but I'm less confident about this case.
Possibly fixes <rdar://problem/29043074>, <rdar://problem/30976765>,
<rdar://problem/31122590>, and <rdar://problem/31286627>, and the
many other similar-looking dupes.
Since the previous fix is essentially a hack to dodge an
assertion, I'm adding stronger assertions to
AbstractTypeParamDecl::getSuperclass() and
getConformingProtocols().
This fixes a crash when referencing partially-applied methods
from @_inlineable functions.
Also, curry thunks for private methods do not need shared
linkage; private is sufficient.
This crash happens because shouldAddSelfFixit (a check for the expected_self_before_reference diagnotic) performs name lookup inside the parser, which causes a search for extensions, which triggers the mangler, which can get confused if we are in an unfinished declaration (a PatternBindingInitilizer in this case).
A cleaner fix would be to move that logic inside Sema, but it would require much more refactoring that I don’t feel comfortable doing. Instead, this band-aid checks if the innermost type is inside a local context. If that’s the case, we can ignore the search for extensions.
New GenericTypeParamDecls should always be created with an
InvalidDepth, to prevent canonicalization before the generic
parameter list has been type checked.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
