[pull] swiftwasm from main #2071
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
The WLAN APIs are used for the native WiFi implementation and is not as generally useful. Extract it into a submodule.
… async. Implements rdar://70506634.
For callers who do not know the actual type of the called function, e.g. when the called function is the result of a partial apply, the offset to the direct returns would otherwise not be known.
Bindings will always be supplied by the first partial apply, so they will only be added to the async context when its full layout is known. If they are earlier in the layout, subsequent partial applies will put their arguments into the wrong position because they will not be privy to the space requirements of the bindings.
The convenience was added to aid with the async calling convention but it has proven to be unnecessary. Here, it is removed.
Partial applies of methods supply only self. When applies of the resulting thick function are performed, that self was one of the arguments is not known. As a result, self must appear after the fields that might be supplied at the apply site, which is to say all the arguments.
I removed the implementation in swiftlang#34151
The "wave" of a compilation job describes the number of indirections through other compile jobs the driver required to reach the decision to schedule a job. In incremental mode, it should always be the case that it takes no more than two complete waves to arrive at a fixpoint in the build. This is a natural consequence of the structure of the dependencies emitted by the Swift frontend - namely we rely on transitivity in dependency arcs. A quick proof sketch: Suppose an arbitrary perturbation of the inputs to an incremental compilation session are made. In the first wave, dependency edges from the prior build's state (the "zeroeth wave") are loaded and the files corresponding to invalidated edges are scheduled into the first wave. Supposing the second wave is not the null set - the trivial case - there are additional arcs that were invalidated. Now suppose that there were a third wave. Take an arbitrary arc invalidated by this third wave. It must be the case that the file containing the use is not new - else it would be scheduled. Further it must be the case that its def was not invalidated by the zeroeth or first waves of compilation otherwise we would have scheduled it into the first or second waves. Finally, it must have a use that was discovered in the second wave. But in order for that use to have been included in the second wave, there must have been an invalidated arc created by the first wave. By transitivity of dependency arcs, there must therefore be a dependency arc from a definition invalidated in the first wave to our third wave job, which implies that the file would be scheduled into the second wave! [Insert contradiction pig image here]
Name adjustments should be performed by omitNeedlessWords(), not the early classifcation of async imports.
Also, rename them to follow the general namespacing scheme.
Make all tasks into heap objects.
…ods. The "Asynchronously" is a needless word for an "async" function. Remove it.
…leFunctionKind() getFragileFunctionKind() would report that all initializers in non-resilient public types were inlinable, including static properties. This was later patched by VarDecl::isInitExposedToClients(), which was checked in diagnoseInlinableDeclRefAccess(). However, the latter function only looked at the innermost DeclContexts, not all parent contexts, so it would incorrectly diagnose code with a nested DeclContext inside of a static property initializer. Fix this by changing getFragileFunctionKind() to call isInitExposedToClients() and simplifying diagnoseInlinableDeclRefAccess(). This commit also introduces a new isLayoutExposedToClients() method, which is similar to isInitExposedToClients(), except it also returns 'true' if the property does not have an initializer (and in fact the latter is implemented in terms of the former).
There's no need to check for that here, because we also run diagnoseDeclRefExportability() on declarations referenced from inlinable code. This changes some diagnostics; we now produce the same diagnostic for references to SPI types in declaration signatures and for references to non-type SPI declarations in inlinable function bodies. Also note that the old inlinable reference diagnostic no longer has to handle the 'public' and 'open' access levels, which previously happened for '@_spi'; so I changed those entries in the %select to %error.
…Frozen structs We require that all stored properties in a @Frozen struct have public or @usableFromInline types, even if the property itself is not public. This is so that clients can correctly generate code to manipulate the @Frozen struct. This check was only looking for bona-fide stored properties, and missing out looking at properties that have backing storage, namely 'lazy' properties and property wrappers.
…attribute is allowed We need to prohibit 'lazy' properties and property wrappers from being declared @_spi inside of a @Frozen struct. Making them SPI doesn't make sense, because these properties will be omitted from the module interface and not taken into account when clients manipulate values of this type.
Even if a nominal type does not have its own generic parameters, we need to visit its conformances, because it might be defined in a constrained extension or have a 'where' clause of its own.
In @Frozen structs, stored properties and property wrappers must have inlinable initial value expressions, since they are re-emitted into designated initializer bodies, which themselves might be @inlinable. However, 'lazy' properties don't follow this pattern; the initial value expression is emitted inside the getter, which is never @inlinable.
Platform: extract `WLANAPI` module on Windows
…et-async [Concurrency] Asynchronous Objective-C method importer naming adjustments
…-fixes Another pile of availability checking fixes
Implicitly import _Concurrency under -enable-experimental-concurrency
Refine task APIs and introduce an API for task creation
The majority of support comes in the form of emitting partial
application forwarders for partial applications of async functions.
Such a partial application forwarder must take an async context which
has been partially populated at the apply site. It is responsible for
populating it "the rest of the way". To do so, like sync partial
application forwarders, it takes a second argument, its context, from
which it pulls the additional arguments which were capture at
partial_apply time.
The size of the async context that is passed to the forwarder, however,
can't be known at the apply site by simply looking at the signature of
the function to be applied (not even by looking at the size associated
with the function in the special async function pointer constant which
will soon be emitted). The reason is that there are an unknown (at the
apply site) number of additional arguments which will be filled by the
partial apply forwarder (and in the case of repeated partial
applications, further filled in incrementally at each level). To enable
this, there will always be a heap object for thick async functions.
These heap objects will always store the size of the async context to be
allocated as their first element. (Note that it may be possible to
apply the same optimization that was applied for thick sync functions
where a single refcounted object could be used as the context; doing so,
however, must be made to interact properly with the async context size
stored in the heap object.)
To continue to allow promoting thin async functions to thick async
functions without incurring a thunk, at the apply site, a null-check
will be performed on the context pointer. If it is null, then the async
context size will be determined based on the signature. (When async
function pointers become pointers to a constant with a size i32 and a
relative address to the underlying function, the size will be read from
that constant.) When it is not-null, the size will be pulled from the
first field of the context (which will in that case be cast to
<{%swift.refcounted, i32}>).
To facilitate sharing code and preserving the original structure of
emitPartialApplicationForwarder (which weighed in at roughly 700 lines
prior to this change), a new small class hierarchy, descending from
PartialApplicationForwarderEmission has been added, with subclasses for
the sync and async case. The shuffling of arguments into and out of the
final explosion that was being performed in the synchronous case has
been preserved there, though the arguments are added and removed through
a number of methods on the superclass with more descriptive names. That
was necessary to enable the async class to handle these different
flavors of parameters correctly.
To get some initial test coverage, the preexisting
IRGen/partial_apply.sil and IRGen/partial_apply_forwarder.sil tests have
been duplicated into the async folder. Those tests cases within these
files which happened to have been crashing have each been extracted into
its own runnable test that both verifies that the compiler does not
crash and also that the partial application forwarder behaves correctly.
The FileChecks in these tests are extremely minimal, providing only
enough information to be sure that arguments are in fact squeezed into
an async context.
…en/partial-apply
Add Compilation "Wave" Assertion in +Asserts Builds
kateinoigakukun
approved these changes
Oct 23, 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]. Want to support this open source service? Please star it : )