[SR-11407] swiftc crash due to generic constraints, I guess #53808
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
type checker
Area → compiler: Semantic analysis
Comments
|
Also tested with nightly build swift-DEVELOPMENT-SNAPSHOT-2019-08-30-a.xctoolchain and it still crashes. |
|
With asserts on near master: Assertion failed: ((HadError || !M.is<SourceFile*>() || M.get<SourceFile*>()->ASTStage < SourceFile::TypeChecked) && "UnresolvedDeclRef" "in wrong phase"), function walkToExprPre, file /Users/suyashsrijan/Documents/swift-src/swift/include/swift/AST/ExprNodes.def, line 90. |
|
The code looks fine to me, so the unreported error in the @swift-ci create |
|
It also crashes if you replace |
|
Comment by Nate Chandler (JIRA) A couple of data points: Replacing the final class Box<Wrapped> {
init(_ wrapped: Wrapped) { }
}
protocol List {
associatedtype Element
var node: ListNode<Element, Self>? { get }
}
struct ListNode<Element, Rest: List> where Rest.Element == Element { }
struct Strict<Element>: List {
var node: ListNode<Element, Strict<Element>>? {
return nil
}
var box: Box<ListNode<Element, Self>>?
}Dropping the where clause from the @usableFromInline final class Box<Wrapped> {
init(_ wrapped: Wrapped) { }
}
public protocol List {
associatedtype Element
var node: ListNode<Element, Self>? { get }
}
public struct ListNode<Element, Rest: List> { }
public struct Strict<Element>: List {
public var node: ListNode<Element, Strict<Element>>? {
fatalError()
}
var box: Box<ListNode<Element, Self>>?
} |
|
Comment by Nate Chandler (JIRA) A workaround: Explicitly define the @usableFromInline final class Box<Wrapped> {
init(_ wrapped: Wrapped) { }
}
public protocol List {
associatedtype Element
var node: ListNode<Element, Self>? { get }
}
public struct ListNode<Element, Rest: List> where Rest.Element == Element { }
public struct Strict<_Element>: List {
public typealias Element = _Element
public var node: ListNode<Element, Strict<Element>>? {
fatalError()
}
var box: Box<ListNode<Element, Self>>?
} |
|
It turns out |
|
On master we correctly diagnose the original issue. /Users/rwidmann/test.swift:15:31: error: reference to invalid associated type 'Element' of type 'Strict<_Element>'
public var node: ListNode<Element, Strict<Element>>? {
^
/Users/rwidmann/test.swift:13:15: error: type 'Strict<_Element>' does not conform to protocol 'List'
public struct Strict<_Element>: List {
^
/Users/rwidmann/test.swift:7:20: note: protocol requires nested type 'Element'; do you want to add it?
associatedtype ElementI believe this was repaired by @xymus or @slavapestov's recent work in and around decl checking. |
|
Thanks for testing! Can you add a regression test, @CodaFi? |
|
Can do. EDIT: #27027 |
|
I notice that @CodaFi's quoted diagnostics mention |
|
Aha, it's Nate's reproducer that compiles (look at their declaration of Strict, it includes _Element) but your code that still doesn't. I spoke too soon. I'll look into this. |
|
Comment by Nate Chandler (JIRA) @CodaFi To clarify, that wasn't a reproducer, that was a workaround. The workaround was to change the name of the generic parameter to something else and explicitly define the associatedtype, that is, to change from public struct Strict<Element>: List {to public struct Strict<_Element>: List {
public typealias Element = _Element |
|
I know, I could have sworn commenting out your typealias (which is what I've committed in that linked PR) crashed on my box, but now I'm not sure what to think anymore. |
AnthonyLatsis
added
the
crash
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Xcode Version 11.0 beta 6 (11M392r) — this is really beta 7
macOS 10.15 Beta (19A546d) — also beta 7
Additional Detail from JIRA
md5: 1b4882d67244b42cb5d290f64788bdca
Issue Description:
The following makes swiftc crash (Xcode 11 beta 7):
Here's the log:
The text was updated successfully, but these errors were encountered: