Skip to content

[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
merged 134 commits into from
Dec 9, 2021
Merged

[pull] swiftwasm from main #3972

merged 134 commits into from
Dec 9, 2021

Conversation

pull[bot]
Copy link

@pull pull bot commented Dec 9, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

philipturner and others added 30 commits December 6, 2021 16:58
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>
philipturner and others added 27 commits December 7, 2021 18:58
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.
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.
…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.
…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
@pull pull bot merged commit 3b1ad80 into swiftwasm Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants