Lazy property initializers can refer to 'self' either directly or
implicitly (via references to instance members). Model this in
ASTScope-based unqualified name lookup.
Note that the modeling of 'self' with the current name lookup
mechanism is broken, so when ASTScope-based unqualified name lookup is
enabled, it fixes SR-2203, rdar://problem/16954496, and the many dupes
of the latter.
For methods/initializers/deinitializers, modeling the scope of a
function body allows us to correctly introduce instance member lookup
relative to 'self'. Do so so that we can resolve unqualified name
lookup within methods based on the implicit 'self'.
Private and fileprivate declarations have a special "private
discriminator" to keep them from colliding with declarations with the
same signature in another file. The debugger uses this to prefer
declarations in the file you're currently stopped in when running the
expression parser. Unfortunately, the current logic didn't just prefer
declarations in the current file---it /only/ took declarations in the
current file, as long as there weren't zero. The fixed version will
include any declarations in the current file plus any declarations
with 'internal' or broader access.
(Really we shouldn't do this at the lookup level at all; it should
just be a tie-breaker in solution ranking in the constraint
solver. But that would be a more intrusive change.)
rdar://problem/27015195
We do this in a more general way higher up in the constraint
solver. Filtering out methods in name lookup only hurts
diagnostics.
In fact I don't think this behavior was intentional at all,
since the code in question was originally written in 2013
before a lot of the more recent member lookup and diagnostic
code was added.
This does break source compatibility though, but in a minor
way. See the change to the CoreGraphics overlay. Again,
though, I think this was an accident and not intentional.
If the extension ended up with ErrorType, we could crash while we
continue trying to process its body adding members.
Just bail out in this case.
rdar://problem/27671033
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.
'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')
This removes the logic which issued warnings when accessing enum
elements as instance members (SE-0036), making room for a new
implementation that will issue errors instead.
This reverts commit ae1058a39a.
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.
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.
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.
This ruins a diagnostic when a local variable shadows a type, but I think
the other reliability improvements that fell out of these changes are
worth it. If we want to bring the diagnostic back, there are better ways
of doing it than the old, somewhat duplicated approach.
With the previous resolveTypeInContext() patch, a few compiler
crashers regressed with this problem, presumably because we were now
performing lookups in more contexts than before.
This is a class of problems where we would attempt a recursive
validation:
1) Generic signature validation begins for type T
2) Name lookup in type context finds a non-type declaration D nested in T
3) Generic signature validation begins for D
4) The outer generic context of D is T, but T doesn't have a generic
signature yet
The right way to break such cycles is to implement the iterative
decl checker design. However when the recursion is via name lookup,
we can try to avoid the problem in the first place by not validating
non-type declarations if the client requested a type-only lookup.
Note that there is a small semantic change here, where programs that
were previously rejected as invalid because of name clashes are
now valid. It is arguable if we want to allow stuff like this or not:
class A {
func A(a: A) {}
}
or
class Case {}
enum Foo {
case Case(Case)
}
However at the very least, the new behavior is better because it
gives us an opportunity to add a diagnostic in the right place
later. The old diagnostics were not very good, for example the
second example just yields "use of undeclared type 'Case'".
In other examples, the undeclared type diagnostic would come up
multiple times, or we would generate a cryptic "type 'A' used within
its own definition".
As far as I understand, this should not change behavior of any existing
valid code.
The unavailable-in-current-Swift declarations introduced by the Clang
importer to help with migrating Swift 2.x code to Swift 3's naming
cause problems with unqualified name lookup when they shadow, e.g.,
types. The biggest problem in practice is with "URL", which is a
common Cocoa property name (in Swift 2) that becomes "url" in Swift 3,
but the old name conflicts with the Foundation value type "URL".
Fixes <rdar://problem/26236989>.
This was added at some point to make 'import Foundation' faster in the REPL.
What we really care about though is not delaying synthesis of the rawValue
accessors (those are synthesized on demand anyway), but delaying the
conformance check to RawRepresentable.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
We were memcopying a std::function into the the AST context memory,
which leaks memory incidentally used by the std::function
implementation. Fix by using a std::unique_ptr and registering a
destructor cleanup. Incidentally, I turned the array of functions into
a single function, since we never have more than one anyway.
rdar://problem/22387897
Swift SVN r31600
Update the importer and name lookup to prefer a factory initializer that is more available
over a convenience initializer that is less available even though we generally prefer
convenience initializers over convenience factory initializers. The motivation for this
change is CIColor, which has added a new convenience initializer:
- (instancetype)initWithRed:(CGFloat)r green:(CGFloat)g blue:(CGFloat)b NS_AVAILABLE(10_11, 9_0);
but already has existing convenience factory initializer:
+ (instancetype)colorWithRed:(CGFloat)r green:(CGFloat)g blue:(CGFloat)b;
Without this change we prefer -initWithRed:green:blue, so instantiating CIColor with:
let colorChannelValue: CGFloat = …
let ciColor = CIColor(red: colorChannelValue, green: colorChannelValue, blue: colorChannelValue)
results in an availability error even though there is a perfectly available convenience
factory initializer. With this change, we choose the convenience factory initializer
when importing, so there is no availability error.
rdar://problem/20617581
Swift SVN r30946
isSettable() returns true for these, but they don't have a setter.
Tread carefully around them.
Fixes <rdar://problem/21877598> and <rdar://problem/21933630>.
Swift SVN r30631
It's common for a requirement in a protocol and an implementation of that
requirement in a protocol extension to have the same
signature. Overload resolution prefers the requirement (which
dispatches dynamically), but that was being subverted by the shadowing
rules when the protocol came from an imported module and the extension
was in the current module. Fixes rdar://problem/21739333.
Swift SVN r30598
They had already diverged even before my last commit. Let's not have that
happen again!
This re-fixes code completion for bindings declared in top-level guard
statements.
More rdar://problem/21928533
Swift SVN r30525
These variables really are local variables -- they have have a
TopLevelCodeDecl as their DeclContext rather than the SourceFile.
Treating them as global variables caused crashes in serialization.
We need an overhaul of top-level variables in script files anyway
(see rdar://problem/20992489&21628526), but this fixes the immediate
issue.
rdar://problem/21928533
Swift SVN r30519
'let' properties are settable inside certain initializers, but the
logic was wrong -- in most cases we would fall through and return
true from ::isSettable().
This came up when deserialization (correctly) didn't set the setter
accessibility on a 'let' property, and a read of that property from
a constructor in another struct incorrectly decided the property
was settable, causing a crash.
Fixes <rdar://problem/21559246>.
Swift SVN r30484
Right now we just have one notion of providing or using a type (as opposed to a
name). It doesn't matter if you're doing lookups, or checking conformance, or
inheriting from a superclass or protocol -- they're all in the same bucket. I'd
like to split these out so that extending a commonly-used type (like, say, Array)
doesn't cause every file in your target to depend on your extension.
This commit doesn't do anything but start tracking which member names are looked
up. For the other things you can do with a type, it's using a dummy empty name.
Swift SVN r30284
