type is either a protocol type or a protocol composition type. The
long form of this query returns the minimal set of protocol
declarations required by that existential type.
Use the new isExistentialType() everywhere that we previously checked
just for ProtocolType, implementing the appropriate rules. Among other
things, this includes:
- Type coercion
- Subtyping relationship
- Checking of explicit protocol conformance
- Member name lookup
Note the FIXME for IR generation; we need to decide how we want to
encode the witnesses for the different protocols.
This is most of <rdar://problem/11548207>.
Swift SVN r2086
application expressions that provide a 'this' parameter to a
method. There will eventually be more than just DotSyntaxCallExpr, to
capture the other syntactic (and implicit) forms.
Swift SVN r1924
applies to operators whose first parameter is [byref]. Assignments
must return Void, and have their first arguments implicitly treated as
an lvalue.
As part of this, add the various C compound operators (+=, -=, *=, /=,
&=, |=, and ^=) to the standard library.
Swift SVN r1846
in general, not sound. For the limited cases where we did use this
expression kind on lvalues (member access or instance method
invocations on a superprotocol), leave the conversion to the client of
their respective AST nodes (MemberRefExpr, DotSyntaxCallExpr). We may
decide to enrich these ASTs in the future with more information about
the conversion path, but it's not clear that it's actually useful
information for, e.g., IRgen.
Swift SVN r1830
[byref(implicit)], and rely on type coercion for the implicit object
argument to deal with the implicitness. This is one half of
<rdar://problem/11215969>.
The other half of <rdar://problem/11215969> requires us to invent some
syntax to allow increment/decrement/assignment to operate on lvalues
without requiring one to write '&'. There are two distinct ideas
gaining traction here:
- Adding an [assignment] attribute to these operators, which tells
us both that use of the operators is a statement (not an
expression) and that the byref argument (either on the left, or
the only argument).
- Allowing operators to be written as member functions, so that they
get the same treatment as "a.b".
The former seems like the better option.
Swift SVN r1819
protocol Document { var title : String }
protocol Versioning { func bumpVersion() }
protocol VersionedDocument : Document, Versioning { }
This commit covers the basic functionality of protocol inheritance, including:
- Parsing & AST representation
- Conforming to a protocol also requires conforming to its inherited
protocols
- Member lookup into a protocol also looks into its inherited
protocols (results are aggregated; there is no name hiding)
- Teach ErasureExpr to maintain lvalueness, so we don't end up
performing a silly load/erase/materialize dance when accessing
members from an inherited protocol.
Swift SVN r1804
e.g. "foo is \(i+j)". This implements rdar://11223686
Doug implemented all the hard parts of this. I ripped out support for nested string
literals (i.e. string literals within an interpolated string), which simplified the
approach and defined away some problems with his patch in progress. I plan a few refinements
on top of this basic patch.
Swift SVN r1738
be lvalues (materializing them if necessary), as we do with subscript
expressions. Introduce a verifier for member expressions to make sure
this property holds.
Note that there is a slight regression in semantic analysis for
assignments to properties, because we no longer detect some cases of
writing into a property that should not be set. The general solution
to the problem is covered by <rdar://problem/11259972>.
Swift SVN r1530
- Ensure that the base is always an lvalue, materializing it if necessary
- Give appropriate lvalue qualifiers to the subscript expression
- Make sure to write the converted indices back into the AST
Finally, introduce a verifier for subscript expressions.
Swift SVN r1528
the appropriate slice type and check the bounds. The
first bound must be a literal or a type with a
getArrayBoundValue method, which has the same recursive
nature as getLogicValue (i.e. it can return a type that
has a getArrayBoundValue that returns an integral type,
but that's it; it's capped at one hop). The rest
of the bounds must be empty (meaning a slice) or
constant under the same conditions as fixed-size
array types.
Swift SVN r1501
oneof/struct/protocol within a static method. The lookup is performed
on the metatype (as one would get when using qualified syntax
Type.member). Add tests to verify that this provides proper
overloading behavior.
As a drive-by, actually set the type of the implicit 'this' variable
during name binding for a non-static method.
Swift SVN r1394
Unlike Type, it implements equality operators. It is returned by Type->getCanonicalType().
This adopts it in the minimal places required to get the build to work, it would also be nice
to switch IRGen to canonical types and use it there.
Swift SVN r1298
qualifier, making sure that variables end up so-qualified by
default. Add a RequalifyExpr to capture the act of adding
qualifiers (to form a supertype) to an l-value.
Swift SVN r1236
- introduce the concept of qualifiers on l-value types
- teach overload resolution and coercion how to drop explicitness
- require explicitness on normal [byref] arguments
- make 'this' [byref(implicit)]
- special-case '&' as a unary operator in the parser to make it
produce an expression which type-checks as turning implicit l-values
into explicit ones.
Obvious missing pieces:
- updating LangRef
- we should really complain about ever trying to rvalue-convert an
explicit l-value
- maybe qualification should play a part in overload resolution
- we should diagnose attempts to declare unary '&' operators
- there's a test case in expressions.swift which suggests my logic is
slightly off
But I am out of time, and these will have to wait.
Swift SVN r1119
instead .
1,2d
1i
Change the 'walk' APIs to use virtual dispatch instead of
blocks. This makes it much easier to thread information
through the API, as well to extend the API to handle
recursive visiting of other structures (e.g., Decls
and Patterns).
Swift SVN r1101
unconditionally so that we don't need to handle delegation
in the checkers just to preserve the standard checks.
Verify the invariants of a TupleElementExpr.
Swift SVN r874
statement walk callback functions, where we can stash additional
information without breaking all of the callers.
At present, the only information in the context is the parent
statement or expression.
Swift SVN r860
This will be required until there's some sort of error marking
in the AST, at which point that marking will just turn off
shouldVerify for that subtree.
Swift SVN r732
