Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
We don't properly open up the existential to make this work, which
leads to an IRGen crash. Reject the uses of generics that would cause
such a crash rdar://problem/17491663.
Swift SVN r21946
t2.swift:3:1: error: argument for generic parameter 'U' could not be
inferred
f(i)
^
t2.swift:2:6: note: in call to function 'f'
func f<T, U>(t: T) -> U? { return nil }
^
Our lack of decent locator information means that we don't get notes
in all of the cases we want them. I'll look at that separately.
Swift SVN r21921
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
This patch adds a new 'pound_os' token, a new case for it in parseExprPostfix, and parsing of platform version constraints, e.g., OSX >= 10.10.
It also adds enough type checking and SILGen to get the parsing tests to run without triggering "Unimplemented" assertions.
Swift SVN r21865
If an entity is declared in an extension, and the extension is declared in a
different module from the type it extends, we include the extension's module
name in the mangling in addition to the extended type. We were already doing
this for functions and subscripts because of rdar://problem/18057875, but
this extends it to all declarations.
This is necessary to handle
(1) debugging private members of cross-module extensions
(2) the same member being declared in two different modules, each of which
extends a type in a third module
rdar://problem/14884749
Swift SVN r21846
We use the basename to generate the private-discriminator. Why just the
basename? Because we want projects checked out in different locations to
still have a chance of generating identical binaries, and (at least for now)
private symbols still have external linkage.
Part of rdar://problem/17632175
Swift SVN r21845
You'll notice that emitting this diagnostic will make some already noisy closure-related errors slightly more so. This is unfortunate, but for the time-being it's better than crashing.
Swift SVN r21817
This works using the nominal's normal lookupDirect to gather decls from the
original declaration and all its extensions, then filters them by module and
private-discriminator. This does not yet do the right thing for extensions
because we don't include the extension's module in a member's mangling except
in very specific circumstances. In order to make this work in general we'll
have to start doing this more generally.
Part of rdar://problem/17632175
Swift SVN r21785
This is useful when making an Objective-C class conform to a Swift
protocol. Note that we can only implement this safely for non-@objc
protocols, where we have a witnes function that can perform the
checked unwrapping.
Swift SVN r21782
We cannot properly deserialize extensions of generics where the
extension lives in a different module than the original generic type
definition rdar://problem/18250779. For now, emit a diagnostic when
one defines public API in such an extension, rather than crashing
later on rdar://problem/18232867.
Swift SVN r21776
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
This commit adds a new expression (AvailabilityQueryExpr) and a single kind of
specification for when a block of code or function is available
(VersionConstraintAvailabilitySpec). We may add more kinds of specifications
in the future. At the moment, the AvailabilityQueryExpr allows only a
single platform to be queried; I will add support for multiple platforms
in a later commit.
This commit contains just the added AST nodes; no parsing, type checking, etc.
I’ve added assert(false && “Unimplemented”) for places where support for
AvailabilityQueryExpr will need to be added later.
Swift SVN r21760
Now that there's just one entry point for discriminated lookup, there's not
really a need for this extra abstraction.
One thing still up in the air is unqualified lookup support for discriminator
preferences (for, say, breakpoint conditions), but we'll cross that bridge
when we come to it.
Part of rdar://problem/17632175
Swift SVN r21755
Since the primary purpose here is to go from a mangled name to a decl, and
discriminators are only valid in the context of a particular module, it
makes sense to make this an API on Module. Eventually this will also support
lookup into a type or its extensions, limited by module and discriminator.
Swift SVN r21754
This behaves like @UIApplicationMain, except for AppKit. Attach it to your NSApplicationDelegate, and an artificial "main" will be generated that invokes NSApplicationMain() for you. Implements rdar://problem/16904667.
Swift SVN r21697
Currently this only handles top-level nominal types. We're just trying to
emulate what the debugger does when it needs to go from a mangled name to
an AST node, so it's okay that the cases handled here are very restricted.
We just want to make sure that the debugger is /able/ to do what it needs
to do.
This does not yet handle nested (non-top-level) values; that will require
changes to DeclContext::lookupQualified.
Part of rdar://problem/17632175
Swift SVN r21690
This is in preparation for allowing demangling to match up with a particular
AST node, even if there are two private decls with the same name in the same
module. This commit doesn't actually change anything about the lookup; the
next commits will start adding support for the various lookups-with-
discriminators. (This is mostly only useful for the debugger.)
Part of rdar://problem/17632175
Swift SVN r21689
This raises an error for some cases we don't implement correctly yet, though not ones that require super.init or self.init delegation yet.
Swift SVN r21669
This already can't happen in most circumstances because of trailing closures, but we didn't explicitly disallow it at the beginning of a BraceStmt or following a statement production. Fixes the parser part of rdar://problem/17850752 (though there's a type checker bug there too).
Swift SVN r21663
disallow overriding a let property with a var: a var property could return a different
value every time, which violates substitutability of the 'let' contract.
Swift SVN r21618
This is useful both for caching purposes and for comparison of discriminators
(something the debugger will need to do when looking up a particular decl).
No observable functionality change.
Swift SVN r21610
Now we can test the mangling rules set up in the previous commit: include
the discriminator for the top-most 'private' decl, but not anything nested
within it.
Part of rdar://problem/17632175
Swift SVN r21599
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
If either parameter to == has a known concrete type at constraint generation
time, see if that type is a nominal that can derive its conformance to
Equatable. If so, do so, and then add that == to the overload set.
(It may already be there, but that's okay -- it will get uniqued later.)
This isn't perfect because it relies on one of the parameters to == having
a concrete type /before/ constraint solving. There are plenty of reasons
why that wouldn't happen. But this at least fixes the common case, and
breaking the expression up into multiple lines is a less distasteful
workaround than replacing (x == .Value) with !(x != .Value). I've added a
test case that should work but doesn't that we can revisit later.
rdar://problem/18073705
Swift SVN r21557
sema let them slip through if classbound. Reject them until silgen handles
them, fixing <rdar://problem/18158354> partial application of protocol method crashes the compiler in silgen
Swift SVN r21514
