[pull] swiftwasm-release/5.3 from release/5.3 #1203
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}
Fixes <rdar://problem/63195315> (cherry picked from commit 7108978)
A more modest fix for rdar://63289339 for the 5.3 release.
… uses when validating if a LiveRange is alive in a scope. The reason why this is important is that if our destroy_value is elided due to the destroy_value being in a dead end block, we can promote a load [copy] to a load_borrow even if the load [copy] has a forwarding consuming use outside of a begin_access region. I changed every place in SemanticARCOpts that did this sort of thing to use this pattern instead of just destroys so that no one cargo cults the original pattern by mistake. <rdar://problem/61774105> (cherry picked from commit ba1ac78) Cherry-pick radar: rdar://63188362
For example for: funcName(base.<HERE>) Wrap 'base' with 'CodeCompletionExpr' so that type checker can check 'base' independently without preventing the overload choice of 'funcName'. This increases the chance of successful type checking. rdar://problem/63965160 (cherry picked from commit 3ec250f)
…alizer. Fixes rdar://problem/63169705 / FB7699647. (cherry picked from commit d43c515)
Test case from Holly Borla, thank you! (cherry picked from commit 3e7b4ae)
…nt(for:). Fixes rdar://problem/63898120.
So that the parser can parse the subject expresion which provides the expected type of the pattern. rdar://problem/56802036 (cherry picked from commit f107a15)
rdar://problem/61016147 (cherry picked from commit 38d8b13)
In 'protocol', 'Self' is implicitly declared as a generic parameter. In 'struct' and 'enum', 'Self' is just an alias for the nominal type. In 'class', 'Self' is a dynamic type and usable only in result types and inside function bodies. rdar://problem/61307680 (cherry picked from commit 3b97b86)
We omit leaf frame pointers on arm64. rdar://64192051
…est_5.3 [5.3] Fix c_globals test
…lder-dynamic-replacement-5.3 [5.3] [Function builders] Infer function builder through @_dynamicReplacement(for:
…paque-result-crash-fix-5.3 [5.3] [Property wrappers] Reject opaque result types when there is no initializer
…s-5.3 [5.3] Add all the ptrauth IR attributes that Clang does
…eric classes `dynamically_replaceable`
```
* Description:
class Generic<T> {
@objc dynamic func method() {}
}
extension Generic {
@_dynamicReplacement(for:method())
func replacement() {}
}
```
The standard mechanism of using Objective-C categories for dynamically
replacing @objc methods in generic classes does not work.
Instead we mark the native entry point as replaceable.
Because this affects all @objc methods in generic classes (whether there
is a replacement or not) by making the native entry point
`[dynamically_replaceable]` (regardless of optimization mode) we guard this by
the -enable-implicit-dynamic flag because we are late in the release cycle.
* Scope: Before this patch @_dynamicReplacement(for:) was not allowed on
objective c methods in generic classes.
* Risk: Medium. Should only affect entry points that did not work before.
* Reviewed by: Slava Pestov
* Testing: Regression test added
rdar://63679357
…ar56802036 [5.3][CodeCompletion] Skip to '=' after completion in 'if'/'guard' pattern
…elf-rdar61307680 [5.3][CodeCompletion] Suggest 'Self' inside struct, enum and classe
…ypathsubscript-rdar61016147 [5.3][CodeCompletion] Add keypath apply subscript after open bracket
…8362 [5.3] [semantic-arc-opts] Use all consuming uses instead of just destroying uses when validating if a LiveRange is alive in a scope.
[Incremental Dependencies] Coarse-grained dependencies by default
…letion Don't insert CodeCompletionExpr at the cursor position in "conforming method list" or "typecontext" mode. This increase the chance of successful type checking. rdar://problem/63781922 (cherry picked from commit 67e88f4)
…ethod_generic_class_5.3 [5.3] Mark non-foreign entry points of `@objc dynamic` methods in generic classes `dynamically_replaceable`
…ar63965160 [5.3][CodeCompletion] Wrap base expression with CodeCompletionExpr
…ftlang#32316) We were accidentally using the system libicu instead of building it, causing version mismatches. This will unblock Linux PR testing for swiftlang/swift-llbuild#674 (cherry picked from commit ccb41f0, swiftlang#31733) Co-authored-by: Ben Langmuir <[email protected]>
Introduce an experimental mode (behind the flag
`experimental-one-way-closure-params`) that places one-way
constraints between closure parameter types and references to those
parameters within the body of the closure. The intent here is to
break up constraint systems further, potentially improving type
checking performance and making way for larger closure bodies to be
supported.
This is a source-breaking change when the body of a single-expression
closure is used to determine the parameter types. One obvious example
is when there is no contextual type, e.g.,
let _ = { $0 + 1 }
this type-checks today because `1` becomes `Int`, which matches the
`+` overload with the type `(Int, Int) -> Int`, determining the
parameter type `Int` for the closure. Such code would not type-check
with one-way constraints.
(cherry picked from commit 64f903f)
Introduce one-way constraints for the parameters of closures to which a function builder is being applied. This was an intended part of the model when one-way constraints were introduced, but somehow got missed. This should further break up large constraints systems for faster solving, and *most likely* won't break much source code in practice. Fixes rdar://problem/64231116. (cherry picked from commit f60d17b)
…hods-disablelabeledtrailingclosure-rdar63781922 [5.3][SourceKit] Disable labeled trailing closure support except code completion
…ne-way-params-5.3 [5.3] [Function builders] Use one-way constraints for closure parameters.
…e the index expression isn't a tuple or paren expression
During witness table instantiation, the witness table is constructed several sources: the pattern, the resilient witnesses, the private data, and default implementations. The private data area is the only one that was being zeroed out; the rest we rely on always filling in the data from the conformance descriptor and provided info. However, witness table instantiation uses the presence of a NULL pointer for a particular witness in the resulting table to indicate that no witness fulfilled that requirement, so that it can fill in the default witnesss. Except that, without zeroing that part of the table beforehand, we aren't guaranteed to have a NULL pointer for witness entries that the client (protocol conformance) did not know about at the time it was compiled. Zero out the entire witness table so default implementations can be filled in appropriately. Fixes rdar://problem/64295849.
[5.3] Remove stray backtick in doc comment.
[5.3] [CS] Fix a crash in AllowArgumentMismatch
…antiation-default-zeroing-5.3 [5.3] [Runtime] Zero out the entire witness table during instantiation.
MaxDesiatov
approved these changes
Jun 16, 2020
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]. Want to support this open source service? Please star it : )