It also uses the new mangling for type names in meta-data (except for top-level non-generic classes).
lldb has now support for new mangled metadata type names.
This reinstates commit 21ba292943.
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
For this we are linking the new re-mangler instead of the old one into the swift runtime library.
Also we are linking the new de-mangling into the swift runtime library.
It also switches to the new mangling for class names of generic swift classes in the metadata.
Note that for non-generic class we still have to use the old mangling, because the ObjC runtime in the OS depends on it (it de-mangles the class names).
But names of generic classes are not handled by the ObjC runtime anyway, so there should be no problem to change the mangling for those.
The reason for this change is that it avoids linking the old re-mangler into the runtime library.
The old method of constructing a mangled class name does not work anymore with the new mangling scheme.
Also, by using the re-mangler, _typeByName now works with class names containing non-ascii characters.
Data can encapsulate it’s own sub-sequence type by housing a range of the slice in the structural type for Data. By doing this it avoids the API explosion of supporting all APIs that take Data would need overloads to take a slice of Data. This does come at a small conceptual cost: any index based iteration should always account for the startIndex and endIndex of the Data (which was an implicit requirement previously by being a Collection). Moreover this prevents the requirement of O(n) copies of Data if it is never mutated while parsing sub sequences; so more than an API amelioration this also could offer a more effecient code-path for applications to use.
These were overlooked, and somehow code that attempted to make a minimal collection conform to RangeReplaceableCollection and RandomAccessCollection managed to compile successfully in Swift 3.0, but in Swift 3.1…*something* changed to reject a type that conforms to both due to the lack of a suitable default slicing subscript implementation in the stdlib that provided all the requirements. Fill in these missing implementations, fixing rdar://problem/30228957.
* Mark several C macros imported from <float.h> as deprecated.
These macros all have straightforward replacements in terms of static properties on FloatingPoint or BinaryFloatingPoint. It is necessary to add 1 in a few places because of differences between how C and Swift count significand bits and normalize the significand, but this is expected to have minimal impact on code in practice (and when it does have impact, using the Swift definition is generally simpler).
* Address review notes from @moiseev.
This fixes <rdar://problem/27871465>
* Removing uses of mixed-type + and - in benchmarks
Using type cast or explicit type annotations.
* Deprecating use of + and - on SignedInteger
As it leads to mixed type arithmetics that is not supposed to work.
It was needed before the new collection indexing model to make moving
indexes simple.
* Test deprecation warning
