The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
Update tests to match, and rewrite SwiftPrivatePthreadExtras to take advantage of native C function pointer support instead of hacking it up through a stub C++ library.
Swift SVN r27604
Update tests to match, and rewrite SwiftPrivatePthreadExtras to take advantage of native C function pointer support instead of hacking it up through a stub C++ library.
Swift SVN r27598
Previously, we were importing Clang's 'deprecated' attribute in as
@availability(*, unavailable), based on the idea things that were
unconditionally deprecated in Objective-C shouldn't even be accessible
in Swift. (We were motivated by 'tmpnam', among others). However, this
plays havoc with mixed Objective-C/Swift projects, because the
Objective-C 'deprecated' attribute was useless as a mechanism for
making internal changes in the project. We have Clang's
__attribute__((availability(swift, unavailable))) to make an API
unavailable in Swift, so the deprecated -> unavailable mapping here no
longer makes sense.
Fixes rdar://problem/18934173.
Swift SVN r27358
This renames their 'value' field to 'rawValue'.
This is needed for consistency in the next commit. I can't find a Radar for
it, though.
Swift SVN r25399
attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
Previously we'd try to put the same method into the list of members multiple
times--once for each redeclaration in the @interface. This led to an
assertion failure.
Checking the canonical decl isn't super cheap, but the ObjCMethodDecl
redeclaration infrastructure seems to be fairly broken. We can revisit this
later.
There's also a test for what happens when categories get involved. I'm not
convinced this is correct behavior, either, and will file an additional bug
to look into that at some point.
rdar://problem/19039485
Swift SVN r24129
We can't reliably reject raw values in an NS_ENUM's init(rawValue:), because the enum may have SPI or future values we don't statically know about. Fixes https://twitter.com/autorelease/status/524698585406124033
Swift SVN r23817
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
We don't do this very efficiently, but it does work. And now that it's working,
drop some special cases in module interface printing -- just always print
Clang decls in Clang source order.
Swift SVN r21901
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
Specifically, it should not ever have a clang::TypedefDecl as its Clang node,
even if the RecordDecl is anonymous and immediately wrapped in a typedef.
It looks like no one was ever doing this intentionally; it's just left over
from before we looked through typedefs at all. This is important because we
use the clang::RecordDecl for IRGen layout if it's present; before this patch
we would fall back to Swift layout for these structs (clearly wrong).
The one exception here is enums -- NS_OPTIONS and named C enums get imported
as structs as well. If we add any other exceptions, we should be sure they
are dealt with in IRGen as well.
The change in the printed interface output is due to the source location
for the Clang node of an NS_ENUM or NS_OPTIONS decl being inside a macro.
I didn't see a quick fix for this, so I'm going to ignore it for now.
Swift SVN r21748
Previously we only printed submodules that were imported by the
top-level module, which worked in the common case of inferred submodules
of frameworks (e.g. Foundation.NSArray), but fell over when the
submodules were explicit (e.g. OpenGL.GL), or just not imported by the
top-level module.
Swift SVN r20855
This completes <rdar://problem/17024498>, except that we don't yet do
anything with 'deprecated' or 'obsoleted'. The former is covered by
<rdar://problem/17406050>, and I filed <rdar://problem/17873422> for the
latter.
Swift SVN r20845
Nearly all of them come from some annotation written explicitly in the
Objective-C header, and all of them should be shown in the generated
interface for an imported module.
Part of <rdar://problem/17024498>
Swift SVN r20841
We require some level of consistency between the way the overlays were
built and what we work with in our mock SDK. The IDE/sdk_sugar.swift
test failure was because the overlay referenced "init(coder:)" while
the test was looking for "init(withCoder:)". Hilarity ensued
<rdar://problem/17791048>.
This only impacts testing.
Swift SVN r20564
...and 'assign' and 'unsafe_unretained' as 'unowned(unsafe)', if the
property is a class type.
This isn't important for the compiler, but it is documentation for users
when they look at the generated interface for an Objective-C module.
Note that this actually produces a decl users can't yet write:
unowned(unsafe) var foo: UIView!
That's <rdar://problem/17277899> unowned pointers can't be optional.
<rdar://problem/17245555>
Swift SVN r20433
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
This keeps CInt (and related type aliases) in the stdlib, and keeps the clang importer
using them, but has it look through one level of the type alias to get to the underlying
type.
The upshot of this is that we now import things like exit (as a random example) as
"func exit(Int32)" instead of "func exit(CInt)".
Swift SVN r19224
...where T is the equivalent Swift function type. This gives us proper type
safety (ish) for C function pointers while still not treating them the same
as Swift closures.
If the function type is not one we can represent in Swift, we fall back to
COpaquePointer. CFunctionPointer<T> and COpaquePointer can be explicitly
constructed from one another, but do not freely convert.
<rdar://problem/17215978>
Swift SVN r19154
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
TL;DR. You don't want to read this patch. Mostly, it's adjusting to
the fact that global functions no longer have keyword arguments by
default, which affects nearly every SIL- and IR-test, as well as the
IDE-related tests. I've tried to generalize the SIL and IR tests to be
more resilient against such mangling changes, but I've surely missed
some.
Swift SVN r17058
Fixes
<rdar://problem/16438738> Ensure that RawOptionSet conformance is printed for
imported NS_OPTIONS
and probably other latent bugs.
Swift SVN r16971
This leaves in the existing syntax for @unchecked T?. That will
be addressed in later patches.
There's still a mysterious case where some of the SIL output
includes UncheckedOptional<T> and some places T!.
Moreover, this doesn't handle SourceKit's behavior for printing
for overrides. This just handles parsing the 'T!' syntax.
Swift SVN r16945
