I can't actually reproduce the buildbot failure that happened last night, so
hopefully it will (a) happen again, so I can investigate, or (b) not happen
again.
Swift SVN r22230
FixNum.h and BCRecordLayout.h will move down into LLVM, APINotes
will move into Clang. Get the namespaces right before we start to move
files around.
Swift SVN r22218
conformances (22195 to 22199).
It broke tests:
Failing Tests (4):
Swift :: Interpreter/SDK/Foundation_NSString.swift
Swift :: SIL/Serialization/deserialize_appkit.sil
Swift :: SIL/Serialization/deserialize_foundation.sil
Swift :: stdlib/NSStringAPI.swift
Swift SVN r22214
Doug had changed the comment but not the implementation -- we were still
serializing the containing module rather than the declaring nominal or
extension.
Found by enabling verification on deserialized decls (to come soon).
Swift SVN r22198
Previously, we depended on whether or not a serialized module was located
within a framework bundle to consider whether or not it may have a "Clang
half". However, LLDB loads serialized modules from dSYM bundles. Rather
than try to figure out if such a module is "really" a framework, just track
whether the original module was built with -import-underlying-module. If so,
consider the underlying Clang module to be re-exported.
rdar://problem/18099523
Swift SVN r21544
I'm not quite sure how to tickle this one, but the next commit adds more
data after the cached header, at which point existing tests break. This
could have already caused problems if no padding was needed in the bitstream.
Swift SVN r21543
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
We now have this information during parsing and throw it away during deserialization. This half-baked state works because all non-generic-extension clients only care about the module context.
Swift SVN r20833
Previously, we only retained the module in which a normal protocol
conformance occurred, which meant we either had to go searching for
the appropriate extension (yuck) or do without that information. This
is part of the separating-extension-archetypes work.
Swift SVN r20793
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
to emit fixit's when we rename something, e.g.:
t.swift:6:9: error: 'float' has been renamed to Float
var y : float
^~~~~
Float
Adopt this in the stdlib.
Swift SVN r20549
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
To answer "did the user specify this, or is it implicit", stick a couple
of is-implicit bits in InfixOperatorDecl, and thread them through
serializaton/deserialization.
Swift SVN r20067
Also:
- merge the test/decl/func/functions_new.swift testcase into test/Sema/immutability.swift,
where the bulk of similar tests are.
- Move the type checking logic for 'dynamic' out of ValidateAttrs into TypeCheckAttrs
- Change the encoding for 'override' to 49 so that stuff vbr's so much more densely :-)
Swift SVN r20006
attribute. As part of this, introduce a new "NotSerialized" flag in Attr.def.
This eliminates a bunch of special case code in the parser and elsewhere for handling
this modifier.
Swift SVN r19997
them to cover all declaration types.
This ensures that we reject attributes on declkinds where they don't make sense. I went so far
as to make the QoI decent when an attribute can only be applied to a single kind of declaration
to make sure the error message says "@IBAction is only valid on 'func' declarations" as well.
This resolves <rdar://problem/17681151> 'dynamic' accepted by the compiler where it shouldn't be
Swift SVN r19982
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
We still have type checker support for user-defined conversions,
because the importer still synthesizes __conversion functions for CF
<-> NS classes.
Swift SVN r19813
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
