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
For now, just update NameLookup's FindLocalVal to use a
VisibleDeclConsumer just like lookupVisibleDecl().
A subsequent patch will continue removing duplicated code
now that this is place.
This fixes compiler crashers where we were not handling
declarations with duplicate names (which of course is an
error, diagnosed elsewhere).
Swift SVN r29913
- In name lookup, if we find a decl that is already being type checked
(which only occurs on illegal code) just assume it is acceptable instead
of blowing up with an assertion checking access control that hasn't been
evaluated yet.
- In checkInheritanceClause, make sure that the we mark the decl being
resolved as being type checked when resolving the types involved. That way,
cyclic references are detected as invalid, instead of causing assertions and
other explosions.
This fixes some compiler crashers.
Swift SVN r29538
Fold the witness-mapping code and deduplication logic into the main
lookup path, so we don't end up performing redundant lookups. Delay
the removal of overridden and shadowed declarations until after we've
done witness mapping, so we're not wasting effort the first time
around. NFC except for a small performance optimization.
Swift SVN r29060
When performing unqualified lookup within a type context (or method
thereof) that is a protocol or a protocol extension, use the Self
archetype of the protocol or extension so we look in types implied by
the requirements as well. Part of rdar://problem/20509152, fixing the
example provided in rdar://problem/20694545.
Swift SVN r28363
Members of protocols found via unqualified name lookup are mapped to
their corresponding witnesses, as we do for qualified name
lookup. This is the bulk of the compiler changes for
rdar://problem/20509152. Performing this mapping for unqualified name
lookup of types will follow.
Swift SVN r28333
We're still doing too much work to form these unqualified lookup
results that should really move into semantic analysis, but this is
the NFC part we need now.
Swift SVN r28331
Make unqualified lookup always provide a declaration for the things it
finds, rather than providing either a module or a declaration. Unify
various code paths in our type checker now that module declarations
come in with the other declarations.
Swift SVN r28286
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
When reading the generic parameters of a constrained protocol
extension, cross-refencing an associated type would perform name
lookup into the protocol extension itself, causing fatal recursion
during deserialization. Fixed by avoiding additional deserialization
when looking for an associated type. Fixes rdar://problem/20812303.
Swift SVN r28228
