Skip to content

[pull] swiftwasm-release/5.3 from release/5.3 #1004

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 19 commits into from
May 16, 2020
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented May 14, 2020

See Commits and Changes for more details.


Created by pull[bot]. Want to support this open source service? Please star it : )

rjmccall and others added 3 commits May 14, 2020 00:38
…ed" with itself.

SIL type lowering might have already substituted away an opaque type during a SIL substitution.
Fixes rdar://problem/62072397.
In particular, types generic on the CodingKey produce a lot of runtime metadata.
Reducing the number of such types should help with some of the reported memory
bloat from Codable.

Based on a suggestion of @jckarter

Resolves rdar://62620208
rintaro and others added 16 commits May 14, 2020 13:08
rdar://problem/60982638
(cherry picked from commit 32bd377)
in expression context analysis. They are simply not necessary.

rdar://problem/60982638
(cherry picked from commit 3337d7b)
…lying-type-with-underlying-type-5.3

[5.3] ReplaceOpaqueTypesWithUnderlyingTypes: Handle a type being "substituted" with itself.
…ar60982638

[5.3][CodeCompletion] Avoid re-typechecking pre-checked expressions
…or unavailable initializer

Fixes <rdar://problem/63188572>.
[5.3][Type-checker] Improve diagnostic for keypath used without 'keyPath:' label
…tomics-5.3

[5.3] Make the lazy assignment of an associated type/wtable atomic
…sure parameter(s)

Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.

```swift
struct S {
}

S.foo { a, b in } // `S` doesn't have static member `foo`

let _ = { v in } // not enough context to infer type of `v`

_ = .foo { v in } // base type for `.foo` couldn't be determined
```

Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
…ating-ctor-fix-5.3

SILGen: Remove obsolete hack preventing emission of allocating init for unavailable initializer [5.3]
…lude initializer expressions.

Catch any cleanups that get emitted while evaluating the initializer expression for a property.
Fixes rdar://problem/63187509.
Opaque result type syntax is not usable except the declaration of
itself. In other places, users need to let them inferred. If they are
inferred associated type, they need to reffered by the name of the
associated type.

rdar://problem/59817674
(cherry picked from commit 29398b1)
[5.3][ConstraintSystem] Detect and diagnose inability to infer type of clo…
…ar59817674

[5.3][ASTPrinter] Don't print inferred opaque result type witness
…er-scope-5.3

[5.3] SILGen: Extend scope for evaluation in memberwise initializers to include initializer expressions.
* Revert "test: move RangeSet test into validation-test"

This reverts commit e9aaef4.

* Revert "Add RangeSet and discontiguous collection operations (swiftlang#28161)"

This reverts commit c6183ee.
@pull pull bot merged commit 7922165 into swiftwasm-release/5.3 May 16, 2020
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.