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
This works around a big performance regression in code completion
performance that was introduced with r25741. This hack does not work
completely correctly with multiple file builds, but a) this should be a
minor issue for enum code completions, and b) this simply returns to the
pre-25741 behaviour. This hack should disappear when we fix
rdar://problem/20047340.
For rdar://problem/20445407.
Swift SVN r27320
Instead of only honoring the last occurrence of -import-module, the frontend now
honors all occurrences of -import-module, making all of the modules specified on
the command line implicitly visible.
This fixes <rdar://problem/20422696>.
Swift SVN r27299
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
Refactor the Objective-C selector computation code for all forms of
methods, collapsing it into a single routine to eliminate
duplication. Test that we're computing Objective-C selectors for
throwing initializers correctly, as well as that we're printing the
appropriate Objective-C method declarations for throwing
initializers.
Swift SVN r27293
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
The Objective-C method corresponding to a throwing method has an extra
error parameter; note that within the arity mismatch diagnostic to
reduce head-scratching.
Swift SVN r27277
When computing an Objective-C selector for a throwing method,
introduce an "error:" selector piece at the location specified by the
foreign error convention. If it's part of the first selector piece,
append "WithError" to the method base name.
Also require the manually-specified @objc(selector) of a throwing
method to include a selector piece for the error parameter.
Swift SVN r27276
Previously, the only way to get initializers was completing after the
name of the type:
Foo#^complete_here^#
Foo(#^or_here^#
And now it will also work in unadorned expressions:
#^a_top_level_completion^#
bar(a, #^walked_into_a_bar^#
Unfortunately, not all our clients handle this well yet, so it's
protected by a language option.
-code-complete-inits-in-postfix-expr
Swift SVN r27275
... with disabled test 1_stdlib/Bit.swift for ios.
Most likely the problem of 1_stdlib/Bit.swift (only on armv7) is just uncovered by this change.
Unfortunately I have no possibility to debug the problem on a device. Therefore I filed rdar://problem/20521110
Swift SVN r27274
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
The protocol_lookup testcase from Interpreter test-cases exposed a bug when compiled with -O:
- SILCloner was generating an open_existential_ref from an open_existential_metatype instruction during cloning even if the existential in question was not a class existential.
Swift SVN r27266
The protocol_lookup the testcase from Interpreter test-cases exposed two bugs, once I tried to compiler with with -O:
- SILCloner was generating an open_existential_ref from an open_existential_metatype instruction during cloning even if the existential in question was not a class existential.
- DynamicCasts was not considering the fact that subclasses of a given class may implement a protocol, even if the class does not implement it.
Swift SVN r27260
Throwing @objc methods need to get mapped down to the Objective-C
runtime, so check that we can establish a foreign error convention for
them, and complain otherwise.
As a drive-by, don't allow any throwing function types to occur any
place else within @objc declarations.
Swift SVN r27259
FuncDecl::throws() is misleading because it only tells us whether the
'throws' keyword was present on the declaration. Since source
locations are lost during deserialization, it would give the wrong
result. Nobody was making this mistake now, but it's better not to
leave this trap in the ASTs.
Use AbstractFuncitonDecl::isBodyThrowing() to determine whether a
particular function (or initializer, eventually) can throw.
Swift SVN r27257
Make sure that a witness declaration is at least as available as
the protocol requirement declaration. This is analogous to requiring that an
override is at least as available as the base declaration.
We don’t use the RequirementMatch machinery to mark a candidate as unsafe but
rather let the witness be chosen and then diagnose for potential unavailability.
That is, potential unavailability will not affect the search for a candidate
witness to a requirement. This is less expressive (users cannot write a protocol
that selects an available implementation) but is more predictable.
Swift SVN r27256
A non-throwing function can be a trivial subtype of a throwing
function. Encode this rule more directly, introduce some additional
tests to ensure that we get the behavior right where we need exact
matches, and add a failure kind with custom diagnostic for cases where
function types mismatch due to 'throws'.
Swift SVN r27255
This is new attribute we're using to coalesce @thin, @objc_block, and @cc, and to extend to new uses like C function pointer types. Parse the new attribute, but preserve support for the old attributes, and print with the old attributes for now to separate out test changes. Migration fixits and test updates to come. I did take the opportunity here to kill off the '@cc(cdecl)' hack for AST-level function pointer types, which are now only spelt with @convention(c).
Swift SVN r27247
The only caveat is that:
1. We do not properly recognize when we have a let binding and we
perform a guaranteed dynamic call. In such a case, we add an extra
retain, release pair around the call. In order to get that case I will
need to refactor some code in Callee. I want to make this change, but
not at the expense of getting the rest of this work in.
2. Some of the protocol witness thunks generated have unnecessary
retains or releases in a similar manner.
But this is a good first step.
I am going to send a large follow up email with all of the relevant results, so
I can let the bots chew on this a little bit.
rdar://19933044
Swift SVN r27241
The two ways functions are created currently is via the two
SILModule::getOrCreateFunction(). One of the methods, takes in a raw mangled
name and uses that to create the function. The other takes in a SILDeclRef to
generate the mangled name. Most function emission (besides some thunk creation
functions) goes through the latter. For now we update the map there. This is ok,
since this map will only be used to provide extra verification that guaranteed
self is occuring everywhere that it is supposed to (since constructors and
destructors still have @owned self).
Swift SVN r27240
Consistently open all references into existentials into
opened-existential archetypes within the constraint solver. Then,
during constraint application, use OpenExistentialExprs to record in
the AST where an existential is opened into an archetype, then use
that archetype throughout the subexpression. This simplifies the
overall representation, since we don't end up with a mix of operations
on existentials and operations on archetypes; it's all archetypes,
which tend to have better support down the line in SILGen already.
Start simplifying the code in SILGen by taking away the existential
paths that are no longer needed. I suspect there are more
simplifications to be had here.
The rules for placing OpenExistentialExprs are still a bit ad hoc;
this will get cleaned up later so that we can centralize that
information. Indeed, the one regression in the compiler-crasher suite
is because we're not closing out an open existential along an error
path.
Swift SVN r27230
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
This is the same as the reverted r27216 except that it does not suggest a FixIt
to make the property lazy.
Swift SVN r27223
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
We can safely support potential unavailability on lazily initialized
properties (and statics), so suggest a Fix-It that adds a lazy attribute when
the property declaration allows for it.
Swift SVN r27216
We may want to use optimized ErrorType representations that don't naturally "become" NSErrors, such as tagged-pointer representations of small error enums, or a tagged function pointer to a deferred error type constructor. Rename the runtime function to something a bit more descriptive of its real purpose, not its implementation.
Swift SVN r27209
This avoids that an unoptimized imported function is linked instead the optimized version from the stdlib.
rdar://problem/20485253
It gives considerable performance improvmenets for some benchmarks with -Onone. E.g.
PopFrontUnsafePointer: +281%
ArrayOfPOD: +92%
StrComplexWalk: +91%
ArrayOfGenericPOD: +61%
Several others are within the range of +10% to +30%.
For the implementation I added runSILPassesForOnone() in Passes.cpp.
Here we can add other optimizations for -Onone in the future.
Swift SVN r27206
Remove the suppression of deprecation and potential unavailability diagnostics in
synthesized functions. We still suppress some explicit unavailability diagnostics -- those
in synthesized functions in synthesized functions that are lexically contained in
declarations that are themselves annotated as unavailable. For these cases, the right
solution <rdar://problem/20491640> is to not synthesize the bodies of these functions in
the first place.
rdar://problem/20024980
Swift SVN r27203
In source files that are in script mode, global variable initialization
expressions are eagerly executed. For this reason, disallow @availability
attributes having 'introduced=' on script-mode globals.
I had to rejigger a fair number of potential unavailability tests because they
weren't written with this distinction in mind.
Swift SVN r27137
Previous attempts to update the callgraph explicitly after calls to
linkFunction() weren't completely effective because we can deserialize
deeply and introduce multiple new function bodies in the process.
This gets us a bit closer, but only adds new call graph nodes. It does
not currently add edges for everything that gets deserialized (and this
is not fatal, so it is a step forward).
Swift SVN r27120
