When we are type-checking calls, subscripts, or other call-like
expressions, use the argument labels provided by the various
expression nodes rather than those encoded in the tuple type. This
means that argument label matching now matches the callee
declaration's argument labels against the argument labels, without
relying on encoding the argument labels within types in the AST.
This refactor is a stepping stone torward SE-0111.
* [Type System] Handle raw pointer conversion.
As proposed in SE-0107: UnsafeRawPointer.
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#implicit-argument-conversion
UnsafeMutablePointer<T> -> UnsafeMutableRawPointer
UnsafeMutablePointer<T> -> UnsafeRawPointer
UnsafePointer<T> -> UnsafeRawPointer
UnsafeMutableRawPointer -> UnsafeRawPointer
inout:
&anyVar -> UnsafeMutableRawPointer
&anyVar -> UnsafeRawPointer
array -> UnsafeRawPointer
string -> UnsafeRawPointer
varArray -> UnsafeMutableRawPointer
* Rename expectEqual(_, _, sameValue:) to expectEqualTest to workaround a type system bug.
<rdar://26058520> Generic type constraints incorrectly applied to functions with the same name
This is exposed by additions to the type system for UnsafeRawPointer.
Warning: unit tests fail very confusingly without this fix.
This is needed for declaration-based resolution subscript expressions,
which is the basis for implementing default arguments in subscripts as
well as declaration-based argument labels.
Protocol types cannot provide an implementation of their members — when
one is looked up on a protocol in that protocol’s context, we can
suggest using the dynamic `Self` type.
```
extension StaticP {
func bar() {
_ = StaticP.foo(a:) // suggest `Self.foo(a:)`
}
}
```
This reverts commit dc24c2bd34.
Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
This removes conformance of DarwinBool and ObjCBool to the Boolean protocol,
and makes the &&/||/! operators be concrete w.r.t. Bool instead of abstract
on Boolean.
This fixes some outstanding bugs w.r.t diagnostics, but exposes some cases
where an existing diagnostic is not great. I'll fix that in a later patch
(tracked by rdar://27391581).
In Swift, default arguments are associated with a function or
initializer's declaration---not with its type. This was not always the
case, and TupleType's ability to store a default argument kind is a
messy holdover from those dark times.
Eliminate the default argument kind from TupleType, which involves
migrating a few more clients over to declaration-centric handling of
default arguments. Doing so is usually a bug-fix anyway: without the
declaration, one didn't really have
The SILGen test changes are due to a name-mangling fix that fell out
of this change: a tuple type is mangled differently than a non-tuple
type, and having a default argument would make the parameter list of a
single-parameter function into a tuple type. Hence,
func foo(x: Int = 5)
would get a different mangling from
func foo(x: Int)
even though we didn't actually allow overloading.
Fixes rdar://problem/24016341, and helps us along the way to SE-0111
(removing the significance of argument labels) because argument labels
are also declaration-centric, and need the same information.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Some modifications for the ms-extension option of the clang.exe in the Visual Studio 2015 development environment
This patch is only for swiftc.exe. I used the library set of Visual Studio 2015 Update 1 and recent version of swift-clang as the compiler. If you are using the real MSVC compiler, more patch might be required.
a match, since it *could* be, and typically conforms to whatever the expression is.
Fixing this improves the diagnostic in Constraints/closures.swift significantly, and
fixes these bugs:
<rdar://problem/21718970> QoI: [uninferred generic param] cannot invoke 'foo' with an argument list of type '(Int)'
<rdar://problem/21718955> Swift useless error: cannot invoke 'foo' with no arguments
where before we produced:
error: cannot invoke 'foo' with an argument list of type '(Int)'
and now produce:
x.swift:5:10: error: generic parameter 'A' could not be inferred
Whatever.foo(a: 23)
^
x.swift:1:7: note: 'A' declared as parameter to type 'Whatever'
class Whatever<A: IntegerArithmetic, B: IntegerArithmetic> {
^
It looks like the mapTypeIntoContext() call is using the wrong
'dc', because in fact we have no way of knowing what the original
'dc' was which produced the type parameters in question.
Really the problem is we're picking apart SubstitutedType here,
which is almost always the wrong thing to do. I don't think
SubstitutedType should exist at all.
To avoid the crash, just bail-out if 'dc' is not generic.
I'm intentionally avoiding a principled fix here to hasten the
apocalypse when all of CSDiag.cpp will collapse under its own
weight and get rewritten in a sane way.
Rather than relying on the embedding of default argument information
into tuple types (which is gross), make sure that the various clients
(type checker, type checker diagnostics, constraint application) can
dig out the callee declaration and retrieve that information from
there.
Like this:
MyEnumType(MyEnumType.foo)
This is missing 'rawValue:' label, but that won't actually fix this. A better fix is to just remove the unnecessary constructor call:
MyEnumType(MyEnumType.foo)
-->
MyEnumType.foo
Adds fixits for:
- Passing an integer with the right type but which is getting wrapped with a
different integer type unnecessarily. The fixit removes the cast.
- Passing an integer but expecting different integer type. The fixit adds
a wrapping cast.
If the expression type is RawRepresentable with an associated
RawValue type of T, and the contextual type is T, suggest adding
a '.rawValue' accessor call.
Also, suggest inserting the fixit in a few more cases, such as
dictionary keys.
This improves upon a previous patch which added a fix-it for the
other direction:
<55bf215feb>
Fixes <rdar://problem/26470490>.
