As part of this, use a different enum for parsed generic requirements.
NFC except that I noticed that ASTWalker wasn't visiting the second
type in a conformance constraint; fixing this seems to have no effect
beyond producing better IDE annotations.
This eliminates some minor overheads, but mostly it eliminates
a lot of conceptual complexity due to the overhead basically
appearing outside of its context.
The main idea here is that we really, really want to be
able to recover the protocol requirement of a conformance
reference even if it's abstract due to the conforming type
being abstract (e.g. an archetype). I've made the conversion
from ProtocolConformance* explicit to discourage casual
contamination of the Ref with a null value.
As part of this change, always make conformance arrays in
Substitutions fully parallel to the requirements, as opposed
to occasionally being empty when the conformances are abstract.
As another part of this, I've tried to proactively fix
prospective bugs with partially-concrete conformances, which I
believe can happen with concretely-bound archetypes.
In addition to just giving us stronger invariants, this is
progress towards the removal of the archetype from Substitution.
A protocol conformance needs to know what declarations satisfy requirements;
these are called "witnesses". For a value (non-type) witness, this takes the
form of a ConcreteDeclRef, i.e. a ValueDecl plus any generic specialization.
(Think Array<Int> rather than Array<T>, but for a function.)
This information is necessary to compile the conformance, but it causes
problems when the conformance is used from other modules. In particular,
the type used in a specialization might itself be a generic type in the
form of an ArchetypeType. ArchetypeTypes can't be meaningfully used
outside their original context, however, so this is a weird thing to
have to deal with. (I'm not going to go into when a generic parameter is
represented by an ArchetypeType vs. a GenericTypeParamType, partially
because I don't think I can explain it well myself.)
The above issue becomes a problem when we go to use the conformance from
another module. If module C uses a conformance from module B that has a
generic witness from module A, it'll think that the archetypes in the
specialization for the witness belong in module B. Which is just wrong.
It turns out, however, that no code is using the full specializations for
witnesses except for when the conformance is being compiled and emitted.
So this commit sidesteps the problem by just not serializing the
specializations that go with the ConcreteDeclRef for a value witness.
This doesn't fix the underlying issue, so we should probably still see
if we can either get archetypes from other contexts out of value witness
ConcreteDeclRefs, or come up with reasonable rules for when they're okay
to use.
rdar://problem/23892955
Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
to check the implicit bit for decls, because otherwise we'd consider
params declared with a name of `self` as being "the self parameter".
This is trivial, except for the fact that we don't serialize the
implicit bit on parameters. I can't bring myself to burn encoding
space for this (particularly since we shouldn't be encoding self
decls in the first place!), so make the deserializer infer this bit
instead.
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.
Rather than plumbing a "has missing required members" flag all the way
through the LazyResolver's loadAllMembers and its implementations,
just eagerly update the "has missing required members" flag in the
Clang importer when it happens. More NFC cleanup.
The issue: we're apparently not keeping the archetypes in an instruction in sync
with the archetypes used in the SIL function's generic signature. This apparently
isn't the problem, but it's a good assertion to have, if a little ad hoc.
(The actual issue is rdar://problem/23892955.)
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.
Modeling nonescaping captures as @inout parameters is wrong, because captures are allowed to share state, unlike 'inout' parameters, which are allowed to assume to some degree that there are no aliases during the parameter's scope. To model this, introduce a new @inout_aliasable parameter convention to indicate an indirect parameter that can be written to, not only by the current function, but by well-typed, well-synchronized aliasing accesses too. (This is unrelated to our discussions of adding a "type-unsafe-aliasable" annotation to pointer_to_address to allow for safe pointer punning.)
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
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
GenericSignature's factory method determining whether the signature
was canonical based solely on whether the types in the parameters and
requirments were canonical. While that is currently true (for legacy
reasons), it is wrong: canonicalization also needs to canonicalize
requirements, including same-type requirements, as is currently done
in the canonical signature "for mangling". Move the "this is
canonical" dependency to the point where the canonical signature is
actually computed, so we can change the definition of canonical
signatures later.
While we're here, don't eagerly compute the canonical generic
signature in GenericSignature::getASTContext().
Swift SVN r32309
Apart from being general compile-time goodness, this helps break a
circularity issue involving serialization cross-references and the
Clang importer.
The test is being added to validation-tests because it relies on
several levels of non-laziness in the compiler, all of which we'd
like to fix. It's making sure we don't regress here, but it isn't
actually verifying this change in particular.
rdar://problem/22364953
Swift SVN r31455
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
These never appear in Swift code, but they can appear when serializing the
full output of SILGen ("SIB" format) because that includes code synthesized
for imported Clang declarations.
rdar://problem/22098491
Swift SVN r31364
This provides better AST fidelity through module files and further
reduces our dependencies on storing a list of protocols on nominal
type declarations.
Swift SVN r31345
This improves the fidelity of the AST printed from a loaded module, as
well as consistency in the AST. Also teach the Clang importer to add
"inherited" clauses, providing better fidelity for the mapping from
Objective-C to Swift.
With trivial update to SDKAnalyzer test.
Swift SVN r31344
This improves the fidelity of the AST printed from a loaded module, as
well as consistency in the AST. Also teach the Clang importer to add
"inherited" clauses, providing better fidelity for the mapping from
Objective-C to Swift.
Swift SVN r31337
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
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 is mostly a "don't crash" commit, but since member XREFs don't
specify which module they're looking in, they can actually pick up
members from the module currently being compiled...which may not have
a type yet.
rdar://problem/21071045
Swift SVN r30895
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
Otherwise the verifier can crash because hasType() returns true but
getType() gives us a MetatypeType that hits a null pointer in
desugaring.
The computeType() calls appear in a few too many places for my liking;
would be nice to clean this up further or replace everything with
interface types one day.
Fixes <rdar://problem/19606899>.
Swift SVN r30388
This changes the behavior to match NominalTypeDecls, which don't have a type
until everything is set up either. In a few places we construct TypeAliasDecls
from known types directly, and we have to call computeType().
Fixes <rdar://problem/19534837>.
Swift SVN r30386
Add a new convention to describe what happens with
nonzero_result on a type that isn't imported as Bool.
This isn't really a safe convention to implement, but
calls are fine.
Implements <rdar://21715350>.
Swift SVN r29953
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
This time, fix a paste-o that caused SILBlockStorageTypes to get replaced with SILBoxTypes during type substitution. Oops.
Swift SVN r29489
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
Swift SVN r29474
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
