[pull] swiftwasm from main #5288
Merged
Conversation
This file contains 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}
Radar-Id: rdar://problem/88093007
Radar-Id: rdar://problem/88093007
other threads/tasks which have a reference to the task might need to access parts of it even if the task itself is completed. Radar-Id: rdar://problem/88093007
Part of rdar://104192094
field of an ActiveTaskStatus can also be modified while the TaskStatusRecord list is being modified. Make the StatusRecordLock reentrant. Radar-Id: rdar://problem/88093007
task is blocked on. We can use this information to then perform live priority escalation to a task future. Radar-Id: rdar://problem/88093007
If a module was first read using the adjacent swiftmodule and then reloaded using the swiftinterface, we would do an up to date check on the adjacent module but write out the unit using the swiftinterface. This would cause the same modules to be indexed repeatedly for the first invocation using a new SDK. On the next run we would instead raad the swiftmodule from the cache and thus the out of date check would match up. The impact of this varies depending on the size of the module graph in the initial compilation and the number of jobs started at the same time. Each SDK dependency is re-indexed *and* reloaded, which is a drain on both CPU and memory. Thus, if many jobs are initially started and they're all going down this path, it can cause the system to run out of memory very quickly. Resolves rdar://103119964.
…rs (not "cxx method conventions"). Otherwise we will incorrectly use the "self" type's conventions when lowering the parameters (off-by-one).
Since the unsafe iterator types are now used throughout the overlay, not just by `CxxSequence` and `CxxRandomAccessCollection`, let's move them to a separate file.
I had a fix a bunch of bugs in this, which isn't very surprising. I changed remapSubstitutionMap to preserve the non-canonical signature of the substitutions because otherwise it messes up printing open_pack_element pretty badly --- we end up printing a sugared shape class but a desugared generic signature. I'd rather not eagerly canonicalize everything there because the sugar is quite nice. Still, I don't feel great about this approach, and this is the second time I've found myself doing something a little gross in order to preserve sugar for printing this instruction. Canonicalizing the replacement types is important for test stability, and I think it's good downstream. The most interesting part of this is that I implemented a rule which handles tuple types becoming scalar as part of the substitution of tuple_pack_element_addr. We talked about having this rule in the formal type system, and I thought we were going to do it, but it looks like we haven't actually implemented that yet. I added it to SIL substitution because (1) I anticipate we'll be doing this eventually in the formal type system, and that will have consequences for SIL, and (2) we don't actually have a way to parse these singleton tuple types, and I didn't want expanding singleton packs into tuples to become this weird untestable corner case. I did have to poke a hole in this rule to preserve types that were singleton tuples before substitution, since apparently AutoDiff makes a lot of those. I think adding a type_refine_addr that statically asserts a type match is the right way to go in the long term for rewriting singleton tuple_pack_element_addr, but I'm a little sick of adding SIL instructions, so we just rewrite to unchecked_addr_cast for now.
…DeclCarryingInst. I discovered when working with improving the debug output of the move only address checker that I had a need for lightweight thing like DebugVarCarryingInst but that only could vend a VarDecl (unlike DebugVarCarryingInst which also can vend a SILDebugVariable). As an example, this lets one write a high level API that uses the standard API to loop over a bunch of instructions all that vend a VarDecl and construct a stringified path component list. rdar://105293841
This reflects better the true meaning of this check which is that a value marked with this check cannot be consumed on its boundary at all (when performing let/var checking) and cannot be assigned over when performing var checking.
…AndAssignable This fits the name of the check better. The reason I am doing this renaming is b/c I am going to add a nonconsumable but assignable check for global_addr/ref_element_addr/captures with var semantics.
This is used to model global_addr/ref_element_addr/escaping closure captures
where we do not want to allow the user to consume the memory (leaving the memory
in a potentially uninitialized state), but we do want to allow for the user to
assign over the memory all at once.
Consider a situation like the following:
```
@_moveOnly
struct FileDescriptor {
var state: CInt = ...
}
final class Klass {
var descriptor = ...
}
func consumeDescriptor(_ x: __owned FileDescriptor) {}
// Eventually both of these will point at the same class.
var globalKlass = ...
var globalKlass2 = ...
func memoryUnsafe() {
consumeDescriptor(globalKlass.descriptor)
consumeDescriptor(globalKlass2.descriptor)
}
func callMemoryUnsafe() {
globalKlass2 = globalKlass()
memoryUnsafe()
}
```
Notice how in the above in memoryUnsafe, locally the compiler has no way of
knowing that globalKlass and globalKlass2 actually point at the same class and
thus we are attempting to consume the same descriptor twice. This is even
allowed by exclusivity. If descriptor was not move only, this would be safe
since we would just copy the value when we consume it. But b/c we ar3e using
move only, we must take from the memory.
Mark the test as requiring reflection as it uses the new `_Runtime` module.
…spatch-execution.cpp.
… on Apple Silicon See apple#62017
Previously wtable packs were never forwarded because pack types consisting of a single element which was itself a pack archetype were never canonicalized into that. In the forwarding scenario, gepped and loaded from wtable when lowering open_pack_element.
Moved a few static helpers to the top.
…aths Effects are only defined for operations which don't involve a load. In case the argument's path involves a load we need to return the global effects.
…rgen/wtable-forwarding [IRGen] Forwarded wtable packs when possible.
[interop][SwiftToCxx] dispatch virtual calls via thunks for resilient…
[cxx-interop] NFC: move unsafe iterator types to a separate file
[Macros] Respect VFS overlays when loading plugins
[Reflection] Use bytes in lock size
[Macros] Initial implementation of peer macros.
The result values of the expansion requests for attached macros tended to be useless, because most of their operation is via side effects on the nodes they are attached to. Replace the result values with an array of expansion buffer IDs, so clients can see what effect the macro expansion had.
Macro expansion buffers, along with other generated source buffers, need more precise "original source ranges" that can be had with the token-based `SourceRange`. Switch over to `CharSourceRange` and provide more thoughtfully-determined original source ranges.
Extend the macro-expansion refactoring to work with member and member-attribute attached macros. These expansions can return several different changes, e.g., adding new members, sprinkling member attributes around, and so on.
…escalation-to-future Provide support for live priority escalation in the task runtime
[interop][SwiftToCxx] use vtable offset/thunk to dispatch class property and subscript accessors
…nd signed method pointer on arm64e
No test case at the moment, but it's pretty crashy here in practice :)
…ilure Update PartialType.swift
[Index] Prevent re-indexing system modules repeatedly
Add a pack_length SIL instruction for measuring the length of a pack
Fix two bugs in side effect computation
…-loc [SourceKit] Disable optimization that's now incorrect with macros.
[interop][SwiftToCxx] dispatch swift class methods using signed isa a…
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 : )