Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This is necessary for some other work I'm doing, which really wants
paramdecls to have reasonable declcontexts. It is also a small step
towards generic subscripts.
to consolidate the kajillion places the allocate the decl for self.
- Move the ParamDecl ctor implementation out of line, since only one TU
calls it.
NFC.
is used by precisely one thing (producing a warning in a scenario that is obsolete
because we deprecated the entire thing), so the complexity isn't worth it anymore.
Previously, methods on DeclContext for getting generic parameters
and signatures did not walk up from type contexts to function
contexts, or function contexts to function contexts.
Presumably this is because SIL doesn't completely support nested
generics yet, instead only handling these two special cases:
- non-generic local function inside generic function
- generic method inside generic type
For local functions nested inside generic functions, SIL expects
the closure to not have an interface type or generic signature,
even if the contextual type signature contains archetypes.
This should probably be revisited some day.
Recall that these cases are explicitly rejected by Sema diagnostics
because they lack SIL support:
- generic function inside generic function
- generic type inside generic function
After the previous patches in this series, it becomes possible to
construct types that are the same as before for the supported uses of
nested generics, while introducing a more self-consistent conceptual
model for the unsupported cases.
Some new tests show we generate diagnotics in various cases that
used to crash.
The conceptual model might still not be completely right, and of
course SIL, IRGen and runtime support is still missing.
This would just set the NominalTypeDecl's declared type to
ErrorType, which caused problems elsewhere.
Instead, generalize the logic used for AbstractFunctionDecl.
This correctly wires up the GenericTypeParamDecl's archetypes even
if the signature didn't validate, fixing crashes if the generic
parameters of the type are referenced.
For better or worse, the type of a function can end up as ErrorType,
and the generic signature was not stored anywhere else, causing
crashes from orphaned generic type parameters.
This patch is the first in a series to make this more robust by
storing the generic signature before the interface type is computed.
A fixed layout type is one about which the compiler is allowed to
make certain assumptions across resilience domains. The assumptions
will be documented elsewhere, but for the purposes of this patch
series, they will include:
- the size of the type
- offsets of stored properties
- whether accessed properties are stored or computed
When -enable-resilience is passed to the frontend, all types become
resilient unless annotated with the @fixed_layout attribute.
So far, the @fixed_layout attribute only comes into play in SIL type
lowering of structs and enums, which now become address-only unless
they are @fixed_layout. For now, @fixed_layout is also allowed on
classes, but has no effect. In the future, support for less resilient
type lowering within a single resilience domain will be added, with
appropriate loads and stores in function prologs and epilogs.
Resilience is not enabled by default, which gives all types fixed
layout and matches the behavior of the compiler today. Since
we do not want the -enable-resilience flag to change the behavior
of existing compiled modules, only the currently-compiling module,
Sema adds the @fixed_layout flag to all declarations when the flag
is off. To reduce the size of .swiftmodule files, this could become
a flag on the module itself in the future.
The reasoning behind this is that the usual case is building
applications and private frameworks, where there is no need to make
anything resilient.
For the standard library, we can start out with resilience disabled,
while perfoming an audit adding @fixed_layout annotations in the
right places. Once the implementation is robust enough we can then
build the standard library with resilience enabled.
Revert "Fix complete_decl_attribute test for @fixed_layout"
Revert "Sema: non-@objc private stored properties do not need accessors"
Revert "Sema: Access stored properties of resilient structs through accessors"
Revert "Strawman @fixed_layout attribute and -{enable,disable}-resilience flags"
This reverts commit c91c6a789e.
This reverts commit 693d3d339f.
This reverts commit 085f88f616.
This reverts commit 5d99dc9bb8.
A fixed layout type is one about which the compiler is allowed to
make certain assumptions across resilience domains. The assumptions
will be documented elsewhere, but for the purposes of this patch
series, they will include:
- the size of the type
- offsets of stored properties
- whether accessed properties are stored or computed
When -enable-resilience is passed to the frontend, all types become
resilient unless annotated with the @fixed_layout attribute.
So far, the @fixed_layout attribute only comes into play in SIL type
lowering of structs and enums, which now become address-only unless
they are @fixed_layout. For now, @fixed_layout is also allowed on
classes, but has no effect. In the future, support for less resilient
type lowering within a single resilience domain will be added, with
appropriate loads and stores in function prologs and epilogs.
Resilience is not enabled by default, which gives all types fixed
layout and matches the behavior of the compiler today. Since
we do not want the -enable-resilience flag to change the behavior
of existing compiled modules, only the currently-compiling module,
Sema adds the @fixed_layout flag to all declarations when the flag
is off. To reduce the size of .swiftmodule files, this could become
a flag on the module itself in the future.
The reasoning behind this is that the usual case is building
applications and private frameworks, where there is no need to make
anything resilient.
For the standard library, we can start out with resilience disabled,
while perfoming an audit adding @fixed_layout annotations in the
right places. Once the implementation is robust enough we can then
build the standard library with resilience enabled.
This is all effectively NFC, but lays out the shape of the iterative
type checker: requests are packaged up in TypeCheckRequest, we can
check whether the request has been satisfied already (isSatisfied),
enumerate its dependencies (enumerateDependenciesOf) in terms of other
TypeCheckRequests, and satisfy a request (satisfy).
Lazily-computed semantic information is captured directly in the
AST, but has been set aside in its own structure to allow us to
experiment with moving it into a lookaside table.
The only request that exists now is to type-check the superclass of
the given class. It currently performs unhealthy recursion into the
existing type checker. As we detangle dependencies, this recursion
between the IterativeTypeChecker and the TypeChecker can go away.
Swift SVN r32558
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
Bitfield accessors are generated by Clang, but have a curried function
type Self -> * -> *. This isn't supported for ClangType AbstractionPatterns,
so just special case lowering these since they're so simple.
NFC until bitfields land.
Swift SVN r31764
We were memcopying a std::function into the the AST context memory,
which leaks memory incidentally used by the std::function
implementation. Fix by using a std::unique_ptr and registering a
destructor cleanup. Incidentally, I turned the array of functions into
a single function, since we never have more than one anyway.
rdar://problem/22387897
Swift SVN r31600
Create getters and setters for, and initializers taking, fields in
C unions. This doesn't yet fold anonymous unions' fields nested into
a struct, but it does open up APIs that were previously unavailable.
rdar://problem/19660119
Swift SVN r31396
Now that we have the inheritance lists hanging around, use them: it
makes the conformance lookup table use the same code whether we're
deserializing the conformances or parsing them.
Swift SVN r31383
The conformance lookup table is responsible for answering queries
about the protocols to which a particular nominal type conforms, so
stop storing (redundant and incorrect) protocol lists on the ASTs for
nominal types. Protocol types still store the list of protocols that
they inherit, however.
As a drive-by, stop lying about the number of bits that ProtocolDecl
uses on top of NominalTypeDecl, and move the overflow bits down into
ProtocolDecl itself so we don't bloat Decl unnecessarily.
Swift SVN r31381
We're no longer using this information for generic type parameters or
associated types, so there's no point in leaving this honeypot
around. Note that this information is redundant with what's in the
conformance lookup table already, so it will be going away soon.
Swift SVN r31334
The getConformsTo() callback was responsible for forcing the
collection of the requirements directly placed on an associated type,
which then get added to the archetype builder. This resulted in an
unhealthy dependency on the list of protocols attached to TypeDecl
(which should go away). Instead, retrieve the requirements from the
associated type's archetype (once it's been computed) or directly from
its list of "inherited" types (while we're building the generic
signature for the protocol itself).
Swift SVN r31332
- Disallow @objc on members of non-@objc protocols (the
real reason for this patch)
- Add a separate diagnostic for @objc appearing on members
in non-class, non-protocol types.
- Clean up the code that enforces that @objc can only be
applied to @objc-rooted classes. The diagnostic would
be incorrectly emitted for @objc subclasses of generic
classes.
Fixes <rdar://problem/17273524>.
Swift SVN r31303
This is a step toward weeding out the "getProtocols()" list on
TypeDecl. Now, use the Archetype's list of protocols for the set of
protocols to which the type parameter or associated type
conforms. Since that list is fully canonicalized, it's more generally
reliable. However, start serializing the list of inherited types for a
generic type parameter, so we can print it appropriately.
Swift SVN r31297
This reverts revision r30688. The patch needs more work, because it flags a
valid case as circular, see r15054, "Relax restriction on indirectly-self-
recursive protocol conformances. (rdar://problem/16306715)".
Swift SVN r30690
We have to check for cycles of length > 1 here. Also, add a bit to the
AssociatedTypeDecl to ensure the recursive requirement diagnostic is
only emitted once.
Fixes <rdar://problem/17986597>.
Swift SVN r30678
