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
Based on Dave’s hack, this allows one to define a “default implementation” as, e.g.,
protocol P {
func foo()
}
extension P {
final func foo() { … }
}
Swift SVN r28949
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
When reading the generic parameters of a constrained protocol
extension, cross-refencing an associated type would perform name
lookup into the protocol extension itself, causing fatal recursion
during deserialization. Fixed by avoiding additional deserialization
when looking for an associated type. Fixes rdar://problem/20812303.
Swift SVN r28228
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
preserve the original method name.
This heuristic is based on the Objective-C selector and therefore
doesn't really handle factory methods that would conflict with
initializers, but we can hope that those simply don't come up in
the wild.
It's not clear that this is the best thing to do --- it tends to
promote the non-throwing API over what's probably a newer, throwing
API --- but it's significantly easier, and it unblocks code without
creating deployment problems.
Swift SVN r28066
When deserializing a protocol, the conformance lookup table would not
contain entries for the inherited protocols of that protocol. They
were stashed in the "Protocols" array in TypeDecl (which will
eventually go away), but since there are no conformances for a
protocol, the conformance lookup table never got updated.
Nothing important seems to query this now; that will change soon.
Swift SVN r27967
Printing a module as Objective-C turns out to be a fantastic way to
verify the (de-)serialization of foreign error conventions, so
collapse the parsing-driving Objective-C printing test of throwing
methods into the general test for methods.
Swift SVN r27880
Printing a module as Objective-C turns out to be a fantastic way to
verify the (de-)serialization of foreign error conventions, so
collapse the parsing-driving Objective-C printing test of throwing
methods into the general test for methods.
Swift SVN r27870
Extensions cannot be uniquely cross-referenced, so cross-references to
extensions are serialized with the extended nominal type name and the
module in which the extension resides. This is not sufficient when
cross-referencing the generic type parameters of a constrained
protocol extension, because we don't know whether to get the
archetypes of the nominal type or some extension thereof. Serialize
the canonical generic signature so that we can pick an extension with
the same generic signature; it doesn't matter which we pick, so long
as we're consistent.
Fixes rdar://problem/20680169. Triggering this involves some
interesting interactions between the optimizer and standard library;
the standard library updates in the radar will test this.
Swift SVN r27825
the printed interface.
Previously we printed the typechecked and uniqued requirements and the result was non-sensical.
Long-term the requirements will be preserved in a better form but for now print the requirements
and serialize them.
rdar://19963093
Swift SVN r27680
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Move the map that keeps track of conforming decl -> requirement from ASTContext
to a nominal type's ConformanceLookupTable, and populate it lazily.
This allows getSatisfiedProtocolRequirements() to work with declarations from module files.
Test on the SourceKit side.
Part of rdar://20526240.
Swift SVN r27353
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
This is an internal-only affordance for the numerics team to be able to work on SIMD-compatible types. For now, it can only increase alignment of fixed-layout structs and enums; dynamic layout, classes, and other obvious extensions are left to another day when we can design a proper layout control design.
Swift SVN r27323
Currently untestable (due to SILGen's inability to handle throwing
@objc methods), but testing will become trivial once that's in place.
Swift SVN r27294
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
Currently untestable (due to SILGen's inability to handle throwing
@objc methods), but testing will become trivial once that's in place.
Swift SVN r27290
