Rather than force conformances to Equatable to be added to all imported enumeration types outright, change them back to being lazily added. We can then handle situations where new overloads of '==' are introduced during constraint generation by re-writing the relevant overload disjunction constraint to include the newly forced declarations as bind options.
Swift SVN r17557
Previously, we were just using the base name, which resulted in massive
inefficiency when dealing with Clang (we basically had to check every
selector in the system to see if it had the same first selector piece).
I've hacked ConstraintSystem a bit to carry a map from UnresolvedDotExpr
to the ApplyExpr that consumes it, so that we can use the full DeclName
and look up methods by full selector.
Now that dynamic lookup is fast, re-enable it for the
Foundation_bridge.swift test. (r17520 actually provided most of the benefit.)
This does break selector lookup on AnyObject when doing selector splitting,
and slightly regresses diagnostics when you try to call a method on AnyObject
and forget a parameter name.
<rdar://problem/16808651>. Part of the Playground performance efforts.
Swift SVN r17524
Building on previous work, this allows us to properly handle things like Int?() and Int[]().
Of course doing this exposed that TypeExpr was not correct in lots of ways, so this also:
- Revamps TypeExpr processing to carry a decl in the TypeLoc instead of
carrying a Type. This allows us to correctly handle more complex generics case.
- Enhances CSGen to properly open generic types so we can infer generic type parameters from
context.
Swift SVN r17019
- Change astdumper to print the typerepr in the more canonical syntax.
- Remove bogus logic from CSApply that was preventing us from rewriting
TypeExprs properly
- Teach CSGen to handle unbound generics correctly (thanks to Doug for the help on this)
Swift SVN r17007
and teach type checking to resolve TypeExprs that lack TypeReprs.
This gets us debugged enough to start shoving all local type references
down the TypeExpr path, which is significant progress.
Swift SVN r16958
This leaves in the existing syntax for @unchecked T?. That will
be addressed in later patches.
There's still a mysterious case where some of the SIL output
includes UncheckedOptional<T> and some places T!.
Moreover, this doesn't handle SourceKit's behavior for printing
for overrides. This just handles parsing the 'T!' syntax.
Swift SVN r16945
For an assignment "x = y", the locator for the conversion constraint
is an "assign source" locator anchored on the AssignExpr (not the
source expression), so we can properly relate source to destination.
Swift SVN r16931
them with uses of TypeExpr instead. The remaining uses of
MetaTypeExpr (which will be renamed soon) are places where we
are applying the ".dynamicType" virtual property to an expression.
Unadorned uses of types in code, e.g. the Int in "Int.self" are
now represented with TypeExpr.
One unfortunate travesty that doing this work revealed is that we
are extremely sloppy and terrible about maintaining location information
in implicitly generated decls, and our invariants vary quite a bit. This
is really horrible, but I'm not sure whether I'll go fix the hacks or not.
This patch perpetuates the existing crimes, but makes them more visible.
NFC!
Swift SVN r16646
when resolving identifiers into types. This will eventually allow us to
solve annoying issues like rdar://15295763&15588967 by better modeling
what we already have.
Swift SVN r16620
type-checking and applying attributes.
We should really move to a model where variables are
type-checked in a single pass, including their attributes.
However, given that we don't, attributes which affect the
type must be applied in multiple places and hence multiple
times to the same declaration.
Swift SVN r16339
Make it the conversion function's responsibility to addressof the inout if it wants that pointer. For things like mutable array conversion, we actually want the original inout as a parameter, particularly so we can call _makeUnique on it without disturbing its reference count.
Swift SVN r16090
Add a third branch to the constraint system for '&x' expressions that allows conversion from an lvalue to a type via an additional writeback step:
- Add an LValueConversionExpr node that converts from @lvalue T to @lvalue U, given a pair of functions that convert T -> U and U -> T, to represent the writeback temporary.
- Allow conversion in an inout expression from @lvalue T to a type U that has the following members:
static func __writeback_conversion(Builtin.RawPointer, T.Type) -> U
static func __writeback_conversion_get(T) -> V
static func __writeback_conversion_set(V) -> T
which builds a solution that produces an LValueConversion from the get/set pair before passing the pointer to the writeback temporary off to the conversion function.
Swift SVN r15764
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
permit the result to be *convertible* to the contextual
type and not merely *exactly equal*.
I don't have a use case for factory methods that return
subtypes, but factory methods that return @unchecked T?
are going to be pervasive, and it's not like the subtype
thing is unreasonable.
Swift SVN r15664
We'll need types to be convertible from multiple kinds of inouts, which currently can't be represented with protocol conformance since we only allow one protocol conformance per type per protocol. Instead just look for a magic "__inout_conversion" static method in the type; this is lame but easy, and inout conversions shouldn't be available outside of the stdlib anyway.
Swift SVN r15599
Add two new AST node types:
- InOutConversionExpr, which represents an '&x' expression that involves inout conversion. This will be a signal to SILGen not to introduce a writeback scope for the nested conversion call.
- LValueToPointerExpr, which represents the primitive '@lvalue T' to 'RawPointer' conversion that produces the argument to the inout conversion.
Build an InOutConversionExpr AST when an inout expression is resolved by a conversion to an BuiltinInOutAddressConvertible type.
Swift SVN r15594
Set up the disjunction system for '&x' expressions that allows them to type-check either as simple lvalue-to-inout conversions, as before, or as address conversions that go through one of the BuiltinInOut*Convertible protocols. The solution side is not yet implemented.
Swift SVN r15593
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
Factor an IdentityExpr base class out of ParenExpr, and migrate most of the logic to see through ParenExprs to see through IdentityExprs instead. Add DotSelfExpr as a new subclass of IdentityExpr, produced by parsing 'x.self'.
Swift SVN r14381
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
- 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
Introduce a new Pattern::forEachVariable that takes a lambda and iterates
over all the variables encompassed by the pattern (the ones found by
collectVariables) and runs the lambda on it.
Use this to implement collectVariables, so we only have one copy of the code.
Convert several places to use this, removing a bunch of duplicated code for
walking the pattern structure and extracting decls.
Convert a few uses of collectVariables to forEachVariable, leading to more
clear code without a temporary smallvector.
Remove simplifyPatternTypes in CSApply.cpp, which is dead.
Swift SVN r13545
This eliminates the duplication of type variables that represent the member types of existing type variables. I'm unable to trigger this with a test case at the moment, but it becomes important when we begin to substitute type variables through protocol conformances.
Swift SVN r12971
