[pull] swiftwasm from main #4080
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}
The API is not constrained to methods only, it should support computed properties as well.
…esult builder context
…erence` Instead of checking the frontend flag directly, let's use dedicated method on a constraint system to determine whether closure did participate in inference or not.
…re inference in result builder contexts Multi-statement closure inference doesn't play well with result builders at the moment because it expects all of the information from the parent statements to be inferred before solver starts working on the body of a nested closure. Let's prevent inference for nested multi-statement closures until result builders are ported to use conjunctions and solve the body incrementally top-down instead of in one shot.
These are just invariant checks which will become obsolete as soon as multi-statement closure inference is enabled by default.
…t closures This test-case used to crash with multi-statement closure inference enabled in result builder contexts.
…Type As a small step toward moving away from having a bespoke generic environment for each OpaqueTypeArchetypeType, create the types without the generic environment and only build it lazily.
We were always mangling based on the last generic parameter, which makes sense when there is only one opaque result type, but is incorrect when there are multiple opaque result types, e.g., due to named or structural opaque result types.
…hing. Introduce a new primitive operation on opaque type archetypes that canonicalizes a type within the environment of the opaque type archetype without building the environment itself. Use it when matching opaque archetype types in the solver.
…ion. Creation of the "bound" generic signature isn't possible with interface types or type variables, so open up the opaque interface signature instead and separately bind the outer type parameters as appropriate.
…types. Teach `GenericEnvironment` how to lazily create opaque type archetypes, performing the contextual substitutions as required but without building the "bound" generic signature until required. To get here, augment `GenericEnvironment` with knowledge of the purpose of the environment, whether it is for normal cases (any signature), an opened existential type, or an opaque type. For opaque types, store the opaque type declaration and substitution map, which we also use to uniquely find the generic environment. Among other things, this ensures that different opaque type archetypes within the same opaque type declaration are properly sharing a generic environment, which wasn't happening before.
…nment. When forming the generic signature of a generic environment for opaque types, substitute for the outer generic parameters based on the provided substitution map. We weren't able to do this before because the substitution cannot be performed when there are interface types or type variables involved. However, the lazy construction of this generic signature and use of other queries on opaque type archetypes ensures that we don't form new generic signatures until we have concrete types to work with. This enables same-type constraints amongst different opaque result types and their associated types.
…andled in the property map
…ion domain When minimizing a generic signature, we only care about loops where the basepoint is a generic parameter symbol. When minimizing protocol requirement signatures in a connected component, we only care about loops where the basepoint is a protocol symbol or associated type symbol whose protocol is part of the connected component. All other loops can be discarded since they do not encode redundancies that are relevant to us.
On arm64e, this test generates incorrect output. rdar://86825277
[Distributed] NFC: Remove `Method` from accessor APIs
…rence-inside-result-builder-bodies [ConstraintSystem] SE-0326: Temporarily prevent multi-statement closure inference in result builder contexts
…ype-environment
This addresses most of the options with computed defaults. Addresses rdar://86723940
…-map-rewrite-loops RequirementMachine: More fixes for property map induced rules
Conditionally disable tsan/racy_async_let_fibonacci.swift
MaxDesiatov
approved these changes
Jan 6, 2022
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 : )