Naively wrapping a T in an Any would require metadata for T, but we can go to AnyObject first and put the AnyObject in the Any without T's metadata. This fixes a regression in ObjC generic extension methods when they try to pass their generic parameters to id parameters as Any. rdar://problem/27526877
...and make sure we're in that mode for SIL inputs and for sil-opt and
sil-extract, even when working with AST types and declarations rather
than SIL types.
Without this, we get zillions of deprecation warnings coming out of
the validation tests SIL/parse_stdlib_*.sil, which dump the standard
library and then attempt to re-parse it. This has been causing the
"long" tests to take, well, too long.
Suppose you have this protocol:
protocol P {
typealias A = Int
typealias B = Self
}
Clearly, 'P.B' does not make sense, because then the type parameter
would "leak out" of the existential container. However, 'P.A' is totally
fine, it just means 'Int'.
Previously, we would allow 'P.A' in type context, and diagnose on 'P.B'.
However, due to an oversight, neither one was allowed in expression
context, so for example you could not write 'P.A.self', even though
that should just mean 'Int.self'.
Fix this by generalizing performMemberLookup(), and fix up some
diagnostics to be more specific when something is wrong -- we want
to avoid talking about typealiases as 'static members', since that
doesn't really make much sense.
Fixes <https://bugs.swift.org/browse/SR-2314>.
SIL already does this where necessary, except with foreign throwing
functions; this patch changes Sema and the ClangImporter to give
them an ObjCBool foreign error result type explicitly.
This fixes a problem where calls to functions taking and returning
the C99 _Bool type were miscompiled on Mac OS X x86-64, because
IRGen was conflating the Objective-C BOOL type (which is a signed
char on some platforms) and C99 _Bool (which lowers as the LLVM
i1 type).
Fixes <rdar://problem/26506458> and <rdar://problem/27365520>.
- Make sure VarDecls have an associated TypeLoc, like ParamDecls do, then use it for printing the VarDecl's type.
This is done by moving ParamDecl's TypeLoc up to the VarDecl.
This is useful for being able to display the parameter names of function types embedded in VarDecls.
- Use the result TypeLoc of functions for printing. This enables printing parameter names of function types embedded in return types.
- Make sure to annotate attributes while they are printed.
When DynamicSelfType occurs outside of a class body (for example,
inside of a SIL function), it is not enough to simply utter 'Self',
because then we lose the underlying type.
Instead, print it out as '@dynamic_self Foo', where 'Foo' is the
underlying class type or archetype, and add parser support for
the same.
Fixes <rdar://problem/27735857>.
Previously, qualified lookup would use a metatype to signal
to the LookupResultBuilder that conformance checks should not
be used to resolve protocol members found with a concrete
type base. This is too subtle for my taste. Add an explicit
flag and clean up some usages, fixing <rdar://problem/16123805>.
Also, clean up the 'CheckProtocolMembers' flag. We now set
when the base type is an archetype, and correctly handle
the concept of an abstract conformance. This finally
fixes <rdar://problem/22776964>.
Member operators should be placed within a nominal type (or extension
thereof) that they operate on. Aside from being good style, enforcing
this in the type checker can help with dependency tracking. Addresses
rdar://problem/27536066.
Otherwise, we'll treat lookups on generic parameters as ambiguous,
since we don't have a concrete nominal type to use (coincidentally)
as the "base" of each lookup result.
It's possible we can get rid of this condition altogether, but I don't
want to rock the boat for unqualified lookup right now.
rdar://problem/23087787
* [FixCode] Add a fixit to help users migrate to Swift 3 name convention of enum cases. rdar://26887735
When users' referring to a enum case with a wrong name and we can find a correct enum case whose name
differs from the wrong name only in capitalization, we replace the wrong name with the correct one.
* Addressing Argyrios' code review comments. NFC
* [test] Update existing test.
* Grammatical polish suggested by @CodaFi.
The constraint generator's optimization to eagerly merge type
variables for different keys in a dictionary literal was too eager,
merging the type variables for (e.g.) a string literal and an integer
literal. This prevented us from properly inferring AnyHashable key
types in dictionary literals. Fixes the rest of rdar://problem/27661580.
The problem here is that we would just emit 'invalid pattern'
instead of digging deeper, which meant that the fix-it for
qualified enum element access wasn't getting inserted for
more complex patterns, such as 'case X(let x)'.
Unfortunately, in the matching_patterns.swift test, we emit
too many diagnostics that are not really useful to figuring
out the problem, and the old 'invalid pattern' made more
sense. I'll work on some CSDiag tweaks to address this --
I think it makes more sense to dig there than just emit a
general 'invalid pattern' diagnostic anyway.
Fixes <rdar://problem/27684266>.
Suggest a fix-it for unqualified references to all static members
from instance context, not just enum elements.
Also, fix a small problem with the fix-it for replacing protocol
names with 'Self' inside extension bodies -- we didn't handle nested
functions properly.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
Stub out a simplistic 'meet' operation for types that currently only
handles finding the meet of two class types. Use it to optimize the
constraint solver ever so slightly: when we see a type variable whose
constraints state that it is a supertype of two different concrete
types, we attempt to compute their meet and, if we find it, only
produce one potential binding that is the meet itself.
Note that this is an extremely poor implementation of this concept
that is meant to address a specific regression being introduced by the
defaulting of collection literal element types. A real implementation
would, at the very least:
* Implement a proper 'meet' that covers all subtyping in the language.
* Distinguish between "I don't know if there is a meet" and "I am
absolutely certain that there is no meet".
* Collapse the constraints themselves to reduce the number of
constraints in the system, rather than just the number of type
variable bindings we attempt.
