Diagnose a metatype reference that doesn't appear as part of a call or member reference, offering fixits to either default-construct the type or get at the metatype explicitly using '.self'. Also diagnose an attempt to refer to 'T.type' by fixiting it to '.self'.
Swift SVN r14433
A couple of related fixes here:
* Properly diagnose extraneous @override on subscript declarations
* Allow covariant overrides of (non-mutable!) subscripts
* Check subscript overrides as part of declaration validation
Swift SVN r14409
A few improvements in our checking of property overrides:
* Properly check for an extraneous @override on a property
* Don't allow overriding of stored properties or with a stored property
* Only allow a covariant override when the overridden property is not mutable
* Check overrides as part of validation, not in a post-pass
Swift SVN r14403
The 'override' attribute indicates that the given declaration, which
may be a method, property, or subscript, overrides a declaration in
its superclass. Per today's discussion, the 'override' attribute must
be present if and only if the corresponding declaration overrides a
declaration in its superclass.
This implements most of <rdar://problem/14798539>. There's still more
work to do to on property and subscript overrides.
Swift SVN r14388
... but obviously not when we've statically derived the existential
metatype. This isn't quite the way I'd like to prohibit these issues,
but more work on existentials and metatypes is coming up shortly.
Swift SVN r14326
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
An arbitrary value of class metatype cannot be used to construct an
object, because there's no guarantee that a given subclass will
provide that initializer.
Swift SVN r14175
Previously, semantic analysis would permit uses of DynamicSelf in the
body of a DynamicSelf method. However, SILGen's lowering of
DynamicSelf to the underlying self type caused breakage. Because we
don't have a pressing need for this feature, just disable
it. Restricts the scope of <rdar://problem/15862605>.
Swift SVN r14172
The name Stream didn't seem to be working out as intended; we kept
gravitating back to calling it Generator, which is precedented in other
languages. Also, Stream seems to beg for qualification as Input or
Output. I think we'd like to reserve Stream for things that are more
bulk-character-API-ish.
Swift SVN r13893
From now on, /any/ changes to SIL or AST serialization must increment
VERSION_MINOR in ModuleFormat.h.
The original intent of VERSION_MAJOR/VERSION_MINOR was that VERSION_MAJOR
would only increment when backwards-incompatible changes are introduced,
and VERSION_MINOR merely indicates whether to expect additional information.
However, the module infrastructure currently isn't forgiving enough to accept
even backwards-compatible changes to the record schemas, and the SIL
serialization design might not be compatible with that at all.
So for now, treat any version number 0.x as incompatible with any other 0.y.
We can bump to 1 when we hit stability.
<rdar://problem/15494343>
Swift SVN r13841
"parameter list" instead of "tuple argument". Fix a potential crash I
introduced by making an assumption about default initialized implied name
parameters being the only thing in parens.
Swift SVN r13813
This allows us to use implicit names in protocols and asm name functions, as well
as for the first chunk of selectors. This feature is particularly useful for
delegate methods.
Swift SVN r13751
Introduce a new expression kind, OpenExistentialExpr, that "opens" up
an existential value into a value of a fresh archetype type that
represents the dynamic type of the existential. That value can be
referenced (via an OpaqueValueExpr) within the within the
subexpression of OpenExistentialExpr. For example, a call to a
DynamicSelf method on an existential looks something like this:
(open_existential_expr implicit type='P'
(opaque_value_expr implicit type='opened P' @ 0x7fd95207c290
unique)
(load_expr implicit type='P'
(declref_expr type='@lvalue P' decl=t.(file).func
decl.p@t.swift:5:37 specialized=no))
(erasure_expr implicit type='P'
(call_expr type='opened P'
(archetype_member_ref_expr type='() -> opened P'
decl=t.(file).P.f@t.swift:2:8 [with Self=opened P]
(opaque_value_expr implicit type='opened P' @
0x7fd95207c290 unique))
(tuple_expr type='()')))))
Note that we're using archetype_member_ref_expr rather than
existential_member_ref_expr, because the call is operating on the
opaque_value_expr of archetype type. The outer erasure turns the
archetype value back into an existential value.
The SILGen side of this is somewhat incomplete; we're using
project_existential[_ref] to open the existential, which is almost
correct: it gives us access to the value as an archetype, but IRGen
doesn't know to treat the archetype type as a fresh archetype whose
conformances come from the existential. Additionally, the output of
the opened type is not properly parsable. I'll fix this in follow-on
commits.
Finally, the type checker very narrowly introduces support for
OpenExistentialExpr as it pertains to DynamicSelf. However, this can
generalize to support all accesses into existentials, eliminating the
need for ExistentialMemberRef and ExistentialSubscript in the AST and
protocol_method in SIL, as well as enabling more advanced existential
features should we want them later.
Swift SVN r13740
Treat inout as a SIL-only attribute, but produce a better diagnostic for it
if someone uses it accidentally (which I expect to be common over the next
few weeks). inout is done.
Swift SVN r13567
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
"@mutating func f()". I'm keeping the @mutating version around
so we can determine what to do with @!mutating.
Also, improve the QoI of mutating related diagnostics.
Swift SVN r13480
When referring to a DynamicSelf method, treat DynamicSelf as an alias
for the class type in which the method was declared, then perform a
function conversion to a method with the appropriate subclass as the
result result type. This is always a (trivial) subtype conversion on
the method.
Swift SVN r13268
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
When we type check the signature of a method, determine which method
it overrides (if any) at that time. This ensures that we always have
this information for name lookup (per <rdar://problem/15932845>).
As part of this, start to make the overriding rules a little more
sane. John has worked out more of the model here, but this patch:
- Considers an Objective-C method an override of another Objective-C
method if the selectors match and the type vs. instance-ness of the
methods match. The method types are checked for consistency
(subtyping is okay).
- Diagnoses when a method overrides more than one method from a
superclass, and
- Eliminates the "cannot overload method from a superclass"
diagnostic, which is overly pedantic and oddly limiting.
Note that we lose some amount of checking here. Specifically, we don't
have a good place to check that one has not provided two different
methods that override the same superclass method. The older code did
that (somewhat), and it's not a trivial problem to solve efficiently.
This fixes the part of <rdar://problem/15597226> that is needed for
<rdar://problem/15932845>. It still doesn't handle properties,
subscripts, and undoubtedly other issues.
Swift SVN r13108
Since we type-check local variables in statement order in a function, but
resolve names on a whole-scope basis, we can end up with a name that refers
to a local variable before its declaration has been reached. If this happens,
the variable won't have a type.
Checking this correctly may require comparing the order of statements in a
syntactic scope, but for now, just emit an error message if a reference
ever resolves to a variable without a type. (Note that UnqualifiedLookup
will have already tried to validate the decl, so if it's a global we just
haven't seen yet there's not a problem.)
Unfortunately, we won't get this right for top-level variables in script
source files, since those are still stored at global context and can be
validated on demand. They're never uninitialized, but zero-initialization
may not be valid for all global kinds.
<rdar://problem/15912025>
Swift SVN r13003
Take DynamicSelf as a keyword, but parse it as a type-identifier.
Teach function declaration checking to sniff out and validate
DynamicSelf early, with appropriate QoI for references to DynamicSelf
that appear in other places.
As a temporary hack, DynamicSelf resolves to an alias for 'Self' in a
protocol or the enclosing nominal type.
Swift SVN r12708
As part of this, give diagnoseUnknownType() the ability to fix the current component so that we continue as-if the user had written what we wanted. This gives us a hook for various forms of fixes, e.g., typo correction on type references.
Swift SVN r12707
its basic logic in libAST, which both makes it easier to
implement and makes it possible to use in the places that
should care about it, i.e. in IR-gen and SIL-gen.
Per Doug, none of the places that were introducing
trivial-subtype constraints really needed to do so rather
than just using subtype constraints.
Swift SVN r12679
protocol BaseProto {
typealias AssocTy
}
var a: BaseProto.AssocTy // error!
While this could be interpreted to mean "a is an existential bounded by
whatever AssocTy is bounded by", we don't actually support this in any
other contexts; if a protocol has a function that returns an associated type,
it can only be used in a concrete or generic context, not an existential one.
<rdar://problem/15850024>
Swift SVN r12600
