You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 15, 2020. It is now read-only.
It appears that as of Swift 4, passing the dataSource as inout causing a simultaneous memory access crash when calling tableView.deleteRows(at: [indexPath], with: .automatic) from the Table commitEditing callback, even in the example app.
let editingController: TableEditingController<DataSource<CellViewModel>> = TableEditingController(
canEditRow: { (item, tableView, indexPath) -> Bool in
return true
},
commitEditing: { (dataSource: inout DataSource, tableView, editingStyle, indexPath) in
if editingStyle == .delete {
if dataSource.remove(at: indexPath) != nil {
tableView.deleteRows(at: [indexPath], with: .automatic)
}
}
})
Selecting No Enforcement for Exclusive Access to Memory from Swift Compiler - Code Generation in the project's build settings resolves the crash, but seems like more of a work-around rather than an actual fix.
The text was updated successfully, but these errors were encountered:
Any update on this issue? Looks like the build setting work-around is no longer working and resulting in crashes in-app. I just removed the inout flag on the DataSource parameter in DataSourceProvider and the accompanying CommitEditingConfig typealias which appears to be working without issues for the time being.
However, it results in a table view inconsistency exception (bad). Not surprising. The copy leaves the data source in an inconsistent state.
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason:
'Invalid update: invalid number of rows in section 0.
The number of rows contained in an existing section after the update (3)
must be equal to the number of rows contained in that section before the update (3),
plus or minus the number of rows inserted or deleted from that section (0 inserted, 1 deleted)
and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out).'
Per: #92 (comment)
It appears that as of Swift 4, passing the
dataSource
asinout
causing a simultaneous memory access crash when callingtableView.deleteRows(at: [indexPath], with: .automatic)
from the TablecommitEditing
callback, even in the example app.Here's the Swift proposal.
Selecting
No Enforcement
forExclusive Access to Memory
fromSwift Compiler - Code Generation
in the project's build settings resolves the crash, but seems like more of a work-around rather than an actual fix.The text was updated successfully, but these errors were encountered: