Another baby step toward <rdar://problem/14462349>, made even more
tepid by the fact that I've quarantined this behind a new flag,
-strict-keyword-arguments. Enforcing this breaks a lot of code, so I'd
like to bring up the new model on the side (with good diagnostics that
include Fix-Its) before trolling through the entire standard library
and testsuite to fix violations of these new rules.
Swift SVN r17143
This is the simplest case to test the infrastructure for
adding/removing/fixing keyword arguments at the call site that don't
line up with the keyword arguments in a declaration. Baby steps toward
<rdar://problem/14462349>.
Swift SVN r17136
Fixes <rdar://problem/15042686>, i.e.,
t.swift:3:7: error: call to non-function of type 'Int'; did you mean
to leave off the '()'?
i = i()
^~~
Swift SVN r16950
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
Example:
test/Constraints/fixes.swift:54:9: error: value of optional type 'B?'
not unwrapped; did you mean to use '!' or '?'?
b = a as B
^
!
Swift SVN r16938
Introduce some infrastructure that allows us to speculatively apply
localized fixes to expressions during constraint solving to fix minor
typos and omissions. At present, we're able to introduce the fixes
during constraint simplification, prefer systems with fewer fixes when
there are multiple fixes, and diagnose the fixes with Fix-Its.
Actually rewriting the AST to reflect what the Fix-Its are doing is
still not handled.
As a start, introduce a fix that adds '()' if it appears to have been
forgotton, producing a diagnostic like this if it works out:
t.swift:8:3: error: function produces expected type 'B'; did you mean
to call it with '()'?
f(g)
^
()
Note that we did regress in one test case
(test/NameBinding/multi-file.swift), because that diagnostic was
getting lucky with the previous formulation.
Swift SVN r16937
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
Originally, I didn't want this because I felt it made
unchecked-optional too non-local --- it wasn't always
obvious that an assignment might crash because it was
implicitly dropping optionality. And that's still a
concern! But I think that overall, if we're prepared
to accept that that danger is inherent in @unchecked T?,
this is a more consistent model: @unchecked T? means
that we don't know enough about the value to say for
certain that nil is a real possibility, so we'll let
you coerce it to the underlying type, and that coercion
just might not be dynamically safe. No more special
cases for calls and member access (to the user; of
course, to the implementation these are still special cases
because of lookup and overload resolution).
Swift SVN r14796
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
- 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
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
- 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
Using "T" as the contextual type, either for an implicit conversion
(in the coercion case) or as a downcast (for the checked-cast case),
opens up more type-inference opportunities. Most importantly, it
allows coercions such as "1 as UInt32" (important for
<rdar://problem/15283100>). Additionally, it allows one to omit
generic arguments within the type we're casting to.
Some additional cleanup to follow.
Swift SVN r10799
Constraints move between the active and retired lists fairly often, so
use a doubly-linked list to eliminate memory traffic and O(n) copies
of constraint pointers between the lists by using splicing instead.
Swift SVN r10715
Rather than introducing a new type variable for every
applicable-function constraint's input type, place the actual argument
type into that position instead. Aside from eliminating a useless type
variable, this is a step toward further improvements with function
application.
Note that there are a few issues uncovered or introduced by this
patch. It makes <rdar://problem/15172575> slightly worse, which caused
the change in GetOpt where we were getting away with overloading on T
vs. T?. It also makes our recovery for code-completion purposes worse
in one of the tests, but this is a general problem
(<rdar://problem/15470973>).
Swift SVN r10462
Similar to the T -> U? conversion, allow T? to be converted to U? through a bind-convert-inject chain. Naively adding this conversion creates ambiguities in the type checker, opening up multiple paths to the same solution in certain cases, so add a a special case to the solver that avoids introducing the conversion if a solution is already available by other means. (Doug figured out that part; thanks Doug!)
This still introduces a regression in test/Constraints/optional.swift, rendering a call ambiguous when overloaded on argument types. <rdar://problem/15367036>
Swift SVN r9857
The "conversion" constraint was far too loose, because we don't want
to permit arbitrary conversions on the left-hand side of the
'.'. Conformance constraints aren't correct either, because an
existential that does not conform to itself can still be used on the
left-hand side of a '.', so we introduce a new kind of constraint for
this.
Swift SVN r9630
The constraint solver was eagerly applying the T -> U? conversion
rule, which only succeeds when T is convertible to U. Thus, we would
reject valid code where T has a user-defined conversion to
U?. Instead, introduce a disjunction conversion to try either T -> U?
by converting T to U or via a user-defined conversion.
Most of this is infrastructure for the introduction of constraint
restrictions, which specify that a particular constraint (say, a
conversion constraint) should only try a single direct path:
scalar-to-tuple, value-to-optional, user-defined, etc. Each term in the
disjunction created for the T -> U? case is restricted to a particular
conversion rule, so that checking it does not create another
disjunction.
Keep track of the constraint restrictions we used within a given
solution, so that we can replay those steps during the application
phase. There is a bunch of inactive code here at the moment, which
will become useful as we start creating disjunctions for other
ambiguous conversions.
Swift SVN r9318
Overload bindings constraints bind a given type to a specific overload
choice. This is a step toward moving overload sets into normal
disjunction constraints.
Part of the work here is to eliminate the constraint system's
dependence on OverloadSet, which will be going away in favor of a
disjunction constraint.
Swift SVN r9209
