Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
This was blocked by some type-checker issues:
First, we weren't registering a constraint restriction when
tail-recursing in matchTypes (as opposed to when creating
a disjunction because multiple conversions applied). Do so,
and move the set of constraint restrictions to the constraint
system in order to make this simpler. A large amount of similar
solver state is already there, and of course solving the system
already prospectively modifies the constraint graph.
Second, only set up a potential existential conversion when
working with concrete types. Without this, we would fail to
typecheck conversions to optional protocol types, but not
optional class/struct/whatever types. It's not clear whether
whether we should ever really be considering conversions when
either of the types is non-concrete.
I believe it was the second fix which removed a need for a !
in the NewArray test case.
Swift SVN r14637
... 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
not to an arbitrary type that's convertible to the existential.
Arbitrary conversions aren't necessarily reversible.
The specific test case in rdar://16041990 involves a downcast
to String instead of NSString; that's supportable in principle,
but it's at the very least a significant feature, and clearly
there are non-reversible conversions out there.
Swift SVN r14028
matter whether the target type is a class existential.
The subtype relation should form a lattice and be intrinsically
reversible; everything else is a conversion.
Swift SVN r14027
- 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
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
a function conversion to be bad.
This encourages the type-checker to place conversions within
closures rather than outside; the test case here crashed in
SIL verification because of that. (Yes, that means that there's
an underlying problem still when the function conversion is
required; that's tracked by rdar://15875305.) But in general,
function conversions are likely to be expensive, and it's good
to avoid them when possible.
The setup work to add SK_FunctionConversion was accidentally
committed as part of r12813.
Swift SVN r12839
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
- MaterializeExpr can never be formed in an argument list (but
still can as the base object) so remove that case from CSApply.
- LValues never exist *inside* of tuples, so remove code related
to that.
Swift SVN r11889
- shouldTryUserConversion was not looking through @lvalue to determine if
the underlying type had a __conversion member, so we were only trying user
conversions on lvalues through an lvalue-to-rvalue conversion.
- Similarly, fix the similar-but-different filter in tryUserConversion to look through
lvalues as well.
This causes the QoI of some conversion diagnostics to get worse (the dreaded "does
not type check error") because there are now two possible conversions instead of one
in some cases and the diagnostics of the type checker doesn't handle this case well.
Swift SVN r11789
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
- Switch all the 'self' mutable arguments to take self as @inout, since
binding methods to uncurried functions expose them as such.
- Eliminate the subtype relationship between @inout and @inout(implicit),
which means that we eliminate all sorts of weird cases where they get
dropped (see the updated testcases).
- Eliminate the logic in adjustLValueForReference that walks through functions
converting @inout to @inout(implicit) in strange cases.
- Introduce a new set of type checker constraints and conversion kinds to properly
handle assignment operators: when rebound or curried, their input/result argument
is exposed as @inout and requires an explicit &. When applied directly (e.g.
as ++i), they get an implicit AddressOfExpr to bind the mutated lvalue as an
@inout argument.
Overall, the short term effect of this is to fix a few old bugs handling lvalues.
The long term effect is to drive a larger wedge between implicit and explicit
lvalues.
Swift SVN r11708
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
- Switch @mutable to be a tri-state attribute that is invertable with @!mutable.
- Move the semantic form of 'mutable' to being a bit on FuncDecl instead of
something in DeclAttrs. The former is a binary bit, the later is a tristate
which differentiates between "not present", "present and set" "present and inverted".
- Diagnose some invalid uses of @mutable, e.g. on class methods.
- Make setters default to mutable, and allow them to be switched with @!mutable.
Swift SVN r11439
Rather than performing a two-pass walk over all of the constraints in
the system to attach them to type variables, use the existing type
variable -> constraints mapping in the constraint graph to make this a
faster single-pass process. Also clarify the type bindings a little
bit. Improves type checking time for the standard library by ~3%.
Swift SVN r11098
