Use ArchetypeResolutionKind::CompleteWellFormed whenever we need to
ask questions about the potential archetype, and
ArchetypeResolutionKind::WellFormed when we need only evaluate whether
there is a legitimate type with that name (and possibly get a handle
to it).
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
The outside representation already went to a flat set of requirements;
make the internal representation match so we aren't tempted to use the
requirement signature as inputs to a generic signature.
Rather than pretend that the requirement signature of a protocol is a
full, well-formed generic signature that one can meaningfully query,
treat it as a flat set of requirements. Nearly all clients already did
this, but make it official. NFC
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
- A mutating method or accessor always has 'inout self'.
- A nonmutating method or accessor never has 'inout self'.
- Only instance members can be mutating.
- Addressors are still addressors even when on static members.
Came up after reviewing another patch that confused the two as
possibly distinct concepts.
We allow protocols to inherit from protocol compositions
defined via a typealias, eg,
typealias PQ = P & Q
protocol R : PQ {}
Sometimes, ProtocolDecl::getInheritedProtocols() is called before
the protocol's requirement signature has been computed. In this
case, we walk the inheritance clause of the protocol directly.
This walk was only looking at ProtocolType members of the
inheritance clause, ignoring ProtocolCompositionTypes.
As a result, name lookup could fail with an assertion because of
not being able to "see" members inherited via the protocol
composition.
Fixes <rdar://problem/32595988>.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
This is a second revision of the patch -- instead of changing
getEffectiveAccess() to take an extra parameter, this changes
getFormalAccessScope() instead.
Fixes <rdar://problem/32592973>.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
Hack around this by adding a new 'forLinkage' parameter to
getEffectiveAccess(). When this is false, we ignore the
-enable-testing flag, and only look for the @_versioned
attribute.
I'm not very happy with the fix, because it only compliates
the subtle behaviors of getFormalAccess(), getEffectiveAccess()
and getFormalAccessScope() further. But refactoring this is
a bigger change than I'm willing to put into swift-4.0-branch.
Fixes <rdar://problem/32592973>.
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
Potential archetypes can resolve to either an associated type or a
typealias. Generalize the latter to "any concrete type", both because
the current implementation is unnecessarily narrow (typealiases aren't
actually special in this regard) and to get us closer to handling
lookups via superclass constraints when resolving these types.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
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.
