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
This implementation accepts more than it should, because we don't
reliably have enough information in the constraint solver to know
whether an argument is actually a trailing closure or not.
Swift SVN r17404
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
- 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
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
- Change the parser to unconditionally reject @mutating and @!mutating with a fixit and
specific diagnostic to rewrite them into the [non]mutating keyword.
- Update tests.
This resolves <rdar://problem/16735619> introduce nonmutating CS keyword and remove the attribute form of mutating all together
Swift SVN r16892
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
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
