Skip to content

[SR-6227] source-compat-suite failure: Moya (toType->hasUnresolvedType() && "Should have handled this above"), function coerceToType, #48779

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

Closed
aschwaighofer opened this issue Oct 26, 2017 · 11 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself crash Bug: A crash, i.e., an abnormal termination of software

Comments

@aschwaighofer
Copy link
Contributor

Previous ID SR-6227
Radar rdar://problem/35198459
Original Reporter @aschwaighofer
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, CompilerCrash
Assignee @xedin
Priority Medium

md5: d1b0676eaa0fa71246e59e9868da0a22

is blocked by:

  • SR-6335 Moya source breakage: Assertion failed: (toType->hasUnresolvedType() && "Should have handled this above"), function coerceToType, file swift/lib/Sema/CSApply.cpp, line 5989.

Issue Description:

$ swift-LOCAL-2017-10-25-a.xctoolchain.base2/usr/bin/swiftc -v
Apple Swift version 4.1-dev (LLVM a2bdb45198, Clang bb20a94e86, Swift ec19cad)
Target: x86_64-apple-darwin17.2.0

(swift/utils/build-toolchain swift build)

source-compat-suite: 112421c (HEAD -> master, origin/master, origin/HEAD) Merge pull request #96 from graydon/misc-run_cperf-fixes

./runner.py --swift-branch master --projects projects.json --swift-version 3 --include-actions 'action.startswith("Build")' --swiftc .../usr
/bin/swiftc

I think we don't see the failure on the bot because the bot builds without assertions.
Assertion failed: (toType->hasUnresolvedType() && "Should have handled this above"), function coerceToType, file /Volumes/Transcend/CompilerGithub9/swift/lib/Sema/CSApply.cpp, line 5999.
0 swift 0x000000010c5d69d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 swift 0x000000010c5d5926 llvm::sys::RunSignalHandlers() + 86
2 swift 0x000000010c5d6f9e SignalHandler(int) + 366
3 libsystem_platform.dylib 0x00007fff79dd5f5a _sigtramp + 26
4 libsystem_platform.dylib 0x00007fc0585517a8 _sigtramp + 3732387944
5 libsystem_c.dylib 0x00007fff79c0130a abort + 127
6 libsystem_c.dylib 0x00007fff79bc9360 basename_r + 0
7 swift 0x0000000109e19434 (anonymous namespace)::ExprRewriter::coerceToType(swift::Expr*, swift::Type, swift::constraints::ConstraintLocatorBuilder, llvm::Optional<swift::Pattern*>) + 900
8 swift 0x0000000109e334cd (anonymous namespace)::ExprRewriter::coerceCallArguments(swift::Expr*, swift::AnyFunctionType*, swift::ApplyExpr*, llvm::ArrayRef<swift::Identifier>, bool, swift::constraints::ConstraintLocatorBuilder) + 3485
9 swift 0x0000000109e1f2ab (anonymous namespace)::ExprRewriter::finishApply(swift::ApplyExpr*, swift::Type, swift::constraints::ConstraintLocatorBuilder) + 3563
10 swift 0x0000000109e34b93 (anonymous namespace)::ExprRewriter::visitApplyExpr(swift::ApplyExpr*) + 99
11 swift 0x0000000109e1bc09 (anonymous namespace)::ExprRewriter::walkToExprPost(swift::Expr*) + 25
12 swift 0x0000000109e20c26 (anonymous namespace)::ExprWalker::walkToExprPost(swift::Expr*) + 22
13 swift 0x000000010a1e6316 swift::Expr::walk(swift::ASTWalker&) + 118
14 swift 0x0000000109e18dc3 swift::constraints::ConstraintSystem::applySolution(swift::constraints::Solution&, swift::Expr*, swift::Type, bool, bool, bool) + 595
15 swift 0x0000000109f22da6 swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, swift::TypeLoc, swift::ContextualTypePurpose, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem*) + 886
16 swift 0x0000000109fa86b2 swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*, void, void, void, void>::visit(swift::Stmt*) + 5106
17 swift 0x0000000109fa7388 swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*, void, void, void, void>::visit(swift::Stmt*) + 200
18 swift 0x0000000109fa67ab (anonymous namespace)::StmtChecker::typeCheckBody(swift::BraceStmt*&) + 27
19 swift 0x0000000109fa5ac9 swift::TypeChecker::typeCheckFunctionBodyUntil(swift::FuncDecl*, swift::SourceLoc) + 233
20 swift 0x0000000109fa646b swift::TypeChecker::typeCheckAbstractFunctionBody(swift::AbstractFunctionDecl*) + 251
21 swift 0x0000000109fc565a typeCheckFunctionsAndExternalDecls(swift::TypeChecker&) + 186
22 swift 0x0000000109fc62de swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int, unsigned int, unsigned int) + 1710
23 swift 0x0000000109c5d4e8 swift::CompilerInstance::parseAndCheckTypes(swift::CompilerInstance::ImplicitImports const&) + 856
24 swift 0x0000000109c5cc18 swift::CompilerInstance::performSema() + 520
25 swift 0x00000001091bb73a performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 1738
26 swift 0x00000001091ba143 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 3315
27 swift 0x000000010917ae30 main + 3360
28 libdyld.dylib 0x00007fff79b55145 start + 1
29 libdyld.dylib 0x000000000000005d start + 2253041433

@aschwaighofer
Copy link
Contributor Author

@swift-ci create

@aschwaighofer
Copy link
Contributor Author

Same assert in:
FAIL_BuildXcodeProjectScheme_Kickstarter*

@aschwaighofer
Copy link
Contributor Author

Same assert in
FAIL_BuildXcodeWorkspaceScheme_ReactiveCocoa
FAIL_BuildXcodeWorkspaceScheme_ReactiveSwift

(Presumably they compile the same thing)

@xedin
Copy link
Contributor

xedin commented Nov 9, 2017

I'm not aware of any changes to type-checker which went into 4.1 branch recently, @rudkx do you know?

@rudkx
Copy link
Contributor

rudkx commented Nov 9, 2017

I suspect (as Arnold mentions above) that we don't normally run with assertions enabled on the bots, which would explain why we aren't seeing it there.

@xedin
Copy link
Contributor

xedin commented Nov 9, 2017

Ah sorry in the rest of the text, I've missed that, will try to take a look ASAP.

@xedin
Copy link
Contributor

xedin commented Nov 10, 2017

I can reproduce this locally now after couple of problems with llbuild/swiftPM:

1.  While type-checking 'logEvents(identifier:events:fileName:functionName:lineNumber:logger:)' at /swift/swift-source-compat-suite/project_cache/Moya/.build/checkouts/ReactiveSwift.git-5417491714505190452/Sources/EventLogger.swift:63:9
2.  While type-checking expression at [/swift/swift-source-compat-suite/project_cache/Moya/.build/checkouts/ReactiveSwift.git-5417491714505190452/Sources/EventLogger.swift:70:10 - line:77:3] RangeText="self.on(
            failed: log(.failed),
            completed: log(.completed),
            interrupted: log(.interrupted),
            terminated: log(.terminated),
            disposed: log(.disposed),
            value: log(.value)
        )"

@xedin
Copy link
Contributor

xedin commented Nov 10, 2017

It looks like all of the errors here are related to same source in ReactiveSwift.

@xedin
Copy link
Contributor

xedin commented Nov 10, 2017

Here is the reduced example to present a problem, only happens in swift-version 3 mode:

class S<Value, Error: Swift.Error> {
  public func on(completed: (() -> Void)? = nil) {}
}

enum A {
  enum E: String {
    case foo
  }
}

extension S {
  func foo() {
    func bar<T>(_ event: A.E) -> ((T) -> Void)? {
      fatalError()
    }

    self.on(completed: bar(.foo) as ((()) -> Void)?)
  }
}

@xedin
Copy link
Contributor

xedin commented Nov 11, 2017

Here is even further simplified example:

func foo(_: (() -> Void)? = nil) {}
func bar<T>() -> ((T) -> Void)? {
  return nil
}

foo(bar() as ((()) -> Void)?)

This is once again fallout from SE-0110 because argument type is going to have paren inside and parameter wouldn't, so when we go trying to coerce types restricted by deep equality they are supposed to be already equal to one another but not in this case they won't be because of paren, which then goes to theoretically unreachable code for DeepEquality restriction and fails on assert.

@xedin
Copy link
Contributor

xedin commented Nov 17, 2017

Fixed by PR #12934 I've just merged into master.

@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 itself crash Bug: A crash, i.e., an abnormal termination of software
Projects
None yet
Development

No branches or pull requests

4 participants