[pull] swiftwasm from main #5402
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}
…able pack expansion Examine pack expansion pattern to determine whether expression result could be discarded without a warning (applies to tuples with a single unlabeled pack expansion element as well). Resolves: rdar://108064941
We started using clang to emit the _OBJC_PROTOCOL_ definition. But we would use a different name for the proto_list definition than clang. "OBJC_LABEL_PROTOCOL$" (objc) |--> OBJC_PROTOCOL "\01l_OBJC_LABEL_PROTOCOL$_" (swift) |--> OBJC_PROTOCOL If an Objective C object also emitted the same protocol definition you could end up in a situation where both clang's and swift's proto_list definitions point to the same protocol definition. Older linkers don't like that. rdar://108505376
rdar://107030743
… attempted as placeholder Diagnose base inference failure only if base gets inferred to be a placeholder, any transitive placeholder inference points to the problem being elsewhere.
We parse `~Copyable` in an inheritance clause of enum and struct decls as a synonym for the `@_moveOnly` attribute being added to that decl. This completely side-steps the additional infrastructure for generalized suppressed conformances in favor of a minimal solution. One benefit of this minimal solution is that it doesn't risk introducing any back-compat issues with older compilers or stdlibs. The trade-off is that we're more committed to supporting `@_moveOnly` in compiled modules in the future. In fact, this change does not deprecate `@_moveOnly` in any way. resolves rdar://106775103
Attached macro mangles for accessors were using a fallback case that triggers an assertion in +Asserts builds, and conflicting manglings is non-Asserts builds. Provide a custom mangling for these cases that's embedded in the identifier. This is a narrow hack to eliminate an assertion. We are considering a different approach for the long term that uses entity manglings with a placeholder type, which will be more flexible long-term.
Resolves rdar://108069565
Properties may have `@_spi` setters and therefore the exportability of a referenced accessor may differ from the exportability of the storage.
In an earlier version of the ASTScope -> SILdebugScope translation a workaround was put into place that would select the current debug scope if an ASTScope was marked as ignoreInDebugInfo. Removing this workaround makes the translation more predictable as it eliminated the dependency on the current SILBuilder state. The property wrapper tests still pass without this. This uncovers a situations with let bindings where the SIL instructions are emitted RHS before LHS, which does violate the di-hole verifier. This is addressed by relaxing the verifier for now. rdar://108736443
In swiftlang#65417 , support for promoting moved-from `load [copy]`s was added. At that time, the existing logic was generalized so that the check for whether writes the loaded-from address occurred: rather than checking whether the writes occurred in the live-range of the `load [copy]`, it was generalized to check whether writes occurred in the live range of the "original" value which was either the `load [copy]` or the `move_value`. That opened a hole for writes that occurred between the `load [copy]` and the `move_value`: ``` %v = load [copy] %a %u = load [take] %a %m = move_value %v ``` Here, this is fixed by checking both the live-range of the "original" and also (supposing the original is different from the `load [copy]`) also the live range of the `load [copy]`. This required changing the list of consuming uses passed to the `LinearLifetimeChecker::usesNotContainedWithinLifetime` to include not just the `destroy_value`s but also the "unknown" consuming uses (i.e. those that are not forwarding). This change only affects arguments (and specifically only `@inout` arguments since promotion for `@in` arguments isn't supported) because a totally different code path is followed for `alloc_stack`s which regards `load [take]`s as an "init" of the address (concretely, `getSingleInitAllocStackUse` returns `truea for the above example if `%a` is an `alloc_stack`). rdar://108745323
Fixes rdar://problem/107151125.
Lookups in submodules do not work and are explicitly ignored in the clang importer
… feature" This reverts commit b412c6c. Resolves rdar://108591384
…ng_for_objc_protocols_by_deploy_target_2nd IRGen: Only use clang protocol emission on newer deployment targets
…accessors-mangle
…-bindings [CSBindings] NFC: Diagnose leading-dot inference failure when base type is…
[Macros] Serialize plugin search paths for LLDB use
[Diagnostics] Suppress unused expression warning if result is discard…
The constraint solver would supply its own version of the function that can check for pack expansion type variables as well.
This flag indicates that a type variable could only be bound to PackExpansionType and nothing else.
Models `PackExpansionType` as a type variable that can only bind to `PackExpansionType` and `expansion of` constraint that connects expansion variable to its pattern, shape types.
…solved pack expansions If a pattern type of a pack expansion doesn't have all of the "pack capable" type variables bound, we don't know what the structure is yet and expansion cannot be flattened.
A pack expansion type variable gets bound to its original pattern type when solver can infer a contextual type for it. This makes sure that pack expansion types are always matched via `matchTypes` without `simplifyType` involvement which can expand them prematurely.
Even if both sides are pack expansion variables they cannot be merged because merging of them means merging of pattern and shape types as well, which is easier to do when one of both sides are bound.
…nstraints Tuple types cannot be matched until all pack expansion variables are resolved, the same is applicable to `shape of` constraints because the structure of the pack is not fully resolved in such cases.
The constraint takes two pack types and makes sure that their reduced shapes are equal. This helps with diagnostics because constraint has access to the original pack expansion pattern types.
…ed to arguments Suggest to drop tuples, synthesized or remove extraneous arguments based on pack shape mismatches.
If diagnostic references a `Pack{repeat ...}` unwrap it to underlying
pattern.
…pect a tuple argument
Diagnose situation when a single argument to tuple type is passed to
a value pack expansion parameter that expects distinct N elements:
```swift
struct S<each T> {
func test(x: Int, _: repeat each T) {}
}
S<Int, String>().test(x: 42, (2, "b"))
```
…at expects individual arguments
Propagating holes to the shape helps avoid spurious diagnostics about same-shape requirement failures. Resolves: rdar://107675464
Situations like `repeat x` where `x` is `Int` where pack expansion expression doesn't have any pack references.
Detect that pack expansion expression doesn't have any pack references during constraint generation. Resolves: rdar://107835215
libstdc++ currently cannot be split into submodules due to the way some types are defined, e.g. there are multiple headers that define `size_t`, so those headers must be a single (sub-)module.
…able Build support for `~Copyable` atop `@_moveOnly`
[SemanticARCOpts] Check uses in moved load range.
…rit-spi Sema: Inherit SPI groups when synthesizing modify accessor
[interop] lookup FRT retain/release functions in top level module
Remove a stateful workaround for Property Wrappers.
[ConstraintSystem] Model pack expansion types via type variables
…port-cxxstdlib [cxx-interop] Update a test on Linux
…pilers. Revert a few unnecessary changes have been made to the _Concurrency module recently that make its swiftinterface un-parseable by older compilers that we need to support. - The `consume` keyword is not understood by older compilers, so including it in inlinable code is a problem. It has no actual effect on lifetimes where it was used, so just omit it. - Don't build the _Concurrency module with -enable-experimental-feature MoveOnly. The MoveOnly feature is now enabled by default in recent compilers, so the flag is superfluous when building the dylib. When emitting the interface, having the feature enabled explicitly exposes code guarded by `$MoveOnly` to older compilers that do not accept all of the code. Resolves rdar://108793606
…ts-for-macOS-toolchain-package [build] Reenable lldb tests for macOS toolchain package
Previously the index data differed when using `Foo, Bar` vs `Foo & Bar`. Fixes swiftlang#56255 This reverts commit 5e2c7a9.
…-pack-mangling ASTMangler: Fix mangling of SILFunctionType with @pack conventions
Older compilers can't parse `name(init)`. Restore the call to `escapeKeywordInContext()` to ensure special names get escaped. Resolves rdar://108806697
…ondfails Concurrency: Make _Concurrency module interface parseable by older compilers
Macros: Escape `init` when printing names for attached macros
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 : )