[pull] swiftwasm from main #3509
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}
…ntials Implemented the necessary code, replacing a "XXX TODO XXX" comment. rdar://74414189
DummyFramework.framework has two different properties to support two different kinds of test cases: to support ModuleInterface/build-alternative-interface-framework.swift, its macOS interfaces are broken, but to support ModuleInterface/arm64e-fallback.swift, it supports only arm64, not arm64e, on iOS. The arm64e test's behavior is about to change, which will complicate all of this. As a preliminary step, make the two tests use two different frameworks so they aren't so intertwined. This temporarily keeps the arm64e test using the name "DummyFramework", but that will change.
Set the flag to indicate the availability of the -library-level flag in the compiler and driver. As driver submissions can be delayed we are integrating this flag late as a safety measure. rdar://82742547
If we are building for ARM64 but we try to import a module with only an ARM64e interface, fall back to importing said interface. This is the reverse of a similar fallback briefly introduced last year, but removed in swiftlang#31196.
Literal closures are only ever directly referenced in the context of the expression they're written in, so it's wasteful to emit them at their fully-substituted calling convention and then reabstract them if they're passed directly to a generic function. Avoid this by saving the abstraction pattern of the context before emitting the closure, and then lowering its main entry point's calling convention at that level of abstraction. Generalize some of the prolog/epilog code to handle converting arguments and returns to the correct representation for a different abstraction level.
Remove the canonicalVararg parameter and CanParamArrayRef wrapper. Almost none of the callers want canonicalVararg, and the one that does calls `getCanonicalType` on the result anyway.
By default avoid imploding params that have parameter flags, but carve out exceptions for ownership flags, which can be thunked, and `@_nonEphemeral` which can be freely dropped without issue.
Reject tupling into a `@differentiable` function, and allow the stripping of `@noDerivative` given we're also losing `@differentiable`.
Tuple and paren types may still have parameter type flags in certain cases, but they should never make it into expressions.
…ted type name before protocols The canonical order on associated types compares the name before the protocol, so for example T.[P2:A] < T.[P1:B]. Make sure the reduction order does the same so that we correctly compute canonical types in this case.
…ializer to create Strings from them
ClangImporter: import SPIs from underlying clang modules by default
…-at-context-abstraction-3 SILGen: Emit literal closures at the abstraction level of their context. [take 3]
…urrency-resilience Ensure that we build back-deployed concurrency libraries with library evolution
Expose __SwiftNativeNSString for Foundation's use, as well as an initializer to create Strings from them
Add arm64 -> arm64e fallback to module loading
…uple [AST] Enforce that TupleExprs and ParenExprs dont have param flags
…ssoc-type-fix RequirementMachine: Reduction order on symbols should compare associated type name before protocols
[Driver] Define the feature flag library-level
MaxDesiatov
approved these changes
Sep 11, 2021
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 : )