* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
Added tests for expected-error and fix-its.
- Add arguments signature regardless that is the same as before.
Because the error message looks more natural.
e.g. "makeIterator" => "makeIterator()",
"replaceSubrange" => "replaceSubrange(_:with:)"
- Any${ExistentialCollection}.underestimateCount() was a method, not
computed property.
- 'LazySequenceType' has been renamed to 'LazySequenceProtocol', but not
'LazyCollectionProtocol'
- Streamable.writeTo(_:) had no argument label.
- Fixed typo in print() debugPrint() error message (not working for now)
- Repeated.init(): changed `renamed` to `message` because the arugment
order has changed.
- Marked `public` for some unavailable method on `Sequence`
- Sequence.split(_:maxSplit:allowEmptySlices) was replaced with
split(separator:maxSplits:omittingEmptySubsequences:),
not split(separator:omittingEmptySubsequences:isSeparator:)
- Sequence.split(_:allowEmptySlices:isSeparator) was replaced with
split(maxSplits:omittingEmptySubsequences:isSeparator:),
not split(_:omittingEmptySubsequences:isSeparator:)
- Sequence.startsWith(_:isEquivalent:) or startsWith(_:) had no label on
the first argument.
- transcode(_:_:_:_:stopOnError), not transcode(_:_:_:_:stoppingOnError)
- Removed mutating methods from UnsafePointer.
alloc(_:), dealloc(_:), setter:memory, initialize(_:), destroy(),
and destroy(_:)
Currently, in Cygwin, the print() function works well without any workaround.
I presume this bug is fixed by side effect of some other commit, but couldn't find out exactly what.
When we're not serializing SIL for all function bodies, @_transparent
functions can only reference internal functions that are declared
@_versioned, otherwise there's no serialized body and no public entry
point, so any client that inlines the @_transparent function will
not be able to link.
This patch adds the minimum set of @_versioned declarations to allow
a non-optimized build of the standard library and overlays.
Recall that this attribute is just a temporary hack to make progress
on building the standard library with resilience enabled.
Once availability and resilience learn about each other, @_versioned
will be replaced by having an availability annotation on an internal
declaration. Invariants will be diagnosed by Sema instead of asserting
in the SIL verifier.
Finally, the set of "internal but available" declarations will
eventually be audited instead of determined by experimentation.
This almost closes out https://bugs.swift.org/browse/SR-267.
The remaining issue is an interaction between SIL optimizations and
serialization that will be fixed with some upcoming changes to the
optimizer.
When comparing two functions for overload resolution, break apart the
parameter lists to compare individual parameters rather than comparing
the tuples. This allows us to prefer functions with fewer arguments to
ones with more, defaulted or variadic arguments. That preference was
already encoded in the constraint optimizer, which led to some strange
behavior where the preference was expressed for function calls but not
for calls to initializers. Fixes rdar://problem/24128153.
The standard library change tweaks the anachronistic, unavailable
"print" variants somewhat. The only behavior change here is a slight
regression for cases like:
print(a: 1, b: 2)
where we used to produce a diagnostic:
Please wrap your tuple argument in parentheses: 'print((...))'
but we now get:
argument labels '(a:, b:)' do not match any available overloads
However, this regression will happen at some point *anyway*, if
SE-0029 (or anything else that removes the implicit tuple splat
operation) goes through.
* Switch to calling `putchar_unlocked()` instead of `putchar()` for
actual printing. We're already locking stdout with `flockfile()`, so
there's no need for the redundant lock that `putchar()` uses.
* Add an explicit lock to the output stream in `dump()`. This means the
entire dump is printed with the lock held, which will prevent the
output of `dump()` from mixing with prints on other threads.
* Use `_debugPrint_unlocked()` instead of `debugPrint()` in
`_adHocPrint()`. The output stream is already locked while this
function is executing. Rename the function to `_adHocPrint_unlocked()`
to make this explicit.
* Use `targetStream.write()` and `_print_unlocked()` instead of
`print()` in `_dumpObject()`. This removes the redundant locking, and
also eliminates the creation of intermediate strings. Rename the
function to `_dumpObject_unlocked()` to make this explicit.
* Use `targetStream.write()`, `_print_unlocked()`, and
`_debugPrint_unlocked()` in `_dumpSuperclass()`. This removes the
redundant locking, and also eliminates the creation of intermediate
strings. Rename the function to `_dumpSuperclass_unlocked()` to make
this explicit.
* Use `_debugPrint_unlocked()` instead of `debugPrint()` in
`String.init(reflecting:)`. This shouldn't really make much of a
difference but it matches the usage of `_print_unlocked()` in
`String.init(_:)`.
The net result is that all printing is still covered under locks like
before, but stdout is never recursively locked. This should result in
slightly faster printing. In addition, `dump()` is now covered under a
single lock so it can't mix its output with prints from other threads.
These APIs are from the Swift 1.2 => Swift 2.0 transition, and are not
relevant anymore.
Removing them reduces the surface area of the library that needs to be
reviewed.
This allows us to remove the workaround generic overloads for "print" without sacrificing good diagnostics for its unavailable overloads. (rdar://problem/21499048, rdar://problem/21582758, rdar://problem/22126141)
Swift SVN r31169
