forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
[pull] swiftwasm from main #3972
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
…ammingImplementation.md
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
I was thinking of removing this since I didn't include it in the table of contents. Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
Co-authored-by: Richard Wei <rxrwei@gmail.com>
…ules This is a source-level error, not an invariant violation. Instead, plumb a new hadError() flag, which in the future will assert if no diagnostic was produced.
…formanceRequirement()
When a rule is replaced by a rewrite path, if the rule is in context then every step of the replacement step is necessarily always in context. The only way new rules in empty context can be introduced by a replacement is if the original rewrite step being replaced had no context. Therefore, loops that do not contain rules in empty context will never provide any additional information during homotopy reduction.
…alized When a rewrite rule is replaced with a path containing ::Adjust, ::Decompose, ::ConcreteConformance or ::SuperclassConformance rewrite steps, the steps will get a non-zero EndOffset if the original rule appears in a step with a non-zero EndOffset. For this reason, these steps must work with a non-zero EndOffset, which primarily means computing correct offsets into the term being manipulated.
… conformances now
…ment-machine-protocol-signatures=verify for now
This doesn't actually matter, except to make the requirement machine minimization cross-checking work on highly-invalid test cases.
This doesn't actually matter, except to make requirement machine minimization cross-checking work on highly invalid code with duplicate associated type declarations in the same protocol.
Adding the ability to add an optional message to the unavailable from async attribute. This can be used to indicate other possible API to use, or help explain why it's unavailable.
Adding nice error messages for when things go wrong.
If you have a pair of requirements T : P and T == G<U>, the conformance G : P might be conditional, imposing arbitrary requirements on U. In particular, these conditional requirements can mention arbitrary protocols on the right hand side. Introducing these conformance requirements during property map construction is totally fine when building a top-level generic signature, but when building a protocol requirement signature, things get a bit tricky. Because of the design of the requirement machine, it is better if the set of protocols appearing on the right hand side of conformance requirements in another protocol (the "protocol dependencies") are known *before* we start building the requirement signature, because we build the requirement signatures of all protocols in a connected component of this graph simultaneously. Introducing conformance requirements to hithero-unseen protocols after the graph of connected components had already been built would require mutating it in a tricky way, and possibly merging connected components. I didn't find any examples of protocols that rely on conditional requirement inference in our test suite, or in the source compatibility suite. So for now, I'm going to try to disable this feature inside protocols. Another argument in favor of not doing conditional requirement inference in protocols is that we don't do the ordinary kind of requirement inference there either. That is, the following is an error: protocol P { associatedtype T == Set<U> associatedtype U } Unlike with an ordinary top-level generic signature, we don't infer 'U : Hashable' here. So arguably the current behavior of protocols inferring these requirements in the case of a conditional conformance only is also rather odd.
…s are present in lookup"
…mization-fixes RequirementMachine: Protocol requirement signature minimization fixes
…navailablefromasync-messages Adding optional message to `_unavailableFromAsync`
…ft-type Revert "lookup: prefer Swift types over Clang ones when multiple types are present in lookup"
…t-inference-in-protocols [Experiment] GSB: Disable conditional requirement inference in protocols
Add an explanatory comment.
MaxDesiatov
approved these changes
Dec 9, 2021
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 : )