Skip to content
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

[SR-10187] Encodable Extension never finishes compiling #52589

Closed
swift-ci opened this issue Mar 26, 2019 · 7 comments
Closed

[SR-10187] Encodable Extension never finishes compiling #52589

swift-ci opened this issue Mar 26, 2019 · 7 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-10187
Radar rdar://problem/49339874
Original Reporter iamkevb (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Xcode 10.2, Swift 4.2

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, CompilerCrash
Assignee @xedin
Priority Medium

md5: 05ca6c84f18b7dd9ab600f4db3d9b2c8

Issue Description:

Attached code blocks the compiler from ever finishing.

Test case:

class EncodableThing<T: Equatable> {
  private let title: String
}

extension EncodableThing: Encodable where T: Encodable {
  enum CodingKeys: CodingKey {
    case title
  }
}
@belkadan
Copy link
Contributor

We get a "nice" "crash" on master:

Bad base type
UNREACHABLE executed at /Volumes/Data/swift-public/swift/lib/AST/Type.cpp:3191!
Stack dump:
0.  Program arguments: /Volumes/Data/swift-public/build/ninja/swift-macosx-x86_64/bin/swift -frontend -c -primary-file - -target x86_64-apple-darwin18.5.0 -enable-objc-interop -sdk /Volumes/Data/Applications/Xcode10.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -color-diagnostics -module-name main -o /var/folders/_d/dmrgv26d3bs6lkrks9z825_w0000gn/T/--3a1f8c.o 
1.  While type-checking 'encode(to:)' (in module 'main')
2.  While type-checking statement at [<invalid loc> - <invalid loc>]
3.  While type-checking expression at [<invalid loc> - <invalid loc>]
0  swift                    0x0000000112e27d45 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  swift                    0x0000000112e27005 llvm::sys::RunSignalHandlers() + 85
2  swift                    0x0000000112e28328 SignalHandler(int) + 264
3  libsystem_platform.dylib 0x00007fff64bf3b5d _sigtramp + 29
4  libsystem_platform.dylib 0x000000011a661f87 _sigtramp + 3047613511
5  libsystem_c.dylib        0x00007fff64ab36a6 abort + 127
6  swift                    0x0000000112da3f92 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 530
7  swift                    0x00000001101dbf58 swift::TypeBase::getContextSubstitutions(swift::DeclContext const*, swift::GenericEnvironment*) + 1464
8  swift                    0x00000001101d63ff swift::TypeBase::getContextSubstitutionMap(swift::ModuleDecl*, swift::DeclContext const*, swift::GenericEnvironment*) + 63
9  swift                    0x000000010fd622e5 checkNestedTypeConstraints(swift::constraints::ConstraintSystem&, swift::Type, swift::constraints::ConstraintLocatorBuilder) + 325
10 swift                    0x000000010fd61c3a swift::constraints::ConstraintSystem::openUnboundGenericType(swift::Type, swift::constraints::ConstraintLocatorBuilder) + 58
11 swift                    0x000000010fce48c1 swift::ASTVisitor<(anonymous namespace)::ConstraintGenerator, swift::Type, void, void, void, void, void>::visit(swift::Expr*) + 4033
12 swift                    0x000000010fce3625 (anonymous namespace)::ConstraintWalker::walkToExprPost(swift::Expr*) + 389
13 swift                    0x00000001100e5f7e swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) + 302
14 swift                    0x00000001100e6ea2 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) + 4178
15 swift                    0x00000001100e893f (anonymous namespace)::Traversal::visitApplyExpr(swift::ApplyExpr*) + 207
16 swift                    0x00000001100e5f52 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) + 258
17 swift                    0x00000001100e5824 swift::Expr::walk(swift::ASTWalker&) + 84
18 swift                    0x000000010fcdf7d2 swift::constraints::ConstraintSystem::generateConstraints(swift::Expr*) + 418

@theblixguy
Copy link
Collaborator

Crashing for me on near-master:

bad base type
UNREACHABLE executed at /Users/suyashsrijan/Documents/swift-src/swift/lib/AST/Type.cpp:3191!

I think the issue here is we're trying to synthesise Encodable conformance for a class which does not have an initialiser? We do end up emitting a diagnostic but then start solving the constraints...

I'll assign this to myself.

@theblixguy
Copy link
Collaborator

Also noticed that changing "CodingKeys" to something else does not lead to the crash... interesting!

This does not crash:

class Foo<T: Equatable> {  
  private let bar: String
}
extension Foo: Encodable where T: Encodable {
  enum CodingKeys1: CodingKey {
    case bar
  }
}

Maybe there is some sort of conflict with the synthesised `CodingKeys`

@theblixguy
Copy link
Collaborator

After a bit of digging, the problem is basically that this (and this seems to be limited to a constrained extension case like above, I couldn't reproduce it otherwise) - normally, the compiler will synthesise CodingKeys on the parent type in such a case (if you name the CodingKeys in the above extension something else, like "CodingKeys1"). However, in this case, the compiler isn't doing that because the one on the extension is called "CodingKeys".

The fix for it is we reject it but synthesise a CodingKeys enum on the parent type. This mimics the behaviour of the compiler when the enum isn't called "CodingKeys".

@belkadan
Copy link
Contributor

That's not right. If the user manually writes a CodingKeys, Codable synthesis is supposed to use it.

@theblixguy
Copy link
Collaborator

Seems like this was fixed on master by @xedin: #23652:

@xedin
Copy link
Member

xedin commented Mar 29, 2019

Thank you @theblixguy! This has indeed been fixed by my PR (I've also cherry-picked in to 5.1 branch).

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software
Projects
None yet
Development

No branches or pull requests

5 participants