Resolve conflicts with upstream main
#3657
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
…ontext Tuple splat/implosion is (still) allowed for patterns (with a warning in Swift 5) so we need to use `SingleApply` while looking up members to make sure that e.g. `case test(x: Int, y: Int)` gets the labels preserved when matched with `case let .test(tuple)` and `Compound` when associated values form a tuple pattern.
…for paren patterns A single paren pattern becomes a labeled tuple pattern e.g. `case .test(let value):` should be able to match `case test(result: Int)`. Note that it also means that: `cast test(result: (String, Int))` would be matched against e.g. `case .test((let x, let y))` but that fails during pattern coercion (behavior consistent with what happens in `TypeCheckPattern`).
KeyPath thunk helpers are called from stdlib indirectly through descriptor and its calling-convention in the caller side is SwiftCC. However, the definition side expects C calling-convention, so they can be broken on some architectures, that SwiftCC is not compatible with C-CC on it. This patch changes to use SwiftCC consistently on caller side and definition side. This doesn't have any effect on the ABI stable platforms because SwiftCC is compatible with C-CC on them.
Addresses rdar://83777172
This was fixed by swiftlang#39497
The lookupConcurrencyIntrinsic function only looked in the concurrency module. It is useful to look in other modules for intrinsics too.
The AsyncEntryPoint represents the thunk that is wrapped in a task. This thunk is used to ensure that the main function explicitly calls "exit", and to properly unwrap and report any unhandled errors returned from the user-written main. The function takes on the name `@async_main` in the emitted SIL.
This patch updates the asynchronous main function to run the first thunk of the function synchronously through a call to `swift_job_run`. The runloop is killed by exiting or aborting the task that it is running on. As such, we need to ensure that the task contains an async function that either calls exit explicitly or aborts. The AsyncEntryPoint, that contains this code, was added in the previous patch. This patch adds the pieces for the actual implementation of this behaviour as well as adding the necessary code to start the runloop. There are now four layers of main functions before hitting the "real" code. @main: This is the actual main entrypoint of the program. This constructs the task containing @async_main, grabs the main executor, runs swift_job_run to run the first part synchronously, and finally kicks off the runloop with a call to _asyncMainDrainQueue. This is generated in the call to `emitAsyncMainThreadStart`. @async_main: This thunk exists to ensure that the main function calls `exit` at some point so that the runloop stops. It also handles emitting an error if the user-written main function throws. e.g: ``` func async_main() async -> () { do { try await Main.$main() exit(0) } catch { _errorInMain(error) } } ``` Main.$main(): This still has the same behaviour as with the synchronous case. It just calls `try await Main.main()` and exists to simplify typechecking. Main.main(): This is the actual user-specified main. It serves the same purpose as in the synchronous, allowing the programmer to write code, but it's async! The control flow in `emitFunctionDefinition` is a little confusing (to me anyway), so here it is spelled out: If the main function is synchronous, the `constant.kind` will be a `SILDeclRef::Kind::EntryPoint`, but the `decl` won't be async, so it drops down to `emitArtificalTopLevel` anyway. If the main function is async and we're generating `@main`, the `constant.kind` will be `SILDeclRef::Kind::AsyncEntryPoint`, so we also call `emitArtificalTopLevel`. `emitArtificalTopLevel` is responsible for detecting whether the decl is async and deciding whether to emit code to extract the argc/argv variables that get passed into the actual main entrypoint to the program. If we're generating the `@async_main` body, the kind will be `SILDeclRef::Kind::EntryPoint` and the `decl` will be async, so we grab the mainEntryPoint decl and call `emitAsyncMainThreadStart` to generate the wrapping code. Note; there is a curious change in `SILLocation::getSourceLoc()` where instead of simply checking `isFilenameAndLocation()`, I change it to `getStorageKind() == FilenameAndLocationKind`. This is because the SILLocation returned is to a FilenameAndLocationKind, but the actual storage returns true for the call to `isNull()` inside of the `isFilenameAndLocation()` call. This results in us incorrectly falling through to the `getASTNode()` call below that, which asserts when asked to get the AST node of a location. I also did a little bit of refactoring in the SILGenModule for grabbing intrinsics. Previously, there was only a `getConcurrencyIntrinsic` function, which would only load FuncDecls out of the concurrency module. The `exit` function is in the concurrency shims module, so I refactored the load code to take a ModuleDecl to search from. The emitBuiltinCreateAsyncTask function symbol is exposed from SILGenBuiltin so that it is available from SILGenFunction. There is a fair bit of work involved going from what is available at the SGF to what is needed for actually calling the CreateAsyncTask builtin, so in order to avoid additional maintenance, it's good to re-use that.
This patch changes the main task to inherit the context of the main thread. This should assign the appropriate priority based on how the program was invoked. I've also updated the tests to reflect these changes.
Isolated parameters were introduced with concurrency, so don't mangle names including them in back-deployed code.
The CMake variables to control this were set *after* the inclusion of the Concurrency library, so they didn't have any effect.
SwiftNativeNSObject is part of the core runtime on OS versions that also have the concurrency library, so we need to include a copy of it with the back-deployed concurrency library.
…-backdeployconcurrency-product Don't include tests for back deploy concurrency product
…m64e Re-enable IRGen test opaque_result_type.swift on arm64e
…tuple-pattern [ResultBuilders] A couple pattern matching fixes to make it consistent with `TypeCheckPattern`
Priorities keep shifting since I first wrote this and are apparently different on different OS's and different versions of the same OS. Since the test is checking that entering and exiting tasks doesn't effect the outer-scoped priority, I've set a variable based on the main thread's priories, which should be inherited by the child.
This allows us to remove the dependency on a slow-to-typecheck example for a `sourcekitd-test`.
This is a tiny routine that is useful for writing assertions to be used for quick sanity checks without computing Dominance. It doesn't always make sense to require a pass to maintain and pass around Dominance just for an assert.
Code that handles checked_cast_br can not be factored easily without coding separate paths for each successor.
Fix two bugs: - FirstArgOwnershipForwardingSingleValueInst needs to forward its first operand. - select_value needs to be a ForwardedBorrow for all cases and the default.
don't care about SPECIFIC order of deinits
Re-working async-main
Minor source and doc comments related to OSSA
Fix SelectValue for OSSA
…path-cc-mismatch [IRGen] Emit keypath thunk helpers with swiftcc to match with the caller cc
Seems that VS2019 and other C++ standard libraries include <atomic> as part of either <string> or <vector>, but not VS2017. When swiftlang#38782 landed a new usage of std::atomic started creating compilation problems in the VS2017 builders (eg. https://ci-external.swift.org/job/oss-swift-windows-x86_64/8736/). Including the <atomic> header solves the problem.
…wiftlang#39516) * Fix unnecessary one-time recompile of stdlib with -enable-ossa-flag This includes a bit in the module format to represent if the module was compiled with -enable-ossa-modules flag. When compiling a client module with -enable-ossa-modules flag, all dependent modules are checked for this bit, if not on, recompilation is triggered with -enable-ossa-modules. * Updated tests
…s-again [Distributed] Re-enable runtime tests
This commit adds a new frontend flag that applies debug path prefixing to the paths serialized in swiftmodule files. This makes it possible to use swiftmodule files that have been built on different machines by applying the inverse map when debugging, in a similar fashion to source path prefixing. The inverse mapping in LLDB will be handled in a follow up PR. Second pass at swiftlang#39138 Tests updated to handle windows path separators. This reverts commit f5aa95b.
When targeting `wasm32` we're relying on the alignment padding branch that's used for 32-bit ARM.
[SourceKit] Add option to simulate a long-running request
# Conflicts: # lib/IRGen/GenKeyPath.cpp
Tests for crashes aren't available on WebAssembly/WASI since there's no way to intercept traps or crashes on this platform. Trapping causes the whole Wasm VM to shut down with no way to recover from within the test code.
yonihemi
approved these changes
Oct 6, 2021
| @@ -4,12 +4,14 @@ | |||
| // REQUIRES: concurrency | |||
| // REQUIRES: distributed | |||
|
|
|||
| // rdar://83859906 | |||
| // UNSUPPORTED: OS=windows-msvc | |||
|
|
|||
There was a problem hiding this comment.
Should we exclude wasi in all Distributed Actor tests?
There was a problem hiding this comment.
seems that not all of them are failing, so I'd prefer not to touch these parts until absolutely necessary
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.
No description provided.