a reliable way to track whether a particular type has been
validated. Instead, add some bits to the type to indicate which stage
of checking it has received. I hate it, but it works and I don't know
of a better way to ensure that types get validated. This subsystem
will need to get rearchitected at some point (ugh).
Reduce the number of places where we build new BoundGenericTypes,
since they need to be validated fully to get substitutions, and then
introduces a number of validateTypeSimple() calls to validate types in
places where we know the validation will succeed, but we need that
information regardless.
Swift SVN r2681
parameters we're substituting. This is either "all levels" (when we're
substituting a specific base type in a member access) or "the
innermost level" (when we're substituting after deducing from a use or
application of a polymorphic function).
Swift SVN r2576
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
in SpecializeExpr, so that we have complete substitution and
protocol-conformance information. On the IR generation side, pass
witness tables for all of the archetypes (again, including derived
archetypes) into generic functions, so that we have witness tables for
all of the associated types.
There are at least two major issues:
(1) This is a terribly inefficient way to pass witness tables for
associated types. The witness tables for associated types should be
accessible via the witness tables of their parent. However, we need
more information in the ASTs here, because there may be additional
witness tables that will need to be passed for requirements that are
placed on the associated type by the generic function itself.
(2) Something about my test triggers a void/non-void verification failure
in the witness build for an instance function whose abstracted form
returns an associated type archetype and whose concrete form returns
an empty struct. See the FIXME in the test.
Swift SVN r2464
and derived) so they can be stored within the generic parameter list
for use 'later'.
More immediately, when we deduce arguments for a polymorphic function
type, check that all of the derived archetypes conform to all of the
protocol requirements, stashing that protocol-conformance information
in the coercion context (also for use 'later'). From a type-checking
perspective, we now actually verify requirements on associated types
such as the requirement on R.Element in, e.g.,
func minElement<R : Range requires R.Element : Ordered>(range : R)
-> R.Element
Swift SVN r2460
used in the very narrow case where we were converting from one
protocol type to another (super) protocol type. However, ErasureExpr
now handles this case via its null conformance entries (for the
"trivial" cases), and can cope with general existential types where
some conversions are trivial and others are not.
The IR generation side of this is basically just a hack to inline the
existing super-conversion code into the erasure code. This whole
routine will eventually need to be reworked anyway to deal with
destination types that are protocol-conformance types and with source
types that are archetypes (for generic/existential interactions).
Swift SVN r2213
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
