Skip to content

[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
merged 55 commits into from
Nov 17, 2020
Merged

[pull] swiftwasm from main #2225

merged 55 commits into from
Nov 17, 2020

Conversation

pull[bot]
Copy link

@pull pull bot commented Nov 16, 2020

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

xedin and others added 24 commits November 11, 2020 12:35
…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.
…_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
nate-chandler and others added 5 commits November 16, 2020 12:02
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
compnerd and others added 26 commits November 16, 2020 13:02
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
Broken by:
Emit Objective-C resilient class stubs for concrete
subclasses of generic subclasses of NSObject swiftlang#34766
swiftlang#34766

Workaround for rdar://71476765
@pull pull bot merged commit 2bb9c8f into swiftwasm Nov 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.