Since the introduction of #26357/SR-11160 the TestJSONEncoder seems to
have been emitting the new warnings related to tuples being incorrectly
pattern matched.
The changes remove the incorrect code (removing the parenthesis around
the pattern).
Should not have any other effect (and the effect was not normally
visible if the test was successful, anyway).
Returns `true` if `T.Type` is known to refer to a concrete type. The
implementation allows for the optimizer to specialize this at -O and
eliminate conditional code.
Includes `Swift._isConcrete<T>(T.Type) -> Bool` wrapper function.
Misaligned indices were fixed in 5.1, but we should disable the test
when testing back deployment.
Adds a shared helper to StdlibUnittest for the run time check.
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
interpolation of Int types in the new os_log APIs so that it is
easier to extend to other integer types. Based on this, add support
for interpolating Int32 types.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
* Replace stdlib and test/stdlib 9999 availability.
macOS 9999 -> macOS 10.15
iOS 9999 -> iOS 13
tvOS 9999 -> tvOS 13
watchOS 9999 -> watchOS 6
* Restore the pre-10.15 version of public init?(_: NSRange, in: __shared String)
We need this to allow master to work on 10.14 systems (in particular, to allow PR testing to work correctly without disabling back-deployment tests).
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
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.
Generic parameters for a context are normally classified as "key",
meaning they have actual metadata provided at runtime, or non-key,
meaning they're derivable from somewhere else. However, a nested
context or constrained extension can take what would be a "key"
parameter in a parent context and make it non-key in a child context.
This messes with the mapping between the (depth, index) representation
of generic parameters and the flat list of generic arguments. Fix this
by (1) consistently substituting out extension contexts with the
contexts of the extended types, and (2) using the most nested context
to decide which parameters are key, instead of the context a parameter
was originally introduced in.
Note that (1) may have problems if/when extensions start introducing
their /own/ generic parameters. For now I tried to be consistent with
what was there.
rdar://problem/52364601
