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
This commit adds a new expression (AvailabilityQueryExpr) and a single kind of
specification for when a block of code or function is available
(VersionConstraintAvailabilitySpec). We may add more kinds of specifications
in the future. At the moment, the AvailabilityQueryExpr allows only a
single platform to be queried; I will add support for multiple platforms
in a later commit.
This commit contains just the added AST nodes; no parsing, type checking, etc.
I’ve added assert(false && “Unimplemented”) for places where support for
AvailabilityQueryExpr will need to be added later.
Swift SVN r21760
A "super" expression may refer not only to a super instance object, but a super metatype object as well. Fixes rdar://problem/17599865.
Swift SVN r21559
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
The fix is to detect this case and return the source's full source location. Otherwise it returns the source location using the destination's start and source's end.
Also modified LLDB's swift build to build the tests for any builds with asserts enabled so we can run the swift tests to ensure no breakage in the future.
Swift SVN r19136
This allows us to cast an AnyObject (or optional thereof) down to a
specific array, e.g.,
if let strArr = obj as String[] { ... }
Addresses most of <rdar://problem/16952771>.
Swift SVN r18397
As part of this, use tail allocation to reduce the memory footprint of
TupleExprs. Use factory methods to make it easier to construct.
I'll be using this information in a follow-on patch. SourceKit
probably wants it as well.
Swift SVN r17129
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
Building on previous work, this allows us to properly handle things like Int?() and Int[]().
Of course doing this exposed that TypeExpr was not correct in lots of ways, so this also:
- Revamps TypeExpr processing to carry a decl in the TypeLoc instead of
carrying a Type. This allows us to correctly handle more complex generics case.
- Enhances CSGen to properly open generic types so we can infer generic type parameters from
context.
Swift SVN r17019
and teach type checking to resolve TypeExprs that lack TypeReprs.
This gets us debugged enough to start shoving all local type references
down the TypeExpr path, which is significant progress.
Swift SVN r16958
them with uses of TypeExpr instead. The remaining uses of
MetaTypeExpr (which will be renamed soon) are places where we
are applying the ".dynamicType" virtual property to an expression.
Unadorned uses of types in code, e.g. the Int in "Int.self" are
now represented with TypeExpr.
One unfortunate travesty that doing this work revealed is that we
are extremely sloppy and terrible about maintaining location information
in implicitly generated decls, and our invariants vary quite a bit. This
is really horrible, but I'm not sure whether I'll go fix the hacks or not.
This patch perpetuates the existing crimes, but makes them more visible.
NFC!
Swift SVN r16646
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
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
Teach name lookup to find complete object initializers in its
superclass when the current class overrides all of the subobject
initializers of its direct superclass.
Clean up the implicit declaration of constructors, so we don't rely on
callers in the type checker doing the right thing.
When we refer to a constructor within the type checker, always use the
type through which the constructor was found as the result of
construction, so that we can type-check uses of inherited complete
object initializers. Fixed a problem with the creation of
OpenExistentialExprs when the base object is a metatype.
The changes to the code completion tests are an improvement: we're
generating ExprSpecific completion results when referring to the
superclass initializer with the same signature as the initializer
we're in after "super.".
Swift SVN r14551
Factor an IdentityExpr base class out of ParenExpr, and migrate most of the logic to see through ParenExprs to see through IdentityExprs instead. Add DotSelfExpr as a new subclass of IdentityExpr, produced by parsing 'x.self'.
Swift SVN r14381
