Also, hide an initializer on String.Index that was unintentionally
public/visible by giving it an underscored keyword argument.
Testing comes next.
Swift SVN r24069
Rather than expose random access on String.UTF16View to all Swift users,
expose it only when Foundation is loaded. This effectively decouples
String from a UTF16 representation on non-Mac platforms.
Swift SVN r23929
GLKVector2 doesn't have 'r' or 'g' components, unlike the longer vector types, and GLKQuaternion has 'x', 'y', 'z', and 'w' components. Thanks Jordan for pointing these out.
Swift SVN r23895
We can access pretty much all of the GLKit functions now, but still lacked accessors for the individual elements. gyb up some accessors to do dirty bitcasting tricks to expose the elements of GLKVectorN, GLKMatrixN, and GLKQuaternion values.
Swift SVN r23892
If an imported C struct has no __nonnull pointer fields, then we can give a default initializer that zeroes all of its fields. This becomes a requirement when working with partially-imported types like NSDecimal. NSDecimal has bitfields Swift can't see yet, so it's impossible to DI, but the Foundation functions that work with NSDecimal all emit their result by out parameter, and without access to its fields it is impossible to initialize an NSDecimal for use with one of these functions. Implement the initializer using a builtin that gets lowered by IRGen; this is also made necessary by the fact that Swift has only a partial view of the struct, so we can't form a complete zero initializer until we have the definitive type layout from Clang.
Swift SVN r23727
rdar://problem/19132138
Make Set<T> visible by removing the underscore. Also, remove the pesky
${_Self} gyb variable that was for a temporary convenience in hiding Set.
Swift SVN r23699
Diagnose cases where the use of @objc will produce Objective-C methods
that end up overriding an Objective-C method in a superclass, when
that override is not properly represented as an override in the Swift
type system. This can happen when the Objective-C methods are produced
by different kinds of entities. For example:
class Super {
@objc var property: Int
}
class Sub : Super {
@objc func setProperty(property: Int) { }
}
In Swift, Sub.setProperty and Super.property are completely
unrelated. However, both produce an Objective-C instance method with
the selector "setProperty:", so we end up with unexpected overriding
behavior. Diagnose this whenever it occurs, regardless of the kind of
@objc entity that produced the Objective-C methods: initializers,
deinitializers, methods, properties, or subscripts.
Implements the rest of the intended functionality of
rdar://problem/18391046, with the caveat that there are two remaining
classes of bugs:
1) Superclasses defined in a module (or imported from a Clang
module) aren't handled properly yet; we might not see those methods.
2) We won't properly detect all of these failures when the methods
are scattered across different source files in the same module.
Swift SVN r23170
Core Graphics mirrors were emitting textual representations without
spaces following commas separating values. This commit fixes that
issue.
Swift SVN r22897
This reapplies commit r22864 - it is not changing the public api as we initially
thought. sqrt() was never available without importing Darwin.
This change only changes where sqrt() gets "forwarded" to. Before 'sqrt' called
the builtin '_sqrt' defined in BuiltinMath now it just calls the math library's
'sqrt' function.
I also added a stdlib test.
rdar://18371371
Swift SVN r22870
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
240 undocumented public non-operator APIs remain in core
Note: previous estimates were wrong because my regex was broken. The
previous commit, for example, had 260 undocumented APIs.
Swift SVN r22234
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
