Entities with shared linkage are allowed to be discarded if they are unused even
in a library context.
Previously we implemented this in the serializer, which introduced
needless complications. Now we leave that responsibility to the optimizer giving
simplicity.
Swift SVN r16150
1. We call DEBUG() so we should set DEBUG_TYPE.
2. Print out the function name when printing out its abbrCode, bitno, etc.
3. Dump the SIL after printing the function information. This makes it easier to navigate the resulting output.
Swift SVN r16102
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
... 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
around in the deserializer's .
1,2d
1i
Bump the reference count of a SILFunction as long as it's sitting
around in the deserializer's cache.
If we deserialize a function, then delete it, then deserialize
another reference to it, we'll end up pointing to a deleted
function. This was causing the bug where IRGen would assert
with "no order number for SIL function definition?"; I can't
seem to find a radar for that, though.
Also, deserialization test cases are hard to write and probably
inherently unstable.
Swift SVN r15908
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
This will be a signal to ARC optimization, RVO, and other lifetime-affecting optimizations that they should not shorten the lifetime of a value past a certain point. We need this for C pointer bridging. This adds the instruction, but does not add any knowledge of it to the ARC optimizers.
Swift SVN r15601
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
Via preprocessor goop, Serialization.cpp generates a set of static
functions that can be used to verify if a set of attributes
can be serialized for a particular declaration.
This design forces the author of the attribute to specify up front
whether or not an attribute is supported on a given declaration
kind. We can possibly hoist this into semantic analysis as well.
These N separate functions do conceptually replace a simple
variadic template implementation. I'm fine with alternatives,
but the goal was to provide a way for the author of new
attributes to describe the requirements in one place: Attr.def.
Swift SVN r15470
This patch adds in the necessary infrastructure for lazily deserializing
witness tables. This is done by following the same approach as the
deserialization/serialization of SILFunction.
Now if one calls SILModule::lookUpWitnessTable and the given witness table is a
definition, the SILModule will attempt to deserialize it from one of the other
modules.
Swift SVN r15403
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
