Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
Using `-dump-parse` on `func foo<T>(bar: T) {}` results in:
```
(source_file
(func_decl "foo(bar:)"<T>
(parameter_list
(parameter "bar" apiName=bar))
(brace_stmt)))
```
Notice there is no space between "foo(bar:)" and <T>.
Add a space to correct the formatting error.
- TypeAliasDecl::getAliasType() is gone. Now, getDeclaredInterfaceType()
always returns the NameAliasType.
- NameAliasTypes now always desugar to the underlying type as an
interface type.
- The NameAliasType of a generic type alias no longer desugars to an
UnboundGenericType; call TypeAliasDecl::getUnboundGenericType() if you
want that.
- The "lazy mapTypeOutOfContext()" hack for deserialized TypeAliasDecls
is gone.
- The process of constructing a synthesized TypeAliasDecl is much simpler
now; instead of calling computeType(), setInterfaceType() and then
setting the recursive properties in the right order, just call
setUnderlyingType(), passing it either an interface type or a
contextual type.
In particular, many places weren't setting the recursive properties,
such as the ClangImporter and deserialization. This meant that queries
such as hasArchetype() or hasTypeParameter() would return incorrect
results on NameAliasTypes, which caused various subtle problems.
- Finally, add some more tests for generic typealiases, most of which
fail because they're still pretty broken.
This was causing us to emit diagnostics talking about τ_m_n, which is
not helpful.
Now that generic function types print sanely, print them in a few
places where we were previously printing PolymorphicFunctionTypes.
Until the point where ASTScope-based unqualified name lookup is the
default, unqualified name lookup can still find names declared *after*
the source location. The 'hasType' check no longer makes sense, so actually
check the source location of the entity we found.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
Parameters are normally given 'private' access, because they can only
be referred to within the body of the owning function. However,
single-expression closures allow a parameter to appear in a constraint
system in the containing context. Mark closure parameters as
'fileprivate' instead.
Similarly, 'private' at the top level is normally equivalent to
'fileprivate', but not for a decl that appears within top-level
imperative code, which has a TopLevelCodeDecl context. This currently
only happens for bindings in a top-level 'guard' statement; mark
these variables and constants as 'fileprivate' as well.
More progress on SE-0025 ('private' and 'fileprivate').
This also adds some tests for the existing generic parameter
capture logic, which was only tested as part of SILGen tests
until now.
Also, move capture analysis into a new TypeCheckCaptures.cpp file.
Make the following patterns illegal:
if var x = ... {
...
}
guard var x = ... else {
...
}
while var x = ... {
...
}
And provide a replacement fixit 'var' -> 'let'.
rdar://problem/23172698
Swift SVN r32855
Otherwise, we'll fail to capture "locals" declared in top-level guard
statements. This led to an assertion failure in SILGen.
Depends on previous commit.
rdar://problem/21997265
Swift SVN r30812
init()'s implicitly evaluate the initial values for properties, and we aren't modeling
that correctly in the AST. This prevented the closure checker from noticing these
accesses, leading to SILGen crashing later. In the absence of proper AST modeling of
this, add special case handling for them.
Swift SVN r29508
Special-casing these as MemberRefExprs created an asymmetry
where unbound archetype instance methods (<T : P> T.f) could
not be represented. Treating class and protocol methods
uniformly also eliminates a handful of special cases around
MemberRefExpr.
SILGen's RValue and call emission peepholes now have to know
about DeclRefExprs that point to protocol methods.
Finally, generalize the diagnostic for partially applied
mutating methods to any partially applied function with an
inout parameter, since this is not supported.
Fixes <rdar://problem/20564672>.
Swift SVN r29298
Properly implementing a class whose methods capture variables
defined in the outer scope requires adding the captures as
hidden vars in the class and initializers, and seems
non-trivial.
Just diagnose this case for now instead of crashing.
Fixes <rdar://problem/20853958>.
Swift SVN r28481
Local functions may reference each other as long as they don't transitively capture any vars or other non-function local decls before their declaration.
Swift SVN r28394
This location is used when deciding whether a capture has already been
initialized, and without it the compiler decides that the reference to
a name from the capture list should be rejected.
rdar://problem/19776255&20153574
Swift SVN r26103
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
This addresses the bulk of <rdar://problem/15344950>, which involes us
not being able to find local variable declarations in expressions when
the parser didn't pre-bind them for us.
The fix to name lookup itself insures that a case such as
case (var a, a)
doesn't allow the second 'a' to find the first.
Swift SVN r9858
There is a special-case hack to allow capture of 'this', which is
implicitly [byref] for structs. At the moment, most of the cases where
this hack is necessary are [auto_closure] parameters (for assertions
and &&/||).
Swift SVN r5047
