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-4315] Xcode 8.3 compiler crashes on generic subclass init #46898

Closed
swift-ci opened this issue Mar 22, 2017 · 8 comments
Closed

[SR-4315] Xcode 8.3 compiler crashes on generic subclass init #46898

swift-ci opened this issue Mar 22, 2017 · 8 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-4315
Radar rdar://problem/31203720
Original Reporter hpwooten (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

Xcode 8.3 8E161. macOS 10.12.3 (16D32)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 3.1Regression
Assignee @slavapestov
Priority Medium

md5: f520d9ba7bad66fb4552766ea0333f42

is duplicated by:

  • SR-4624 Can't cast between generic superclass and generic subclass where subclass has constraints

Issue Description:

I have a class that inherits from a generic class in a separate module. I'm seeing 2 new issues in Xcode 8.3 that were not present in Xcode 8.2.1

1. When trying to access a dictionary property of the superclass, the compiler can't infer which subscript to use
2. When I comment out the dictionary access, SILGen crashes.

I have attached a minimized repro project.

@swift-ci
Copy link
Collaborator Author

Comment by Adam Newton (JIRA)

The subscript part of this is potentially related to https://bugs.swift.org/browse/SR-3547

@swift-ci
Copy link
Collaborator Author

Comment by Adam Newton (JIRA)

One of my teammates found the following workaround:

final class InteractiveAPICall<Document: ParsableResult, Parser: SAXParsable>:
XMLSAXElementParser<XMLElementsNone, ResultElement<Parser>> {
    
}

extension InteractiveAPICall where Document.Parser == Parser {
    
    func result() throws -> Document {
        
        /// With the following code block commented out, the compiler crashes in SILGen
        /// If you uncomment the block, it errors with "ambiguous reference to member 'subscript'"
        
        let childKey = ResultElement<Parser>()
        let parser: [SAXParsable]? = self.children[childKey]
        if let resultParser = parser?.first as? Parser {
            return try Document(parser: resultParser)
        }
        
        throw InteractiveAPIError.malformedResult
    }
    
}

Looks like moving Document.Parser == Parser to an extension lets this compile.

@belkadan
Copy link
Contributor

@swift-ci create

@slavapestov
Copy link
Member

I cannot reproduce this with the latest 3.1 development snapshot.

@slavapestov
Copy link
Member

Sorry, operator error. It reproduces on the latest 3.1 snapshot:

Assertion failed: (!base || !base->hasTypeParameter()), function OverloadChoice, file /Users/buildnode/jenkins/workspace/oss-swift-3.1-package-osx/swift/lib/Sema/OverloadChoice.h, line 108.
0  swift                    0x00000001123e15a8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  swift                    0x00000001123e07c6 llvm::sys::RunSignalHandlers() + 86
2  swift                    0x00000001123e1bf9 SignalHandler(int) + 361
3  libsystem_platform.dylib 0x00007fffdee6abba _sigtramp + 26
4  libsystem_platform.dylib 0x01007fff5069cb68 _sigtramp + 1904418760
5  libsystem_c.dylib        0x00007fffdecf2440 abort + 129
6  libsystem_c.dylib        0x00007fffdecb98b3 basename_r + 0
7  swift                    0x0000000110244118 swift::constraints::ConstraintSystem::performMemberLookup(swift::constraints::ConstraintKind, swift::DeclName, swift::Type, swift::FunctionRefKind, swift::constraints::ConstraintLocator*, bool) + 5688
8  swift                    0x0000000110244a4f swift::constraints::ConstraintSystem::simplifyMemberConstraint(swift::constraints::ConstraintKind, swift::Type, swift::DeclName, swift::Type, swift::DeclContext*, swift::FunctionRefKind, swift::OptionSet<swift::constraints::ConstraintSystem::TypeMatchFlags, unsigned int>, swift::constraints::ConstraintLocatorBuilder) + 207
9  swift                    0x00000001102316e3 swift::constraints::ConstraintSystem::addValueMemberConstraint(swift::Type, swift::DeclName, swift::Type, swift::DeclContext*, swift::FunctionRefKind, swift::constraints::ConstraintLocatorBuilder) + 179
10 swift                    0x00000001102259ee swift::ASTVisitor<(anonymous namespace)::ConstraintGenerator, swift::Type, void, void, void, void, void>::visit(swift::Expr*) + 1134
11 swift                    0x000000011022ceda (anonymous namespace)::ConstraintWalker::walkToExprPost(swift::Expr*) + 58
12 swift                    0x00000001103df20b (anonymous namespace)::Traversal::visitApplyExpr(swift::ApplyExpr*) + 123
13 swift                    0x00000001103dcfb1 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) + 4225
14 swift                    0x00000001103db214 swift::Expr::walk(swift::ASTWalker&) + 84
15 swift                    0x00000001102245b8 swift::constraints::ConstraintSystem::generateConstraints(swift::Expr*) + 264
16 swift                    0x000000011024fb3f swift::constraints::ConstraintSystem::solve(swift::Expr*&, swift::Type, swift::ExprTypeCheckListener*, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 79
17 swift                    0x00000001102c1e04 swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem&, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>) + 340
18 swift                    0x00000001102c4dbf swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, swift::TypeLoc, swift::ContextualTypePurpose, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem*) + 655
19 swift                    0x00000001103376c6 swift::TypeChecker::constructCallToSuperInit(swift::ConstructorDecl*, swift::ClassDecl*) + 422
20 swift                    0x0000000110336e36 swift::TypeChecker::typeCheckConstructorBodyUntil(swift::ConstructorDecl*, swift::SourceLoc) + 1350
21 swift                    0x0000000110336614 swift::TypeChecker::typeCheckAbstractFunctionBodyUntil(swift::AbstractFunctionDecl*, swift::SourceLoc) + 148
22 swift                    0x00000001103371fa swift::TypeChecker::typeCheckAbstractFunctionBody(swift::AbstractFunctionDecl*) + 250
23 swift                    0x0000000110349d49 typeCheckFunctionsAndExternalDecls(swift::TypeChecker&) + 201
24 swift                    0x000000011034aaf4 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int) + 1572
25 swift                    0x000000010ff7a979 swift::CompilerInstance::performSema() + 3753
26 swift                    0x000000010f5a6f2f swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 4255
27 swift                    0x000000010f5649d0 main + 3312
28 libdyld.dylib            0x00007fffdec5e255 start + 1
Stack dump:

@slavapestov
Copy link
Member

It also builds successfully on master.

@slavapestov
Copy link
Member

I think it's a case of https://bugs.swift.org/browse/SR-3045 (the general problem remains but this manifestation appears to be fixed).

@slavapestov
Copy link
Member

So I added a regression test for this to master that ensures the code will continue to work there.

The workaround in 3.1 is to not define generic parameters which are same-type constrained to an associated type. That is,

final class InteractiveAPICall<Document: ParsableResult, Parser>:
XMLSAXElementParser<Document.Parser> where Document.Parser == Parser {

can be written as

final class InteractiveAPICall<Document: ParsableResult>:
XMLSAXElementParser<Document.Parser> {

And instead of using the generic parameter 'Parser' in the body, you just write 'Document.Parser' instead.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 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
Projects
None yet
Development

No branches or pull requests

3 participants