This is fairly ugly, because we're halfway between a-function-type-takes-a-tuple and a-function-type-takes-a-set-of-parameters. However, it's another step toward -strict-keyword-arguments.
Swift SVN r17727
Introduce a new locator kind for argument/parameter comparisons that
tracks both the argument and the parameter, which we will eventually
use in diagnostics more regularly. For now, this helps us smooth over
scalar-to-tuple/tuple-to-tuple/tuple-to-scalar nonsense when dealing
with calls.
Fix a pile of fallout from this change.
Swift SVN r17648
We're going to want to re-use the argument/parameter matching of
matchCallArguments() elsewhere, so separate it from the constraint system.
Swift SVN r17626
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
Implement a completely new path for matching up an argument tuple to a
parameter tuple, which handles the specific rules we want for
calls. The rules are:
- The keyword arguments at the call site must match those of the
declaration; one cannot omit a keyword argument if the declaration
requires it, nor can one provide a keyword argument if the
declaration doesn't have one.
- Arguments must be passed in order, except that arguments for
parameters with defaults can be re-ordered among themselves (we
can't test all of this because neither constraint application nor
the AST can express these).
QoI is extremely important in this area, and this change improves the
situation considerably. We now provide good diagnostics for several
important cases, with Fix-Its to clean up the code:
- Missing keyword arguments:
t.swift:8:13: error: missing argument labels 'x:y:' in call
allkeywords1(1, 2)
^
x: y:
- Extraneous keyword arguments:
t.swift:17:12: error: extraneous argument labels 'x:y:' in call
nokeywords1(x: 1, y: 1)
^~~~ ~~~
- General confusion over keyword arguments (some missing, some
wrong, etc.):
t.swift:26:14: error: incorrect argument labels in call (have
'x:_:z:', expected '_:y:z:')
somekeywords1(x: 1, 2, z: 3)
^~~~
y:
There are still a few areas where the keyword-argument-related
diagnostics are awful, which correspond to FIXMEs in this
implementation:
- Duplicated arguments: f(x: 1, x: 2)
- Extraneous arguments: f(x: 1, y: 2, z: 3) where f takes only 2
parameters
- Missing arguments
- Arguments that are out-of-order
- Proper matching of arguments to parameters for diagnostics that
complain about type errors.
And, of course, since this has only been lightly tested, there are
undoubtedly other issues lurking.
This new checking is somewhat disjoint from what constraint
application can handle, so we can type-check some things that will
then fail catastrophically at constraint application time. That work
is still to come, as is the AST work to actually represent everything
we intend to allow.
This is part of <rdar://problem/14462349>.
Swift SVN r17341
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
double-quoted string literals that contain a single extended grapheme cluster
SEGCL by default infer type String, but you can ask to infer Character
for them.
Single quoted literals continue to infer Character.
Actual extended grapheme cluster segmentation is not implemented yet,
<rdar://problem/16755123> Implement extended grapheme cluster
segmentation in libSwiftBasic
This is part of
<rdar://problem/16363872> Remove single quoted characters
Swift SVN r17034
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
While diagnosing the cause of a constraint system failure, being able to ignore some failures but not others allows us to produce slightly better error messages in some cases. This is in support of JoeG's current work.
Swift SVN r15560
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
to a conversion restriction.
I'm pretty certain that this is *supposed* to be NFC, in that
any subtle differences between the two blocks are actually
inadvertent bugs.
Unify the two places that switch out on a conversion
restriction; I'm pretty sure they're supposed to be doing
the exact same thing, and that any differences between
flags/subFlags and whether to log the restriction kind
are inadvertent.
Swift SVN r14794
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
- 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
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
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
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
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
