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
argument list mismatches, and diagnose them with a very specific error when
they occur in member lookups. This fixes
<rdar://problem/22356434> QoI: Missing diagnostic for invalid arguments passed to enum case constructor
where before we'd produce:
ee.swift:5:16: error: type of expression is ambiguous without more context
let list: E = .C(wrongLabel: 0)
~^~~~~~~~~~~~~~~~
now we produce:
ee.swift:1:17: error: incorrect argument label in call (have 'wrongLabel:', expected 'label:')
let list: E = .C(wrongLabel: 0)
^~~~~~~~~~~
label
I think that unresolved member exprs now get good diagnostics in all cases that they have
a contextual type, but of course there are lots more cases where we're not getting a
contextual type.
Swift SVN r31402
We need to be able to introduce and eliminate existentials inside
reabstraction thunks, so make this logic independent of RValue
and Expr emission.
NFC for now.
Swift SVN r31375
conversions to and from UnresolvedType. This will allow UnresolvedType to be
used more aggressively and predictably by CSDiags. This is NFC, but used in
the next patch.
Swift SVN r31318
ConstraintSystem::applySolution into its own helper function to reduce
indentation and make ConstraintSystem::applySolution much more simple
and obvious. NFC.
Swift SVN r31290
allowing these failures to hook into other diagnostic goodies (e.g. the
"did you mean to use '!' or '?'?" cases showing in the testsuite). That said,
by itself this doesn't have a huge impact, but avoids regressions with other
pending changes.
Swift SVN r31289
node, abandoning the old node. This cuts of places where we'd end up retypechecking
the original expr and getting things like Builtin.Int2048 into the diagnostic.
This is NFC, because there is some crufty stuff avoiding this sitation in CSDiags that
needs to be removed for other reasons, this simply unblocks that.
I have a more aggressive approach in mind to actually fix how we model literals, but
that isn't on my short-term todo list.
Swift SVN r31270
This is a step towards partially-applying methods that return Self
on existentials.
- We model opening of both existential values and metatypes with
OpenExistentialExpr, but erasure had two forms, ErasureExpr and
MetatypeErasureExpr. Combine them into one, since both Sema and
SILGen have similar code paths for each.
- If the source type of an ErasureExpr is a closed existential,
have Sema emit an OpenExistentialExpr, and remove SILGen's
openExistentialForErasure() path, which mostly duplicates
openExistentialImpl().
- There was one difference between openExistentialForErasure() and
openExistentialImpl(). The former would emit the opaque value in
+0 context, and the latter in a +1 with initialization. The
previous patch ensures that visitOpaqueValueExpr() generates
equivalent code in both cases.
Swift SVN r31261
<rdar://problem/18397777> QoI: special case comparisons with nil
<rdar://problem/18042123> QoI: Fixit for "if !optional" should suggest "if optional == nil"
Swift SVN r31204
It's not /really/ an infix operator, but it behaves like a very low
precedence prefix operator. On the other hand, 'try' and 'try!' can
freely move in and out of all the operations we add in fix-its, so
don't bother.
rdar://problem/22259867
Swift SVN r31200
This allows us to remove the workaround generic overloads for "print" without sacrificing good diagnostics for its unavailable overloads. (rdar://problem/21499048, rdar://problem/21582758, rdar://problem/22126141)
Swift SVN r31169
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
no type set on them. This is the minimal fix to address the regressions
on two validation tests, but another approach (not involving null types)
seems like it would be a good idea to investigate on mainline.
Swift SVN r31099
And give a proper warning when you use 'try?' in a non-failable init.
And do the right thing when trying to SILGen 'try?' delegating to a
failable throwing init.
And make sure DI understands that this is, in fact, an initialization.
More rdar://problem/21692467
Swift SVN r31060
Fix construction and simplication of constructor member locators, so
that locators involving constructor members can be simplified during
diagnosis.
<rdar://problem/21427130> Swift can't discriminate on arity of function parameters
Swift SVN r30932
Instead of relying on the reference semantics of the base to make this decision, look at the getter and setter to see if either is mutating to decide whether the base of a property lookup should be inout. This should be the final fix for rdar://problem/21578832.
Swift SVN r30887
This came up with SourceKit fuzz testing on the stdlib. I don't have a
reduced testcase right now.
Progress on <rdar://problem/19554069>.
Swift SVN r30882
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
typeCheckExpression takes a convertType and a contextualType, but the only
client of contextualType is pattern binding initialization that wants to
provide a hint to the initializer, but the type may not be fully formed
(e.g. just Array instead of Array<Int>) so it can't provide a full
convertType to that type.
After trying various ways of eliminating the concept and failing, repaint it
instead: instead of typeCheckExpression taking *both* a convertType and a
contextualType (even though they are mutually exclusive), have it only take
a single convertType and add a bit to TypeCheckExprOptions to indicate whether
it is a hint or a strong conversion. This simplifies all the callers of
typeCheckExpression and makes further evolution simpler.
Swift SVN r30658
directly into the diagnostics subsystem. This ensures a more consistent
treatment of type printing (e.g. catches a case where a diagnostic didn't
single quote the type) and gives these diagnostics access to "aka".
Swift SVN r30609
- Have DiagnosticEngine produce "aka" annotations for sugared types.
- Fix the "optional type '@lvalue C?' cannot be used as a boolean; test for '!= nil' instead"
diagnostic to stop printing @lvalue noise.
This addresses:
<rdar://problem/19036351> QoI: Print minimally-desugared 'aka' types like Clang does
Swift SVN r30587
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
CSApply). The code is somewhat simpler there, more correct (fixing the FIXME in the
testcase) and doesn't run afoul of CSDiags trying to type check partial AST
subexpressions.
Swift SVN r30425
which allows solving of a constraint system to succeed without emitting
errors in the face of ambiguous solutions. This is important for CSDiag
because it is in the business of trying to solve subexpressions of a global
expression - and it wants to know the difference between a subexpression
that is inherently impossible to solve, vs one that is simply ambiguous
because its context has been removed.
Use this in CSDiag's typeCheckChildIndependently() to provide it an
extra flag that enables this behavior. This is currently unused, so NFC
with this patch.
Swift SVN r30402
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
Adjust our placement of RebindSelfInConstructorExpr to fall outside of
a force-value expression (!), allowing, e.g.,
self.init(somethingThatCanFail: x)!
and
super.init(somehtingThatCanFail: x)!
Start suggesting '!' when chaining/delegating to a failable
initializer from a non-failable one, in addition to suggesting that
the enclosing initializer become failable.
Note that DI cannot handle this yet, so this is only the Sema part of
rdar://problem/18497407.
Swift SVN r30219
