[pull] swiftwasm from main #5411
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}
Part of rdar://107388493
When `-unavailable-decl-optimization=stub` is specified, insert a call to `_diagnoseUnavailableCodeReached()` at the beginning of the function to cause it to trap if executed at run time. Part of rdar://107388493
…tubs. User code should not be diagnosed as "unreachable" by the SIL optimizer when the no-return function that made the code unreachable is a compiler inserted call to `_diagnoseUnavailableCodeReached()`. Part of rdar://107388493
Part of rdar://107388493
Part of rdar://107388493
Part of rdar://107388493
Part of rdar://107388493
…thunk. Part of rdar://107388493.
The logic was defaulting to `arm64` when a binary only contained `amr64_32` and `arm64e` slices.
Fixes rdar://108482165.
rdar://108461441
…rted enum rdar://108867547
Previously, the compiler fails to read the result from 'getCapability' IPC message, it used to just emit a fatalError and crashed. Instead, propagate the error status and diagnose it. rdar://108022847
…as such even if the closure doesn't actually escape Specifically, we already have the appropriate semantics for arguments captured by escaping closures but in certain cases allocbox to stack is able to prove that the closure doesn’t actually escape. This results in the capture being converted into a non-escaping SIL form. This then causes the move checker to emit the wrong kind of error. The solution is to create an early allocbox to stack that doesn’t promote move only types in boxes from heap -> stack if it is captured by an escaping closure but does everything else normally. Then once the move checking is completed, we run alloc box to stack an additional time to ensure that we keep the guarantee that heap -> stack is performed in those cases. rdar://108905586
…ng non-consuming uses appropriately. We are doing so now.
…ble twice. We are no longer doing that in the specific test.
Specifically: 1. I added consuming test cases alongside __owned test cases. 2. I inserted the actual error messages so that we can see if we are emitting the correct error messages. 3. I enabled the NONTRIVIAL and NONTRIVIAL/REABSTRACT variants of the tests. There are some differences in the address only version of the test that I am still looking into.
…ther local, emit the correct error message. With some of the changes that I have made, we began to emit a mark_must_check [no_copy] on a copy_addr here. This change teaches the move address checker how to recognize that in this case if we have a project_box it is actually b/c we have something captured by an escaping closure.
…fect forwarding ref they can cause compiler crashes
If we don't split up the tuple into individual constraints, we end up spending more time querying whether a tuple is Copyable in `lookupConformance`, because it will naively check the types of all elements of the tuple recursively with `lookupConformance`. This is inefficient because if we know some of the elements of the tuple are fixed types, we don't need to keep checking those again. For example, if we have `($T, Int, $U)`, and then try a binding for `$T`, we might ask again if the whole tuple conforms. Leading to `lookupConformance` to check whether `Int` (and all other elements of the tuple) conforms to Copyable, when we either already know that, or can't answer it yet because it's still a type variable. By splitting up a Copyable constraint on a tuple into invidivual constraints on each of its type elements, we can avoid this redundant work by `lookupConformance`. While today we could short-cut this even further to say that _all_ tuples are Copyable, since we emit an error if a noncopyable type appears in one, that won't be true in the near future. This is the nicer solution we'll want to keep around long-term. After discussing this with Pavel, we don't think there's a good way to add a regression test for this, because the performance issue primarily comes up in specific example programs that aren't amenable to scale tests. resolves rdar://107536402
…ma clang module import' The semicolon actually causes a compiler error in that case
We can't assume that we will always find a viable witness for a protocol requirement when typechecking a `.swiftinterface` file. The assert that assumed there would be a match could fail when building a broken interface or building a valid interface with a broken SDK, causing crashes instead of emitting diagnostics. Resolves rdar://108688535
When the current toolchain is not a Xcode toolchain, derive '-external-plugin-path' poinintng Xcode plugins paths, so we can use plugins in Xcode. rdar://108624128
…nerated header inside of 'pragma clang attribute' block
…n-void Showing the type annotation only makes sense if they are not `Void`. That’s consistent with functions where we also don’t show a `Void` return type. Most importantly, we shouldn’t be showing a `Void` type annotation for attached macros. rdar://108870970
[CursorInfo] Prefer AST based results over solver based
… that could not be emitted in the C++ section of the generated header
Just do an arity check for now
We haven't quite got the semantics we want implemented for `discard` aka `_forget` statements. Allowing people to use `_forget` in noncopyable types that have stored properties that require destruction will not let us implement it the way we'd like in the future without source break. But, if the type only has "trivial" stored properties with a no-op destruction, like `Int`, then we can still provide utility for users like FileDescriptor who just want to disable the deinit and have nothing fancy stored in the type itself. rdar://108877261
Fixes rdar://problem/108481933.
…ired as bridging conversion to AnyObject in structural position. Minor formatting change in previous test case
…x-executors [Executors] Fix delegation chain of Excecutor.enqueue for Job specifically
…lib-abi-without-asserts Tests: Update stability-stdlib-abi-without-asserts
…xx.swift test on Linux and Windows
Swift's consume semantics are not yet supported in C++
SILGen: Wrap captures of parameter packs inside tuples
If two different C++ structs have methods with the same name, both annotated with `SWIFT_COMPUTED_PROPERTY`, ClangImporter previously confused them when one of the structs referenced the other struct. rdar://108990490 / resolves swiftlang#65675
An expression macro can expand not just to code inside the function, but also to a closure. Such a closure needs to be treated similar to any functions generated from a freestanding macro: Its instructions should have locations that point straight into the macro buffer. Instructions that are expanded into the same function as the macro expansion can be represented using inline locations pointing back to the macro expansion, but this is not an option for top-level function declaration. swiftlang#65484 rdar://108618562
[interop][SwiftToCxx] add swift::String overlay constructor for const…
`_forget` usage fixes to match SE-390
…ror-contextually-required-as [Sema] Fix issue 65330 Unhelpful error when missing contextually requ…
…ate decls only emit them for public ones
…property [cxx-interop] Do not mix up computed properties from different records
[AST] NFC: Silence a warning
…available-unemitted-decls-in-cxx [interop][SwiftToCxx] avoid emitting ambiguous C++ overloads and emit unavailable type stubs for top level types that could not be emitted in the C++ section of the generated header
Fix SILDebugScopes for closures expanded from an expression macro.
…sk-group-availability Fix DiscardingTaskGroup availability
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 : )