Skip to content

[pull] swiftwasm-release/5.4 from release/5.4 #2492

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 8 commits into from
Jan 14, 2021
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented Jan 13, 2021

See Commits and Changes for more details.


Created by pull[bot]

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

xedin and others added 7 commits January 12, 2021 14:21
… and its unwrapped type

Unresolved member lookup is allowed to perform implicit optional
unwrap of a base type to find members. Previously if there were
any members directly on `Optional`, lookup would stop there. But
since SR-13815 it became possible for solver to attempt members
found on unwrapped type even if there are viable ones on
`Optional` as well.

New score kind has been introduced to guard against possible ambiguities
with new scheme - `SK_UnresolvedMemberViaOptional`. It's used very
time member found via base type unwrap is attempted. Unfortunately,
doing so can lead to behavior changes in existing code because it's
possible that base was wrapped into optional implicitly based on
context e.g. unresolved member passed in as an argument to a parameter
of optional type.

To fix situations like that, `SK_UnresolvedMemberViaOptional` should
only be increased if there is a mix of members to attempt - both directly
on `Optional` and on unwrapped type, in all other cases score should stay
the same because there could be no ambiguity.

Resolves: rdar://73027153
(cherry picked from commit 51dc7fdefab230d76518b97f9074a3f98e1fd0c3)
…shMap.

When reallocating storage, the storing the pointer to the new storage had insufficiently strong ordering. This could cause writers to check the reader count before storing the new storage pointer. If a reader then came in between that load and store, it would end up using the old storage pointer, while the writer could end up freeing it.

Also adjust the Concurrent.cpp tests to test with a variety of reader and writer counts. Counterintuitively, when freeing garbage is gated on there being zero readers, having a single reader will shake out problems that having lots of readers will not. We were testing with lots of readers in order to stress the code as much as possible, but this resulted in it being extremely rare for writers to ever see zero active readers.

rdar://69798617
(cherry picked from commit ef8d20a)
…rameter

Unowned references lower as address-only or loadable, depending on
whether the underlying class type is known to be native Swift or
not.

In the case where we were lowering an interface type, we would
unconditionally erase the type to AnyObject, producing an incorrect
lowering when the generic signature constrained the type parameter
to a native Swift class.

Fixes <rdar://problem/73083179>.
…ence-lowering-5.4

SIL: Fix type lowering of unowned reference to class-bound generic parameter [5.4]
…emory-order2-5.4

[5.4][Runtime] Fix incorrect memory ordering in ConcurrentReadableArray/HashMap
…rrors-in-test-Interop-Cxx-static

[tests] Fix compilation errors in test/Interop/Cxx/static
[5.4][ConstraintSystem] Increase score only if members found on `Optional`…
@pull pull bot merged commit b5edbb9 into swiftwasm-release/5.4 Jan 14, 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.

4 participants