When users invoke code completion at an argument position, we suggest argument names,
if required however not specified, or a list of argument values. These values are annotated
with their type relation to the expected argument types, so that
Xcode can prioritize those values that apply over those that do not.
This also fixes: rdar://21727063
Swift SVN r31505
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
<rdar://problem/21167372> transform EditorPlaceholderExpr into fatalError()
Swift SVN r31481
This allows tools, like code completion or jumping to definition, to be able to resolve
function names even though the argument is wrong.
Swift SVN r31387
When users complete the right-hand side of an assignment expression, we only
show the results whose types are convertible to those of the left-hand side.
Swift SVN r31357
Before this commit, for unresolved members, code completion suggests all visible enum elements
and option set types. To refine the results, this commit uses constraint solver to infer
the type of unresolved members by analyzing parental expressions. If the solver has solutions,
we complete the unresolved member, otherwise abort.
rdar://16659653
Swift SVN r31195
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31105
When CSGen was analyzing a DeclRefExpr reference, it was accidentally
applying some magic only to anonymous closure parameters, not named ones,
leading to a silent CSGen failure. Fix this by handling all closure parameters
the same way.
Swift SVN r31098
This bug triggered when three pre-conditions held:
- A protocol requirement method signature involves archetypes built
from associated types
- A protocol extension provides a default implementation of this method
- The method is called from another method in the same extension,
with a parameter of the associated type
In this case, the archetypes in the signature would match exactly
and we would end up picking the extension method over the protocol
method, which would not even be considered. As a result, the
extension method would be dispatch statically instead of using
witness method dispatch, which is wrong.
Hopefully one day we can model default implementations as real
overrides and not overloads.
Note that the test is a SILGen test even though the bug is in Sema,
since its easier to detect the problem at the SIL level.
Fixes <rdar://problem/21995666>.
Swift SVN r30847
to decide whether they're exhaustive.
Unfortunately, we can't actually just type-check the pattern
because it might be dependent on other local type-checking state,
like the types of arguments or variables defined within the closure.
So instead we try to recognize a very specific pattern shape that
should be safe to coerce.
Also, this potentially introduces redundant diagnostics because
of the double-check, but it's tricky to do anything about it.
I think it's better to have these potential redundancies than
to infer a throwing closure type with 'catch let e as NSError',
though.
rdar://21715350
Swift SVN r30701
diagnose problems inside of them instead of punting on them completely.
This leads to substantially better error messages in many cases, fixing:
<rdar://problem/19870975> Incorrect diagnostic for failed member lookups within closures passed as arguments ("(_) -> _")
<rdar://problem/21883806> Bogus "'_' can only appear in a pattern or on the left side of an assignment" is back
<rdar://problem/20712541> QoI: Int/UInt mismatch produces useless error inside a block
and possibly others. We are not yet capitalizing on available type information we do
have about closure exprs, so there are some cases where we produce
"error: type of expression is ambiguous without more context"
when this isn't strictly true, but this is still a huge step forward.
Swift SVN r30547
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
If a function declaration possessed default parameters, and was invoked with a single argument expression that was modeled as a type variable, the compiler would often crash during type application. This was due to the fact that during simplification, we would bind the type variable to the full tuple type of the parameter list. Later on, during constraint application, we would then look to whatever expression created the type variable for information on its default arguments - even if no such thing was possible. (E.g., we would examine, say, an IfExpr expecting to find information on its default arguments.) In these cases, we should have instead been binding the argument type variable to the first element of the parameter tuple.
Swift SVN r30486
with no returns *must* be (), add a defaulting constraint
so that it will be inferred as () in the absence of
other possibilities.
The chief benefit here is that it allows better QoI when
the user simply hasn't yet written the return statement.
Doing this does regress a corner case where an attempt
to recover from an uncalled function leads to the
type-checker inferring a result for a closure that
doesn't make any sense at all.
Swift SVN r30476
instead of treating it as an erroneous subexpr. This was causing <<error type>> to pop
out in diagnostics, and had a hackaround that dissolves now from CSDiags.
Swift SVN r30442
return statements, or a return statement with no operand.
Also, fix a special-case diagnostic about converting a return
expression to (1) only apply to converting the actual return
expression, not an arbitrary sub-expression, and (2) use the
actual operand and return types, not the drilled-down types
that caused the failure.
Swift SVN r30420
To support this, make 'try' and 'try!' no longer IdentityExprs
and give them a common base class to simplify the sorts of
analyses and transformations that do want to treat them
as identity-like.
Note that getSPE() still looks through normal 'try', since
the overwhelming proportion of clients will consider it
semantically equivalent to the undecorated expression.
Change getValueProvidingExpr() to look through try!, since
it's allowed to return something with slightly different
semantics, and use it in the unused-result diagnostic.
Fixes a large number of bugs, mostly uncaught, with SILGen
peepholes that use getSPE() and therefore were accidentally
looking through try!. <rdar://21515402>
Swift SVN r30224
Since each override of a subscript protocol requirement provides
its own materializeForSet, there is no need to do dynamic dispatch,
a peer call to the setter suffices. However, since CodeSynthesis
runs at the AST level, it would create a SubscriptExpr which
overload resolution would later bind to the protocol requirement
subscript rather than the static witness in the extension.
This triggered an assertion. Solve the problem by binding the
actual ConcreteDeclRef of the SubscriptExpr at synthesis time,
and modifying CSGen to special-case SubscriptExprs that already
have a ConcreteDeclRef set.
Fixes <rdar://problem/21370629>.
Swift SVN r29906
is an instance method. Make sure it's a non-static function before
attempting to strip the implicit self parameter from the type.
<rdar://problem/20886179> compiler error
Swift SVN r29732
First, fix a case of type checking an expression twice, which is against
the design of the type checker. We hit this because we can type check
the "context" in
let x = foo.#^COMPLETE^#
and then type check the "parsed expression", which is contained in the
context here.
Second, make the hack from rdar://20738314 more robust so that if we
*do* double typecheck for some reason we won't just choke on an
AutoClosureExpr. I filed rdar://21466394 to audit for other cases of
double typechecking and remove this hack.
Fixes rdar://21346928
Swift SVN r29527
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
Instead of forcing full application of '{super,self}.init' in the parser, and installing the RebindSelf semantic expr node early, make these constraints to Sema-time checks, and parse '<expr>.init' as a regular postfix production. This is a better separation of concerns, and also opens the door to supporting 'metatype.init()' in more general expression contexts (though that part still needs some follow-up sema work).
Swift SVN r29343
- Remove unused names.
- Define IDENTIFIER in terms of IDENTIFIER_WITH_NAME.
- Adjust each name to always match the corresponding value in case.
- Add an IDENTIFIER_ macro for the common case of defining an underscored name.
- Avoid creating names with double underscores, which are technically reserved
by the C++ standard.
There are two special cases I left in here for the identifiers '_code' and
'_domain'. I didn't want to call these simply 'Id_code' and 'Id_domain' for
fear someone would try to use them as 'code' and 'domain', so I made them into
'Id_code_' and 'Id_domain_' for now.
No intended functionality change.
Swift SVN r29291
We have an unreachable in the visitor for auto closures, so avoid
visiting it. It would be great to have a clearer picture of what needs
to happen for AutoClosure vs ClosureExpr. It's hard to tell exactly
where AutoClosure is supposed to be handled if at all.
Swift SVN r29037
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
