[swift-3.0-preview-1] stdlib: fix incorrect distance measurement between UTF-16 indices #4080
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Issue better diagnostics, along with notes and fixits, for the common case of using an implicitly non-escaping parameter of function type in a context expecting an @escaping closure. Provides even more specific diagnostics for common scenarios such as passing to another function or assignment.
Extends the more useful diagnostics for non-escaping function parameters used in @escaping contexts to apply to all functions that are equivalent modulo ExtInfo.
Added sugared test case
3.0 noescape by default
This allows us to freely pass the address of a variable of such types to a C function without worrying about it overwriting other things if e.g. it memcpy's sizeof(T) bytes and thus clobbers the otherwise-non-existent tail padding. There are ways to get this optimization back, but they require things like materializing to a temporary instead of passing the address directly. We haven't done that work yet, so we don't get to take advantage of it. rdar://26828018
) Otherwise we get into a situation like this: 1. Change made to the interface of file A.swift that also causes an error in A.swift. 2. Fixing the error in A.swift does not affect A.swift's interface. 3. File B.swift that depends on A.swift is not rebuilt, since the most recent change to A.swift did not change its interface. To fix this, mark downstream files as needing to be rebuilt even when a compilation job fails with errors. Additionally, attempt to be extra conservative when there's a crash. rdar://problem/25405605 (cherry picked from commit 848b3eb)
Thanks, Dmitri. (cherry picked from commit b8cc267)
This ensures that blocks that come from `DispatchWorkItem`s will function correctly. The only exception is __dispatch_barrier_sync() as the block passed to that call is not `@convention(block)` so it doesn't matter. Fixes SR-2246.
[swift-3.0-branch] Added String.init<T>(_: T) and marked it unavailable
rdar://27226313 (cherry picked from commit b5a8805)
This test is known to fail on a debug stdlib
…rting 'mutating'. rdar://27500578
Huge thanks to John for noting that 'consume' didn't provide the guarantees we wanted, and to Michael G. for getting a TSan build up and running to identify/verify this race. It's possible that this is overlay strict, and that we only need to look at the domain to ensure that the code and userInfo are visible. However, TSan seems to prefix the form in this patch, so we'll be more conservative for now. Fixes rdar://problem/27541751. (cherry picked from commit e07e887)
Count tail-padding in the size of imported C types.
It is important to call doPreProcess to correctly setup the available opened archetypes which were referenced from the original instruction being copied. This fixes a concrete bug in LoopRotate optimization and potential bugs related to cloning. rdar://27659420
...because otherwise option sets that get imported as members using NS_SWIFT_NAME are printed with an 'enum' tag, and the definition of NS_OPTIONS only declares the typedef under C++. We should come back and figure out something more principled for this later, but for now this solves an issue with generated headers imported into C++ translation units. rdar://problem/27130343 (cherry picked from commit 02d2517)
…nitializer overlay
[sil-cloner] Always call doPreProcess when visiting SILInstructions.
…-race Eliminate a race condition in NSError bridging
[3.0] [Driver] Make sure to rebuild dependents when a dirty file fails.
[swift-3.0-branch] Fix Dispatch API's handling of block parameters
…asses. In addition to using the 'Class' existential representation for NSError, use it for subclasses of NSError, which can also be toll-free bridged. Narrowly addresses rdar://problem/27658748. (cherry picked from commit 3f960e3)
…xistentials. Imported Cocoa error types are represented by structs wrapping an NSError. The conversion from these structs to Error would end up boxing the structs in _SwiftNativeNSError, losing identity and leading to a wrapping loop. Instead, extract the embedded NSError if there is one. In the Swift runtime, do this as part of the dynamic cast to NSError, using a (new, defaulted) requirement in the Error type so we can avoid an extra runtime lookup of the protocol. In SILGEn, do this by looking for the _BridgedStoredNSError protocol conformance when erasing to an Error type. Fixes SR-1562 / rdar://problem/26370984. (cherry picked from commit d219531)
When emitting an existential erasure to Error from an archetype, use the _getEmbeddedNSError() witness. If it produces an NSError, erase that; otherwise, go through the normal erasure path. Of course, make NSError and CFError implement _getEmbeddedNSError() so this kicks in for the obvious cases as well as the more obscure ones. Fixes the rest of SR-1562 / rdar://problem/26370984. (cherry picked from commit 75e85dc)
…SError. This clarifies the 'Indirect' case. Thanks, Dmitri! (cherry picked from commit 4b8b7bb)
Various changes throughout the compiler and libraries appear to have resulted in an increase in memory usage in the constraint solver since Swift 2.2. This is a stop-gap measure to allow more expressions to compile while the expression type checker is being improved. We've seen several cases where even a modest increase allows things that compiled with Swift 2.2 to continue to compile (albeit with generally longer compile times). (cherry picked from commit 8886f77)
Fix the source range of a precedencegroup declaration that lacks a }
Add implicit conversions and casts from T:Hashable <-> AnyHashable.
(cherry picked from commit 87a5e4d)
(cherry picked from commit 82ba4df)
…r possibilities. Fixes rdar://problem/17444930. (cherry picked from commit d073375)
Stub out a simplistic 'meet' operation for types that currently only handles finding the meet of two class types. Use it to optimize the constraint solver ever so slightly: when we see a type variable whose constraints state that it is a supertype of two different concrete types, we attempt to compute their meet and, if we find it, only produce one potential binding that is the meet itself. Note that this is an extremely poor implementation of this concept that is meant to address a specific regression being introduced by the defaulting of collection literal element types. A real implementation would, at the very least: * Implement a proper 'meet' that covers all subtyping in the language. * Distinguish between "I don't know if there is a meet" and "I am absolutely certain that there is no meet". * Collapse the constraints themselves to reduce the number of constraints in the system, rather than just the number of type variable bindings we attempt. (cherry picked from commit 2bcf555)
…ny project. This is NFC because nothing sets the bit yet, it is just to aid an ongoing investigation. (cherry picked from commit 1d21b4e)
(cherry picked from commit 8c2d0c5)
…d 'AnyHashable' for dictionary keys.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
(cherry picked from commit 22287dd)
…nt expression kinds. The constraint generator's optimization to eagerly merge type variables for different keys in a dictionary literal was too eager, merging the type variables for (e.g.) a string literal and an integer literal. This prevented us from properly inferring AnyHashable key types in dictionary literals. Fixes the rest of rdar://problem/27661580. (cherry picked from commit 4a569f3)
SILOptimizer: fixed bugs which cause memory leaks.
[swift-3.0-brach] Add pty to Glibc modulemap
Fix crash during type checking when adding members to an extension.
Increase the amount of memory we allow the constraint solver to use.
[Serialization] Fix deserialization crash occurring when a mixed framework fails to load its ObjC part.
This introduces some important diagnostics to help migration. Some of the diagnostics that we would like to provide are impossible on a generic class because they introduce ambiguity. Renaming UnsafePointer<Void> to UnsafeRawPointer makes extensions and global operators ambiguous. We would also like to provide this fix-it on conversion from UnsafePointer<Void> or UnsafeRawPointer to UnsafePointer<T> with this message: Conversion restricted. Use 'assumingMemoryBound(to:)' or 'bindMemory(to:capacity:)'}} However, that introduces ambiguous overloads that defeat other diagnostics.
Add some availability attributes for UnsafePointer conversion.
…al-inference-3.0 Infer existential element/key/value types for collection literals as a fallback
String.UTF16View.Index.distance(to:) was returning a negated result. Fixes SR-1988.
|
Wrong branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
String.UTF16View.Index.distance(to:)was returning a negated result.Reviewed by: @DaveLiu888.
Fixes SR-1988, rdar://problem/27737517.
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
A smoke test on macOS does the following:
device standard libraries are not built.
version of these tests are not run.
A smoke test on Linux does the following:
tests are not run.
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.