forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
[pull] swiftwasm from main #2225
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
Merged
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
…e is not longer necessary Since closure body isn't opened until its contextual type is resolved there is no need to explicitly delay attempting bindings for closure parameter used in the body anymore.
All SIL instructions need their semantics specified in SIL.rst and their constraints specified in SILVerifier.
That prevents the SILVerifier from printing the context, making it hard to quickly produce test cases from logs. Instead, just return the failure status to the SILVerifier so it can do its diagnostic thing. An assert or llvm_unreachable would also be fine in addition to the normal SILVerifier diagnostics, but I don't think that's needed here.
This reverts commit e51575b.
…and Haiku Follow suit from linux, swiftlang#29581, tested on Android.
This new builtin allows the creation of a "future" task, which calls down to swift_task_create_future to actually form the task.
rdar://71427419
…l_apply [on_stack] only (swiftlang#34736)
…_alloca_async IRGen: Fix debug emission for dynamically sized stack vars
I can't reason about whether this is correct to do, because SIL both uses the side-effects semantics to model arbitrary implicit dependencies and simultaneously considers them to be memory writes. What's more, the SIL instruction definitions almost *never* specify the actual constraints that we're attempting to approximate with the model. Be that as it may, we can't verify SIL if we "conservatively" consider instructions that don't write to memory to be writes. So I'll attempt to fix the undocumented model and find out what breaks. Fixes rdar://70737095 Unknown instruction: unchecked_ownership_conversion
Previously, the thick context was passed as a fourth parameter to partial apply forwarders. Here, the thick context is instead moved into the async context at the local context position. To support this, the local context is made always available.
…) can find them We would like it if objc_copyClassList() would find non-generic classes with generic ancestry, as long as they ultimately inherit from an @objc class. Make this so by emitting class stubs in a few more cases. Fixes <rdar://problem/71194117>.
We have two ways of knowing if we're inside of an inactive #if clause. Refactor the only two places that called getScopeInfo().isInactiveConfigBlock() to check InInactiveClauseEnvironment instead. This removes the last remaining usage of Scope that's not related to parse-time name lookup.
…allocator_size_alignment_requirement Reinstate task allocator size alignment requirement
Mark the test as requiring Concurrency support
Now that the convention for partial apply forwarders of async functions is that the thick context is embedded within the async context, there is never a need for a placeholder thick context. Here, the placeholder thick context is only added when the function for which a partial apply forwarder is being emitted is not async.
…ctor [ConstraintSystem] Infer some of the bindings attributes on demand
…-builtin [Concurrency] Add Builtin.createAsyncTaskFuture and implement runDetached on it
…cTaskFuture Thick async functions store their async context size in the closure context. Only if the closure context is nil can we assume the partial_apply_forwarder function to be the address of an async function pointer struct value.
Also, store the end location of the where clause explicitly, so that we can recover it even if there are no requirements. This fixes one of the failing tests when parser lookup is disabled in swift-ide-test by ensuring that the source range of the function extends to the end of the 'where' clause, even though the 'where' clause has a code completion token in it.
…crete-subclass-of-generic Emit Objective-C resilient class stubs for concrete subclasses of generic subclasses of NSObject
…en/thick-context-in-async-context [Async CC] Move thick context into async context.
…en/no-thick-placeholder-for-async-pafs [Async CC] Don't add thick placeholder to args from partial apply forwarder.
…nesupport [Frontend] Disable skipping any function bodies for SwiftOnoneSupport
…rser-lookup Disable parse-time name lookup in swift-ide-test
…tion Handle unowned and unmanaged references.
…ns_create_async_tasks Fix lowering of Builtin.createAsyncTask and Builtin.createAsyncTaskFuture
Add regression tests for a number of casting cases that were fixed by recent work: * SR-13812 (aka rdar://70999129) Verify that the new casting logic correctly handles a generic `is` test for a struct conforming to a protocol. * SR-8964 (aka rdar://45217461) Test casts from Any! holding Error types * SR-1999 (aka rdar://48769924) * SR-6279 (aka rdar://35321438 * rdar://59844232 * SR-12025 Note that SR-12025 is not actually fixed yet; this test is marked "expected failure" until it is.
This assert does not make sense because consumingUses in some cases only contains the destroying uses. Owned values may not be destroyed because they may be converted to ValueOwnershipKind::None on all paths reaching a return. Instead, this utility needs to find liveness first considering all uses (or at least all uses that may be on a lifetime boundary). We probably then won't need this assert, but I'm leaving the FIXME as a placeholder for that work. Fixes rdar://71240363.
Specify the unchecked_ownership_conversion instruction
[build] Remove remaining dependencies on libatomic, for Android, BSD and Haiku
…-lookup Remove parse-time name lookup
Broken by: Emit Objective-C resilient class stubs for concrete subclasses of generic subclasses of NSObject swiftlang#34766 swiftlang#34766 Workaround for rdar://71476765
MaxDesiatov
approved these changes
Nov 17, 2020
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )