[SR-2463] Assertion failed: (resultTy->hasUnresolvedType() && "Should have a selected member if we got a type") #45068
Comments
|
Possibly related to SE-0110. Does the closure really take one argument that's a tuple, or is it supposed to take two arguments? |
|
(We shouldn't crash regardless.) |
|
Comment by Stefan Urbanek (JIRA) The /Users/stefanu/Developer/sepro/Sources/Parser/Grammar.swift:95:55: error: contextual closure type '(_) -> _' expects 1 argument, but 2 were used in closure body
target_type + option(op(".") *> %"slot") => { (a,b) in ModifierTarget(a, b) }
^Edit 2: Here is the function behind +: func then<T,A,B> (_ p: Parser<T,A>, _ q: Parser<T,B>) -> Parser<T,(A,B)> |
|
Okay, thanks for clarifying that. |
|
Despite the example at line 55, I don't believe a tuple is expected here at all. This assert is basically saying that we didn't expect to determine a type when the member reference is invalid, but we did. That would be a fine assert except we're hitting this code on a path where we are attempting to emit a diagnostic, and I suspect we have a type because it's the one we've substituted in to attempt to solve the system (the type we're using here is the one expected by the call to ModifierTarget, in this case a TargetType). Line 96, just below, has another closure that attempts to construct a ModifierTarget using TargetType.This and the closure parameter. If I remove the assert I get the rather unhelpful: /Users/mark_lacey/src/sepro/Sources/Parser/Grammar.swift:95:87: error: type of expression is ambiguous without more context
target_type + option(op(".") *> %"slot") => { target in ModifierTarget(target.0, target.1) }
~~~~~~~^ |
|
Comment by Stefan Urbanek (JIRA) Line 96 contains recognizer that returns a parser which generates just a single object of type Symbol. Operator In line 95 the Edit: replaced all the operators in the rewrite example with functions. |
|
Yes, you're right. I dug into this further and the thing that gets us to this point is that ModifierTarget's init() isn't public, so it's inaccessible from this file. We should emit a useful diagnostic for that, but hopefully this will allow you to work around the lack of diagnostic (and current assert in debug builds). |
|
Comment by Stefan Urbanek (JIRA) Thank you @rudkx for the investigation. Indeed making the method public (and also adding explicit public init for Modifier) solved the problem and the module compiles. Works for me for now. Interesting that it compiled with older versions of swift. You are right, better diagnostic would be helpful. Thanks a lot. |
|
Looks like Swift 3.1 has the good diagnostic and everything. |
AnthonyLatsis
added
the
crash
Environment
Apple Swift version 3.0-dev (LLVM 17c4c6cf7a, Clang 4ca9e01a7c, Swift 31bbb2c)
Target: x86_64-apple-macosx10.9
Additional Detail from JIRA
md5: abe8fdb7709ac58a7d7b1005ed603ecc
Issue Description:
Compiling this library (requires ParserCombinator 0.1.4) results in compiler crash. It fails on Parser/Grammar.swift:95.
The project used to compile on one of earlier versions of swift this year, but I don't have them installed any more.
Crash output:
The text was updated successfully, but these errors were encountered: