The implicit default constructor shouldn't try to initialize static properties, and the implicit memberwise constructor shouldn't have arguments for static properties.
Swift SVN r10378
Introduced VarDecl::getTypeSourceRangeForDiagnostics(), which is not precise
right now; it just highlights the type source range of the typed pattern.
Filed rdar://15441111 to improve it in future.
Swift SVN r10344
This little "find the context where the generic parameters could be"
idiom was copy-pasted in a few places, which is ugly. And if we get
generic subscripts (or some other generic value decl), we'll be sorry.
Swift SVN r9927
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
All other interface types for type declarations were already
metatypes, as they should be; this oddity crept in. Kill it before it
causes more confusion.
Swift SVN r9826
Eliminate the annoying, rarely-firing "while converting 'var' initial
value to declared type" note. We'll eventually have better ways to
deal with this. Otherwise, no functionality change.
Swift SVN r9677
Rely on opening the GenericFunctionType of a method, rather than its
PolymorphicFunctionType. Alas, constraint application still falls back to
the PolymorphicFunctionType.
Swift SVN r9564
When the type checker sees a reference to a generic non-member
function, open its interface type, which is expressed as a
GenericFunctionType, rather than its PolymorphicFunctionType. This is
a tiny step toward weaning the type checker off archetypes within the
interface.
Swift SVN r9504
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Put generic nominal type declarations through the same dependent-type
validation as generic functions, then capture their generic parameters
and requirements in their generic signature. This allows us to
re-instate the requirements in their dependent forms, before the
archetypes ruin them completely.
Swift SVN r8958
When building the (dependent) interface type of generic functions,
don't resolve any generic parameter types to archetypes, even those at
outer levels. Instead, keep everything dependent.
As a special case, the type of 'self' gets baked into the parameter
patterns with archetypes, so reconstruct the 'self' type ourselves.
The actual output of this is still frustratingly untestable, but we
get decent coverage because all of the type checking of generic
functions goes through here first.
Swift SVN r8936
For derivable protocols, such as RawRepresentable on raw-typed enums, when checking the conformance, create a conforming decl if an explicit decl wasn't found. Refactor the conformance derivation for toRaw/fromRaw to be driven by conformance checking in this way.
Swift SVN r8930
If an enum has a valid raw type, synthesize a RawType associated type along with fromRaw and toRaw methods.
An implicit conformance to RawRepresentable is not yet set up. This synthesis may need to be done earlier in order for the names to be available during type-checking of definitions in the enum too.
Swift SVN r8890
Introduces a new kind of function type, GenericFunctionType, that
represents a polymorphic function type with all of its generic
parameters and requirements stored in a more readily canonicalizable
form. It is meant to eventually replace PolymorphicFunctionType, but
for now we build it up in parallel so we can switch over to it
pieacemeal.
Note: this representation is built and then thrown away. We'll start
recording it soon.
Swift SVN r8881
Attribute [transparent] on extensions should apply to all members(functions, properties) of that extension.
Addresses radar://15035271.
Swift SVN r8735
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
