Crash at BarChartDataSet as! IBarChartDataSet

[anekk]

What did you do?

Create BarChartData with BarChartDataSet with BarChartDataEntry.

What did you expect to happen?

See bar chart.

What happened instead?

App crashed.

"Could not cast value of type 'Charts.ChartDataSet' (0x108ede670) to 'Charts.IBarChartDataSet' (0x108e8f868)."

BarChartDataSet is IBarChartDataSet.

Before update to xCode 10.2 it works.

Charts Environment

Charts version/Branch/Commit Number: 3.2.2
Xcode version: 10.2
Swift version: 4
Platform(s) running Charts: iOS 12.2
macOS version running Xcode: 10.14.4

Demo Project

https://github.com/anekk/ChartsIssue.git

[joshxplor]

Having the same issue wherein after setting the BarChartDataSet I invoke highlightColor = .someColor and it just crashes

[liuxuan30]

"Could not cast value of type 'Charts.ChartDataSet' (0x108ede670) to 'Charts.IBarChartDataSet' (0x108e8f868)."

apparently you are not passing in a BarChartDataSet

[kapisz]

"Could not cast value of type 'Charts.ChartDataSet' (0x108ede670) to 'Charts.IBarChartDataSet' (0x108e8f868)."

apparently you are not passing in a BarChartDataSet

After reviewing the demo project to verify that it works and comparing it to my code which doesn't, I think I have an idea as to what's going on. I've instantiated BarChartDataSet as
BarChartDataSet(myArrayOfBarChartDataEntries)
instead of the equivalent in the demo project
BarChartDataSet(values: myArrayOfBarChartDataEntries, label: nil)
the former example seemingly utilizing the initializer in ChartDataSet
@objc public convenience init(values: [ChartDataEntry]?)
and now for whatever reason Xcode 10.2+ seems to be treating the type of value returned as ChartDataSet instead of BarChartDataSet (even though the debugger claims the type to be BarChartDataSet).

Edit: Just to be clear, forcibly using the intended class initializers (in this case, using values and label as parameter) seems to work just fine.

[liuxuan30]

I tried your demo, and it's true indeed.

@jjatie would you take a look? It smells a bug to Apple, not us.

I checked when break at

        let set = BarChartDataSet(values)
        let data = BarChartData(dataSet: set)

set is still BarChartDatSet:

(lldb) fr v set
(Charts.BarChartDataSet) set = 0x000000028109c000 {

but in

let set = barData.dataSets[i] as! IBarChartDataSet

it's

(lldb) p barData.dataSets[i]
(_TtC6Charts12ChartDataSet) $R6 = 0x000000028109c000

note the pointer address is still the same, but failed to cast to BarChartDataSet nor IBarChartDataSet

I cannot step into the function of let set = BarChartDataSet(values), it's always step into

symbol stub for: (extension in Swift):Swift.RangeReplaceableCollection.init<A where A1: Swift.Sequence, A.Element == A1.Element>(A1) -> A

I have no idea but when I tried to retype the code, the auto complete gives me:

which enlightens me that it might because Swift uses it's RangeReplaceableCollection initializer:

Swift.RangeReplaceableCollection.init<A where A1: Swift.Sequence, A.Element == A1.Element>(A1) -> A

rather than our

@objc public convenience init(entries: [ChartDataEntry]?)

But I still don't know why it failed to cast.

and more importantly, I cannot call our convenience init() at all, always throw compile errors

[jjatie]

Looks like there are some issues when keeping objc support around. We need to override the initializer in the subclasses, then it works fine.

[liuxuan30]

@kapisz I reset my branch to 3.2.2 release, and your demo still the same issue. I didn't have an older Xcode on my side, so I don't know if this is introduced with Xcode 10.2

But like what @jjatie said, we can override all super class's designated initializers to make it inherit all superclass's convenient initialziers.

This seems never being raised up by anyone, that, the BarChartDataSet overrides one of the designated initializers:

public override init(entries: [ChartDataEntry]?, label: String?)

so according to Automatic Initializer Inheritance,

Rule 1
If your subclass doesn’t define any designated initializers, it automatically inherits all of its superclass designated initializers.
Rule 2
If your subclass provides an implementation of all of its superclass designated initializers—either by inheriting them as per rule 1, or by providing a custom implementation as part of its definition—then it automatically inherits all of the superclass convenience initializers.
These rules apply even if your subclass adds further convenience initializers.
Note
A subclass can implement a superclass designated initializer as a subclass convenience initializer as part of satisfying rule 2.

the convenient initializer

@objc public convenience init(entries: [ChartDataEntry]?)

is not supposed to be inherited by BarChartDataSet in the first place. So IMO I'm not surprised now it won't work, because BarChartDataSet shouldn't be able to call init(entries: [ChartDataEntry]?) at all.

But I wonder why until now people start complains about this. If this is really a bug of Xcode or the compiler, I think Xcode 10.2.1 just fixed it, and being able to call init(entries: [ChartDataEntry]?) is wrong in previous versions.

looking deeper, that we can simply turn init(label: String?) in ChartDataSet to be a convenient initializer so it can be automatic inherited by all sub ChartDataSet classes.

So now we able able to call init(entries: [ChartDataEntry]?)

But the cast failure issue I think is apple's bug. I will file a radar https://bugs.swift.org/projects/SR/issues/SR-10558

[kapisz]

I had to put my thinking cap on and really dig for this one @liuxuan30 , but I do think Xcode broke it rather than fixed it. First and foremost I was wrong, that is, BarChartDataSet(myArrayOfBarChartDataEntries) was never calling init(values: [ChartDataEntry]?) in ChartDataSet so this isn't an issue where initializers are available when they shouldn't be given the inheritance rules stated in the link you provided. What it's actually calling is init<S>(_ elements: S) where S : Sequence, Self.Element == S.Element of the RangeReplaceableCollection protocol as you discovered earlier, which then calls init() that ChartDataSet conforms to and BarChartDataSet inherits from (and populates the 'values' field using the implemented append method of RangeReplaceableCollection). The interesting thing is that while testing with breakpoints, prior to Xcode 10.2 the public required init() method in BarChartDataSet was called but since Xcode 10.2, it's the init method in ChartDataSet being called when instantiating with a Sequence as the argument. The unfortunate thing is that because it's instantiating with the conforming class rather than with the intended class when passing a Sequence as argument will cause typecasting to fail elsewhere as well (e.g. Instantiating PieChartData with a PieChartDataSet using a Sequence).

[liuxuan30]

@kapisz yes, that's why I said the cast failure should be a bug of Apple.
if it's calling init<S>(_ elements: S), everything should be fine because we adopted the collection protocols.

but it could take a long time to get it really fixed, so I made the change that you could call

public convenience init(entries: [ChartDataEntry]?)

on your side by just adding an argument label "entries".

What I mean "but I think Xcode fix it" is that, I don't remember if old Swift allows to automatically omit the argument label if there is only one parameter without _ being specified. But to my knowledge, let set = BarChartDataSet(values) should never work in any previous versions before we adopt collection protocol, because this initializer is not inherited at all. I just wonder why this is revealed until now. So if you were able to call it and get a valid set, I think it was a mistake back then.

@kapisz can you check on your side, if you have old Xcode and say Charts 3.2.2 or even older, that you can actually get a return of let set = BarChartDataSet(values) ? What's the exact initializer it's actually called?

[kapisz]

Hopefully this is what you were asking for.

Running my project using Charts 3.2.2 on Xcode 10.1, here are the pertinent steps occurring in order.

1. Initialize my BarChartDataSet:

2. `init` in BarChartDataSet is called:

3. 'init' in ChartDataSet is called after calling super in step 2:

4. `append` is called repeatedly adding a new BarChartDataEntry for each `Element`.

And in case if you wanted to know what barChartDataEntries is:

Running the same project in Xcode 10.2 (and 10.2.1), everything happens again the same way EXCEPT step 2 never occurs. Init is called on ChartDataSet (step 3) and the debugger says the set returned is of type BarChartDataSet but the project crashes exactly the way the original poster described it and how you were able to replicate it.

[liuxuan30]

I see. What I said

But to my knowledge, let set = BarChartDataSet(values) should never work in any previous versions before we adopt collection protocol, because this initializer is not inherited at all.

seems wrong. 3.2.2 already adopted collection protocol. before 3.2.2 we don't have this initializer at all.

@objc public convenience init(entries: [ChartDataEntry]?)

this method is never inherited by BarChartDataSet I suppose. So with #3973 you should be able to call it safely. Use it as a workaround for now. I have filed a bug for swift.org.

[jjatie]

@liuxuan30 This is a known issue 49303574

[liuxuan30]

@jjatie good to know. but I kind of oppose we use the 'static func workaround' mentioned in 49303574 now. It's not a small effort to add and later remove it.

and I'm kind of disappointed such major issue is released to outside devs... it should be fixed before :(