... and fix a few other bugs:
* always set the inherited protocols on the ProtocolDecl in the type checker,
so that we can remove a hack in ProtocolDecl::requiresClassSlow();
* diagnose DeclAttributes that are inverted when this is not allowed.
Swift SVN r15992
This allows us to consistently print the AST, no matter if it was just parsed
or deserialized.
Note that we still serialize the isObjC bit from Decl, because it can be set or
cleared by the typechecker. It is possible to have isObjC=true when there is
not attribute (the ObjC'ness was inferred), and it is possible that
isObjC=false while there is an attribute (when the attribute does not pass the
semantic check). While we can represent the former with an implicit attribute,
the latter is harder to represent (maybe with an invalid bit on the attribute?)
Swift SVN r15935
To generalize our serialization logic for more attributes, serialize
each DeclAttribute object in a separate bitcode record.
For simple declaration attributes (no arguments), all of this
serialization logic can be fully automatically generated, and is
done so in this patch. This currently includes @final, but will
expand over time.
To illustrate the plumbing end-to-end, move the serialization logic
for asmnmame over to the new mechanism.
Swift SVN r15933
More importantly, when writing substitution conformances /within the same
module/, use an "incomplete" form of the NormalProtocolConformance layout
that doesn't include any of the substitutions or defaulted definitions.
This avoids a serialization cycle when the witness for a protocol itself
ends up conforming to the protocol.
I couldn't come up with a reduced test cases, but both cases filed by Dave
now work.
<rdar://problem/16468715>
Swift SVN r15912
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
We can just get it from the instance type, if the instance type has been fully initialized, which is the case except during parsing of type decls when the decls' own types are being formed.
Swift SVN r15598
For example:
@class_protocol, @objc
is now just:
@class_protocol @objc
Once we removed attribute grouping in brackets this comma separation
became vestigial. Doug and I discussed this and thought this
was a good simplification in the grammar.
This change still remains to be done for type attributes.
Swift SVN r15540
This representation is inspired by Clang's internal representation.
The current attribute representation, which is basically a union
of "stuff" in DeclAttributes, is not amendable to richer
attributes, such as @availability, that need to be implemented.
In Clang, attributes are modeled with actual objects that
encode both semantic and syntactic information (e.g., source ranges)
that facilitate richer checking, better diagnostics, and better tools.
This change is foundational for implementing @availability, but
also is a better long-term representation. As a migratory path,
it creates some duplications, with AttrKind and DeclAttrKind, the
two which should eventually become the same thing.
As part of this patch, there is some additional parser recovery
(for the new attribute representation) for duplicate attributes.
The parser now parses the entire duplicate attribute, which could
be quite complex, and then issues a diagnostic that the attribute
is a duplicate (and discarding it). This delayed diagnostic
also allows us to present ranges for the duplicate attribute, which
provides a better user experience.
Swift SVN r15365
This fixes the following two bugs:
1. We sometimes would create new conformances when deserializing a
witness method which would not be mapped in the SILModule to the
appropriate witness table. This would cause us to be unable to perform
devirtualization of this witness method. This is tested via a new
verifier check.
2. Different conformances would be created for an instance of a base
protocol and the original protocol. This would cause IRGen to try to
emit witness table global variables with differing types, hitting an
assertion. This is tested via a traditional test.
Swift SVN r15362
Parse function declarations with the form
func murder inRoom(room: Int) weapon(Int) {}
where the function name ("murder") is separated from the parameter
names. This is the same style used in initializers, i.e.,
init withCString(cstr: CString) encoding(Encoding)
Swift SVN r15140
Instead of referencing them by name, serialize a reference to their
storage decl instead, then note which accessor to retrieve.
Uncovered by Chris's override work in r15051...thanks, Chris!
Swift SVN r15063
Previously, we were cloning the default arguments completely, which
meant code duplication (when inheriting within a module) or simply a
failure (when inheriting across modules). Now, we reference the
default arguments where we inherited them, eliminating the
duplication. Part of <rdar://problem/16318855>.
Swift SVN r15062
If a subclass defines no subobject initializers and all of its stored
properties have initial values, "inherit" all of the subobject
initializers of its superclass by creating a new initializer with the
same signature that overrides (and chains to) the corresponding
subobject initializer of its parent. Do this instead of blindly
creating a default initializer.
Note that we aren't yet doing this for generic initializers. That will
be a separate step.
Swift SVN r14995
Let ArchetypeType nested types and PotentialArchetypes be bound to concrete types in addition to archetypes. Constraints to outer context archetypes still suffer type-checker issues, but constraints to true concrete types should work now.
Swift SVN r14832
Before, we would hit one of the error conditions before updating the path
trace, which was misleading at best.
No functionality change.
Swift SVN r14815
The standard library likes to have default definitions for associated types,
which is good. Often the /choice/ of default type, however, is a type that
(indirectly) conforms to the very protocol containing the associated type.
Rather than try to make sure everything is present all at once, just delay
the deserialization of the default definition until it's actually requested.
This does swell the size of AssociatedTypeDecl by two words. I've filed
<rdar://problem/16266669> to remind myself to try to reduce this.
Part of <rdar://problem/16257259>
Swift SVN r14809
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
to the archetypes of their generic parameter declarations.
This was a major inconsistency that was causing a lot of
problems with deserialized generic functions in the presence
of chained module files. In particular, what would happen is
that all the deserialized uses of the archetype would be
mapped to a freshly-created archetype, but the GenericParamList
would refer to GenericTypeParamDecls deserialized from
(potentially) a different ModuleFile and therefore using a
different archetype (since the deserializer assumes that
different modules never share archetypes).
The fix relies on processing a generic parameter list before
any references to the archetypes. Unfortunately, we have
bogus references to archetypes in substitution lists scattered
everywhere in SIL and the AST. I've introduced a really
gross hack where we allow archetypes to be created in that
way but just drop them (in favor of the parameter's archetype)
after processing the generic parameter list; this should
work as long as all the decontextualized references are
basically pointless, but like I said, it's gross, and I've
filed rdar://16240384 to clean it up.
Swift SVN r14694
If we got just the wrong chain of dependencies, we'd create two VarDecls
for the same variable. I'm not sure if any of the other decls have the
same problem, but better safe than sorry.
I couldn't think of a small test case for this, but it does fix the one
in the Radar.
<rdar://problem/16205936>
Swift SVN r14625
The 'override' attribute indicates that the given declaration, which
may be a method, property, or subscript, overrides a declaration in
its superclass. Per today's discussion, the 'override' attribute must
be present if and only if the corresponding declaration overrides a
declaration in its superclass.
This implements most of <rdar://problem/14798539>. There's still more
work to do to on property and subscript overrides.
Swift SVN r14388
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from
the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're
serializing a complete definition. This fixes issues with us getting the
wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the
generic param list to correctly come before we check if the SILFunction block
is empty, and we add a kludge to keep the JIT from crapping itself when it sees
the same transparent definition in multiple REPL lines' modules
<rdar://problem/16094902>.
The previous commit solves a problem this exposed at r14050 in inout deshadowing
that caused memory corruption when transparent functions were imported. This
should now be safe to commit.
Swift SVN r14109
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the generic param list to correctly come before we check if the SILFunction block is empty, and we add a kludge to keep the JIT from crapping itself when it sees the same transparent definition in multiple REPL lines' modules <rdar://problem/16094902>.
Swift SVN r14030
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
This gets me a clean build when applied against r13984.
Swift SVN r14005
