- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
- Increase impact of a generic pointer-to-pointer mismatch fix to
match that of a contextual type failure. This allows more specific
fixes to take precedence.
- De-prioritize generic argument mismatch fix when both types are
pointers. This allows pointer-to-pointer conversion produce a
more specific fix.
- De-prioritize fixes that involve `Builtin.RawPointer` or `OpaquePointer`
in parameter positions. This helps to produce better diagnostics
for argument mismatches during pointer initialization e.g.
`UnsafeRawPointer(<pointer>)`.
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
Currently `{inout, array, string}-to-pointer` conversion doesn't
track whether there was a difference in optionality between involved
types which leads to ambiguity when different overload choices
have different optionality requirements.
Let's fix that by increasing a score in cases if pointer type
is itself optional e.g.:
```swift
func foo(_ x: UnsafeMutablePointer<Int>) {}
func foo(_ x: UnsafeMutablePointer<Int>?) {}
foo(&foo) // Should pick the least optional overload choice.
```
Resolves: [SR-8411](https://bugs.swift.org/browse/SR-8411)
These include the pointer-to-pointer and pointer-to-buffer-pointer
initialiser parameters amongst a couple of others, such as
`Unmanaged.fromOpaque`, and the source for the `move[...]` family of
methods.
Remove this additional note when attempting to incorrectly initialize UnsafePointer:
Pointer conversion restricted: use '.assumingMemoryBound(to:)' or
'.bindMemory(to:capacity:)' to view memory as a type.
The note was added for Swift 3 migration. The idea was to get projects
building as quickly as possible and effectively tag bad behavior so it
could be corrected later. That worked, but now it's been working
against us for the past couple of releases. Too much new code is using
these two APIs and the vast majority of uses are not only incorrect,
but much more simply expressed without them. Instead, programmers need
to be made aware that the UnsafeRawBufferPointer API already does what
they want... but we can work on that problem as separate task.
Most uses of these APIs are something like:
return rawptr.assumingMemoryBound(to: T.self).pointee
or
UnsafeRawPointer(ptr).bindMemory(to: UInt16.self, capacity: 2).pointee
Instead of simply
return rawptr.load(as: T.self)
I've even seen programmers do this:
extension UnsafeRawPointer {
var uint8: UInt8 {
let uint8Ptr = self.bindMemory( to: UInt8.self, capacity: 1 )
return uint8Ptr[0]
}
}
...instead of simply using either UnsafeRawPointer.load or UnsafeRawBufferPointer's subscript.
When the compiler fails to find an overload with suitable parameter or return types, it often attaches a note listing the available overloads so that users can find the one they meant to use. The overloads are currently ordered in a way that depends on the order they were declared, so swift-evolve would sometimes cause tests involving these diagnostics to fail.
This change emits the list in a textually-sorted order instead. The names were already being sorted as they were inserted into a std::set, so this shouldn’t significantly slow down the diagnostic.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
Currently `visitAssignExpr` always attempts to use type
derived from destination as a contextual type for assignment
source type-checking, which doesn't always lead to better
results.
Resolves: SR-5081
https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
Unsafe[Mutable]RawBufferPointer is a non-owning view over a region of memory as
a Collection of bytes independent of the type of values held in that
memory. Each 8-bit byte in memory is viewed as a `UInt8` value.
Reads and writes on memory via `Unsafe[Mutable]RawBufferPointer` are untyped
operations. Accessing this Collection's bytes does not bind the
underlying memory to `UInt8`. The underlying memory must be bound
to some trivial type whenever it is accessed via a typed operation.
In addition to the `Collection` interface, the following methods from
`Unsafe[Mutable]RawPointer`'s interface to raw memory are
provided with debug mode bounds checks: `load(fromByteOffset:as:)`,
`storeBytes(of:toByteOffset:as:)`, and `copyBytes(from:count:)`.
This is only a view into memory and does not own the memory. Copying a value of
type `UnsafeMutableRawBufferPointer` does not copy the underlying
memory. Assigning an `Unsafe[Mutable]RawBufferPointer` into a value-based
collection, such as `[UInt8]` copies bytes out of memory. Assigning into a
subscript range of UnsafeMutableRawBufferPointer copies into memory.
