Deleting a StaffTypeChange causes a crash in macOS
This happens any time the user attempts to delete a StaffTypeChange, no matter where it occurs.
The bug is not specific to macOS, but other compilers are more forgiving if you try to advance an iterator when it already points to
The problem is with this bit of code in
Staff::localSpatiumChanged(), from commit dee8662:
auto i = _staffTypeList.find(tick.ticks()); ++i;
The problem is that by the time this code is executed, the StaffType will already have been removed from the StaffTypeList, so the
find() call will return
end(). Fortunately, the
upper_bound() function does what we want. Replacing those two lines with
auto i = _staffTypeList.upper_bound(tick.ticks());
makes the code work the way it should.
A special case is if the user tries to delete a StaffTypeChange that has been placed on the first measure. A StaffTypeChange on the first measure is really a reference to the Staff's initial StaffType, so removing it should not cause the initial StaffType to be removed from the StaffTypeList. Currently, attempting this will result in a crash on macOS and a hang on Linux. When I try this in Windows, the clefs become misplaced, and the program crashes when I tried to add it back or open the "Staff/Part Properties..." dialog. The fix is to make sure not to call
tick().isZero(). If we do this, then we can safely remove StaffTypeChange elements that have been placed on the first measure.
If a StaffTypeChange on the first measure is understood to be a reference to the Staff's initial StaffType, then it should come as no surprise that if you were to add a StaffTypeChange to the first measure, and then modify some of its properties, a subsequent deletion of the StaffTypeChange will not cause those properties to revert to what they were before the StaffTypeChange was added.