Take expression depth and preorder traversal index into account when
deciding which unresolved overload to complain about, rather than giving
up if there are two exprs with the same number of overloads. Don't
consider solutions with fixes when emitting ambiguous-system
diagnostics.
Swift SVN r30931
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
Just like enums with integer raw values can get autoincrementing case values,
enums with string raw values get the name of the element. The name is /not/
prefixed with the enum type because the purpose is presumably to interoperate
with a string-based system, which may require either writing or printing the
raw value as a string.
If an enum's raw type is both integer literal convertible and string literal
convertible, the integer side wins. That is, elements without raw values
will get auto-incremented integer values, rather than string values, and will
produce an error if an auto-incremented value cannot be generated.
rdar://problem/15819953
Swift SVN r29542
This makes it clearer that expressions like "foo.myType.init()" are creating new objects, instead of invoking a weird-looking method. The last part of rdar://problem/21375845.
Swift SVN r29375
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, provide the location of the { in a closure expr to the argument formation as
part of the datastructure already used to manage implicit closure arguments in the parser.
Swift SVN r28818
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
a list of their elements, instead of abusing TupleExpr/ParenExpr
to hold them.
This is a more correct representation of what is going on in the
code and produces slightly better diagnostics in obscure cases.
However, the real reason to fix this is that the ParenExpr's that
were being formed were not being installed into the "semantic"
view of the collection expr, not getting type checked correctly,
and led to nonsensical ParenExprs. These non-sensical ParenExprs
blocked turning on AST verification of other ones.
With this fixed, we can finally add AST verification that
IdentityExpr's have sensible types.
Swift SVN r27850
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
On platforms that are not explicitly mentioned in the #os() guard, this new '*'
availability check generates a version comparison against the minimum deployment target.
This construct, based on feedback from API review, is designed to ease porting
to new platforms. Because new platforms typically branch from
existing platforms, the wildcard allows an API availability check to do the "right"
thing (executing the guarded branch accessing newer APIs) on the new platform without
requiring a modification to every availability guard in the program.
So, if the programmer writes:
if #os(OSX >= 10.10, *) {
. . .
}
and then ports the code to iOS, the body will execute.
We still do compile-time availability checking with '*', so the compiler will
emit errors for references to potentially unavailable symbols in the body when compiled
for iOS.
We require a '*' clause on all #os() guards to force developers to
"future proof" their availability checks against the introduction of new a platform.
Swift SVN r26988
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
If the placeholder is a typed one, parse its type string into a TypeRepr,
resolve it during typechecking and set it as the type for the associated EditorPlaceholderExpr.
Swift SVN r26215
We parse 'try' as if it were a unary operator allowed on an
arbitrary element of an expr-sequence, but sequence-folding
constrains it to never appear on the RHS of most operators.
We do allow it on the RHS of an assignment or conditional
operator, but not if there's anything to the right which
was not parsed within the RHS.
We do this for assignments so that
var x = try whatever
and
x = try whatever
both work as you might expect.
We do this for conditionals because it feels natural to
allow 'try' in the center operand, and then disallowing it
in the right operand feels very strange.
In both case, this works largely because these operators are
assumed to be very low-precedence; there are no standard
operators which would parse outside the RHS. But if you
create one and use 'try' before it, we'll diagnose it.
Swift SVN r26052
This re-applies r24987, reverted in r24990, with a fix for a spuriously-
introduced error: don't use a favored constraint in a disjunction to avoid
applying a fix. (Why not? Because favoring bubbles up, i.e. the
/disjunction/ becomes favored even if the particular branch is eventually
rejected.) This doesn't seem to affect the outcome, though: the other
branch of the disjunction doesn't seem to be tried anyway.
Finishes rdar://problem/19600325
Swift SVN r25054
And even if we don't suggest wrapping in a closure (say, because there's
already a closure involved), emit a more relevant diagnostic anyway.
(Wordsmithing welcome.)
Wrapping a function value in a closure essentially explicitly inserts a
conversion thunk that we should eventually be able to implicitly insert;
that's rdar://problem/19517003.
Part of rdar://problem/19600325
Swift SVN r24987
Previously, if we created an implicit tuple (i.e. no paren locations) and
exactly one of the first and last arguments had a valid location, we would
return an invalid SourceRange (one part valid, the other not). If we end
up in this situation (and the playground transform can) just return an
invalid range instead (as if the tuple were fully compiler-generated).
rdar://problem/19587250
Swift SVN r24703
propagate the no-escape bit from a parameter into a closure-expr argument. When a
ClosureExpr is thus inferred to be non-escape, disable the "self." requirement.
.. with fixes. Thanks again to Dmitri for reverting + adding testcase.
Swift SVN r24115
closure-expr argument. When a "
This reverts commit r24085. It causes crashes in the validation
testsuite even with r24094. Testcase:
var x = { f: Int {} }
Swift SVN r24102
Provides consistency in behavior, particularly in enum raw values, where we reject non-literals. Factor out a common NumberLiteralExpr base for integer and float literals that handles the common sign and representation stuff. Fixes rdar://problem/16504472.
Swift SVN r23390
Though the value may be statically known in some cases, that isn't good enough to do what we try to do with this information. In particular, if we invoke a class method on a MetatypeConversion, we want to dispatch to the method of the original metatype, not statically call the method of the converted type, which is what is evident in the AST. Fixes rdar://problem/18877135.
Swift SVN r23277
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
This patch extends the AST and parsing of #os(...) queries to permit queries for
multiple platforms, e.g., #os(OSX >= 10.10, iOS >= 8.0). It also improves
parsing error recovery.
Swift SVN r22154
