Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
and diagnoseGeneralConversionFailure(). The previous approach of trying
to dig into anchors would often lead to complaining about types at
different levels in the same diagnostic, and the complexity of the former
code isn't needed now that other changes have landed.
Swift SVN r31036
- Improve handling of if_expr in a couple of ways: teach constraint simplification
about IfThen/IfElse and teach CSDiags about the case when the cond expr doesn't match
BooleanType. This is rarely necessary, but CSDiags is all about cornercases, and this
does fix a problem in a testcase.
- Be a bit more specific about the constraint failure kind (e.g. say subtype) and when
we have a protocol conformance failure, emit a specific diagnostic about it, instead of
just saying that the types aren't convertible.
Swift SVN r30650
we can start taking advantage of ambiguously typed subexpressions in CSDiags. We
start by validating the callee function of ApplyExprs, which substantially improves
our abilities to generate precise diagnostics about malformed calls.
This is the minimal introduction of this concept to CSDiags, a lot of refactoring
is yet to come, however, this is enough to resolve:
<rdar://problem/21080030> Bad diagnostic for invalid method call in boolean expression
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
one of the testcases from:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
and a bunch of other places where we got weird "unexpected trailing closure"
diagnostics that made no sense. As usual, it is two steps forward and one step back,
as this exposed some other weird latent issues like:
<rdar://problem/21900971> QoI: Bogus conversion error in generics case
Swift SVN r30429
path associated with them, and to dig the expression the constraint refers to out
of the locator. Also teach simplifyLocator how to simplify closureexpr results out.
This eliminates a class of completely bogus diagnostics where the types reported
don't make any sense, resolving a class of radars like 19821875, where we now
produce excellent diagnostics.
That said, we still pick constraints to report that are unfortunate in some cases,
such as the example in expr/closure/closures.swift.
Swift SVN r29757
- Diagnose instead of crashing when doing this:
extension Array : MyProto where T : Equatable {}
- Fix crash when Self appeared in where clause
- Finally, improve the diagnostic for this:
extension Array<Foo> {}
Fixes <rdar://problem/21349794>.
Swift SVN r29379
This permits, e.g., extending Array for all Hashable T's. However, it
does not permit extending Array for T == String. Part of
rdar://problem/21142043.
Swift SVN r29107
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
We no longer allow extensions to provide generic parameters, and the
ability to parse the syntax
extension Array<String> { ... }
is causing confusion. Fixes rdar://problem/20873336.
Swift SVN r28468
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
generic parameter 'T' is not used in function signature
func f8<T> (x: Int) {}
This commit takes Jordan't comments on r28181 into account:
- it produces a shorter error message
- it does not change the compiler_crashers_fixed test and add a new expected error instead
Swift SVN r28194
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
There is no way to infer the generic parameter 'T' if it is not used in function signature
func f8<T> (x: Int) {}
^
Swift SVN r28181
The culprit happened to be a type representation cloner for tuple type
representations that didn't actually clone anything. Introduce an
AST-level verifier that makes sure we catch any archetypes that slip
into interface types earlier in the future.
Fixes rdar://problem/18796397 and the three dupes I've found so far.
Swift SVN r28080
in Xcode 6.4 I changed the compiler to start treating properties as rvalues in
initializers when they have an initializer since they cannot be overwritten
in the initializer. This has the unfortunate effect of typing derived member_refs
as rvalues as well, which causes SILGen to load the entire 'self' value instead of
just the member, triggering invalid DI errors in cases like this.
Fix this by always treating properties on self as lvalues in initializers. Invalid
reassignments are already diagnosed by DI anyway, and the QoI of the error is better
from DI than from Sema (as shown by the testsuite change).
Swift SVN r27721
Start allowing extensions to redeclare type parameters, which will get
different archetypes from the original nominal type. When an extension
does not redeclare type parameters, silently clone the nominal type's
generic type parameters so we still get distinct type parameters.
When deserializing an extension, wire up its generic parameter list so
we get the right archetypes for its members. This doesn't change the
module format (that happened earlier).
When determining the substitutions for an associated type that comes
from a different declaration context from the conformance that will
own the witness, be sure to map into the conformance's
DeclContext. Otherwise, we'll end up with tangled archetypes.
Fixes rdar://problem/16519588.
Swift SVN r26483
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
... now that we have an exquisitely shaved yak.
This provides a simple and uniform model for "let" constants: they are always either
immediately initialized in their declaration, or they are initialized dynamically
exactly once before any use.
This is a simple generalization of our current model for initializers, but enables
the use of let constants in more cases in local context, e.g. patterns like this:
let x : SomeThing
if condition {
x = foo()
} else {
x = bar()
}
use(x)
Previously this would have to be declared a "var" for no good reason: the value is
only ever initialized, never actually mutated.
The implementation of this is reasonably straight-forward now that the infrastructure
is in place: Sema treats 'let' constants as "settable" if they lack an initializer
(either in the declaration or in a non-PBD binding). This exposes them as an lvalue
at the AST level. SILGen then lowers these things to an alloc_stack, and DI enforces
the "initialization only" requirement that it already enforces for uninitialized 'let'
properties in structs/classes.
Swift SVN r23916
The changes to the decl/ext/generic test strip out testing of
extensions of nested generics, a feature whose syntax will change and
is fairly broken already.
Swift SVN r21750
We were checking for exact type equality of the DeclContexts, which
will not hold when extensions have their own archetypes. A near-term
fix would be to use interface types, but checking the nominal types is
a better long-term solution.
Swift SVN r20768
Extension binding decides which nominal type declaration is extended
by a given extension, so perform basic validation to ensure that the
generic parameter lists provided in the extension make sense. Note
that we're not checking the actual generic parameters properly in
the nested case, so none of this actually works at all. That will come
next, over in extension validation.
Swift SVN r20724
Extensions must have the same number of generic parameters as the
generic type they extend, and cannot add any additional requirements
beyond those on the extended generic type (yet!). We use requirement
inference to allow one to provide fewer requirements on the extension
than exist on the generic type. The expectation here is that one won't
ever repeat the requirements from the generic type.
Swift SVN r20706
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
