forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
[pull] swiftwasm-release/5.3 from release/5.3 #1038
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
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
When adding a superclass constraint, we need to find any nested types belonging to protocols that the superclass conforms to, and introduce implicit same-type constraints between each nested type and the corresponding type witness in the superclass's conformance to that protocol. Fixes <rdar://problem/39481178>, <https://bugs.swift.org/browse/SR-11232>.
We currently leave a key path constraint unsolved if one of its components hasn't yet had its overload resolved. However, for e.g a missing member component, the overload type variable will be bound to a hole and an overload will never be resolved. Tweak the logic to consider the key path constraint trivially solved if one of its components has been marked as a hole, which will allow the key path type itself to be marked as a hole. Resolves SR-12437 & SR-12823. Resolves rdar://62201037.
…s when performing a dynamic replacement Explanation: When a opaque result type (``some P``) appeared as a parameter of a dynamic replacement function we used to try to emit this opaque result type as a replacement. This made no sense since you can only replace result types that are opaque result types not parameters that happen to have the type of an opaque result type. And doing so would lead to a compiler crash. Scope: Any use of a dynamic replacement with an opaque result type parameter would crash the compiler. Origination: This bug was introduced together with the dynamic replacement feature. Risk: Medium. Affects only dynamic replacements with opaque result types. Reviewed by: Joe Groff Testing: Unit test added. rdar://61936622
…sted-type-5.3 GSB: Concretize nested types when adding a superclass constraint [5.3]
This restores getSourceRange() on DefaultArgumentExpr after it was removed in swiftlang#31184. It was originally removed to solve the issues it was causing when computing the source range of its parent TupleExpr. To account for trailing closures we walk back through the tuple's arguments until one with a valid location is found, which we use as the end location. If the last argument was a DefaultArgumentExpr though that meant the end loc would end up being the tuple's start location, so none of the tuple's other arguments were contained in its range, triggering an ASTVerifier assertion. Source tooling and diagnostics don't care about default arg expression locations as nothing can reference them, but their locations are output in the debug info. Added a regression test to catch that in future, and updated TupleExpr::getSourceRange() to ignore them when computing the end loc. Resolves rdar://problem/63195504.
…lly-5.3 [5.3] [CS] Diagnostic improvements for key paths
…ype_dyn_repl_fix_5.3 [5.3] IRGen: Only replace opaque result types of function result types when performing a dynamic replacement
…ixes (1) Pass property getter as requirement when the witness is an payload-less enum case (2) Remove dead code from visitEnumDecl
We have a hack to handle "public" declarations in extensions to internal protcols that are intended as default implementations for a public protocol that the internal protocol refines. This hack failed to trigger for synthesized declarations with shared linkage, such as automatically generated `read` coroutines, causing a visibility assertion failure where we would try to refer to the non-serializable synthesized declaration from the witness thunk we would normally consider serialized. Fixes rdar://problem/55846638.
rdar://problem/63352700
[5.3] [TBDGen] Fix symbol mismatch for enum case constructors
…-sourceloc-5.3 [5.3][AST] Restore getSourceRange() on DefaultArgumentExpr
[5.3] No dummy constraint in the public swiftinterface for SPI extensions
in global completion result. Overly modules have the same name as the shadowed modules. We should not list both names because they are identical. Maintain a set of seen module names to avoid suggesting duplicated names. rdar://problem/63370253 (cherry picked from commit af27e8f)
… an empty field Introduce getByteOffsetDuringLayout() so that we can treat empty fields just like other fixed sized field while performing layout. Explanation: We used to incorrectly compute the offset of a non-fixed field after an empty field inside of a closure capture context. This lead to crashes at runtime because we read memory that the wrong offset. Scope: Causes Swift programs that caputre empty fields and non-fixed fields to crash or misbehave. Risk: Medium, we now correctly compute the offset in such cases. Testing: Regression test added. Reviewer: Slava Pestov rdar://62349871
…plicatedmodule-rdar63370253 [5.3][CodeCompletion] Avoid suggesting duplicated module names
…ayout_empty_followed_by_nonfixed_5.3 [5.3] IRGen: Correctly compute the offset for a non-fixed field after…
LLVM's isel does not like integer types beyond a certain size (llvm::IntegerType::MAX_INT_BITS). Explanation: The compiler would crash in the LLVM backend on imported C types beyond a certain size. Scope: Causes Swift programs that use types imported from C > 512K to crash the compiler. Risk: Low. Only affects code generation of enum witnesses for very large types (512K). Testing: Unit test added. rdar://63189452
…when the declaration is synthesized
…earest non-implicit decl context
…in certain cases. Don't column align PBD entries if any entry spans from the same line as the var/let to another line. E.g. ``` // Previous behavior: let foo = someItem .getValue(), // Column-alignment looks ok here, but... bar = otherItem .getValue() getAThing() .andDoStuffWithIt() let foo = someItem .getValue() // looks over-indented here, which is more common. getOtherThing() .andDoStuffWithIt() // New behavior getAThing() .andDoStuffWithIt() let foo = someItem .getValue() // No column alignment in this case... doOtherThing() let foo = someItem .getValue(), // Or in this case (unfortunate, but less common)... bar = otherItem .getValue() let foo = someItem.getValue(), bar = otherItem.getValue() // but still column-aligned in this case. ``` Resolves rdar://problem/63309288
[5.3] [Typechecker] Emit a specialised diagnostic for redeclaration errors when the declaration is synthesised
… an Objective-C generic class The assertion here is too strict. The TypeAliasDecl will inherit a generic signature from the outer context even if it does not have generic parameters of its own. Instead, let's just assert that the TypeAliasDecl does not have its own generic parameters. Fixes <rdar://problem/63188938>.
…ess_huge_types_5.3 [5.3] IRGen: Fix enumPayload value witness emission for huge types
to return a string representing default initialization when a property is default initialized via property wrapper.
…lized via property wrapper, mark the init call as implicit.
…efault-init [5.3][Property Wrappers] Fix handling of properties that are default initialized via property wrapper
…eric-typealias-assertion-5.3 PrintAsObjC: Fix crash when printing typedef that was imported inside an Objective-C generic class [5.3]
…-indentation-5.3 [5.3][SourceKit/CodeFormat] Fix var/let declaration continuation lines appearing over-indented.
[5.3][NFC][SwiftSyntax] Fix 'Traling' typo
Fixes <rdar://problem/63188053>.
…ype-of-opaque-type-5.3 ASTDemangler: Add support for member types of opaque result types [5.3]
MaxDesiatov
approved these changes
May 23, 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 : )