-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove unnecessary unsafeUnwrap
calls.
#2
Conversation
Since `dropFirst` does not return an `Optional`, `unsafeUnwrap(xs.dropFirst())` first implicitly wraps result of `dropFirst` into an optional and then calls `unsafeUnwrap` on that.
Nice. I wonder if we should do something to make it a compilation error to pass a non-optional to |
This pull request has a single commit, so I think it is okay to accept it because this merge will be just like a regular rebased commit to master. |
It’s not going to be rebased just because it’s a single commit, @nadavrot. |
@dabrahams Making |
@gribozavr the only question is whether we want it to show up in completion lists. I think people type “.” on a known optional infrequently, but if they don’t remember the thing is an optional it might well lead them astray. |
Cherry-picked into master. |
… the left-hand side. Rather than using a specialized matching rule in the type checker that depends on having default arguments in types, use call argument matching consistently. Note #1: This (correctly) breaks some existing code that depends on inferring a parameter type of () for a single-argument parameter from a no-argument function type(). Note #2: This pessimizes a code completion test, where the code completion engine seems to depend on some quirks of argument matching. The "type relationship" matching needs non-trivial work.
There's no need for a deferred conversion in these cases. This time committing ALL the changes needed to get the validation tests to pass.
While trying to reuse the liveness-points analysis originally in DI for injecting actor hops for more general purposes, Pavel and I discovered that the point at which we are injecting the hops might not have fully-computed the liveness information. That appears to be the case because we were computing the fully-initialized points before having processed destroy/releases of TheMemory. While this most likely had no influence on the actor hop injection, it does affect what the outgoing AvailabilitySet contains for a block. In particular, for this example: ```swift struct X { init(cond: Bool) { var _storage: (name: String, age: Int) _storage.name = "" if cond { _storage.age = 30 } else { _storage.age = 40 } } } ``` But because we are determine the full initialization points before processing the destroy, the liveness analysis doesn't iterate to correctly determine the out-availability of block 1 and 3 (corresponding to the then and else blocks in the example above). Here's the debug output showing that issue: ``` *** Definite Init looking at: %5 = mark_uninitialized [var] %4 : $*(name: String, age: Int) // users: %37, %12, %22, %32 Get liveness 0, swiftlang#1 at assign %11 to %13 : $*String // id: %14 Get liveness 1, swiftlang#1 at assign %21 to %23 : $*Int // id: %24 Get liveness for block 1 Iteration 0 Result: (yn) Get liveness 1, swiftlang#1 at assign %31 to %33 : $*Int // id: %34 Get liveness for block 3 add block 2 to worklist Iteration 0 Block 2 out: (yn) Iteration 1 Block 2 out: (yn) Result: (yn) full-init-finder: rejecting bb0 b/c non-Yes OUT avail full-init-finder: rejecting bb1 b/c non-Yes OUT avail full-init-finder: rejecting bb2 b/c no non-load uses. full-init-finder: rejecting bb3 b/c non-Yes OUT avail full-init-finder: rejecting bb4 b/c no non-load uses. Get liveness 0, swiftlang#2 at destroy_addr %5 : $*(name: String, age: Int) // id: %37 Get liveness for block 4 add block 3 to worklist add block 1 to worklist Iteration 0 Block 1 out: (yy) Block 3 out: (yy) Iteration 1 Block 1 out: (yy) Block 3 out: (yy) Result: (yy) ``` So, this patch basically just sinks the computation so it happens after, so that we force the incremental liveness analysis to also consider the liveness at the point of the destroy, but before having done any other transformations or modifications to the CFG to handle a destroy of something partially initialized.
Add "platforms" field to readme examples
# This is the 1st commit message: utils: update the build-windows-toolchain.bat to extract the toolchain Fetch a prebuilt toolchain to build the toolchain. This is required to enable the macro support on Windows. # The commit message swiftlang#2 will be skipped: # build: build SwiftSyntax before the toolchain build # # Perform a build of Swift Syntax prior to the build of the toolchain so # that we can enable the early swift syntax parser builds. This is a # prerequisite for enabling macros on Windows. # The commit message swiftlang#3 will be skipped: # # This is a combination of 5 commits. # # This is the 1st commit message: # # build: wire up the early swift-syntax build to the build # # This enables the early swift syntax build to get us macro support on # Windows. # # # The commit message swiftlang#2 will be skipped: # # # Update build-windows-toolchain.bat # # # The commit message swiftlang#3 will be skipped: # # # Update build-windows-toolchain.bat # # # The commit message swiftlang#4 will be skipped: # # # Update build-windows-toolchain.bat # # # The commit message swiftlang#5 will be skipped: # # # Update build-windows-toolchain.bat
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
Since
dropFirst
does not return anOptional
,unsafeUnwrap(xs.dropFirst())
first implicitly wraps result ofdropFirst
into an optional and then callsunsafeUnwrap
on that.