Skip to content

[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 41 commits into from
May 23, 2020
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented May 18, 2020

See Commits and Changes for more details.


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

slavapestov and others added 8 commits May 15, 2020 22:15
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
theblixguy and others added 21 commits May 19, 2020 14:08
…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.
[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
…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
slavapestov and others added 12 commits May 21, 2020 17:36
… 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
…ype-of-opaque-type-5.3

ASTDemangler: Add support for member types of opaque result types [5.3]
@pull pull bot merged commit 6b949a2 into swiftwasm-release/5.3 May 23, 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.