When optimizing, GCC now assumes the this pointer can never be null,
which is guaranteed by the language rules. Invalid programs which
assume it is OK to invoke a member function through a null
pointer (possibly relying on checks like this != NULL) may crash or
otherwise fail at run time if null pointer checks are optimized
away. With the -Wnull-dereference option the compiler tries to warn
when it detects such invalid code.
If the program cannot be fixed to remove the undefined behavior then
the option -fno-delete-null-pointer-checks can be used to disable
this optimization. That option also disables other optimizations
involving pointers, not only those involving this.
As a consequence, we cannot call a member function on a prospective null
pointer (which actually is a bad idea for a number of other reasons,
like when anything tries accessing the vtable) and then try sorting out
the condition in the routine itself.
This problem was first observed with Fedora 24. The Ubuntu GCC6
prerelease does not show this problem; presumably the respective
optimization has been disabled in the Ubuntu/Debian packaging because of
affecting other programs.
Commit-message-by: David Kastrup <dak@gnu.org> Signed-off-by: David Kastrup <dak@gnu.org>
David Kastrup [Mon, 4 Jul 2016 08:08:41 +0000 (10:08 +0200)]
Issue 4917: Remove some set_location calls from parser
Older versions of Bison (current is 3.0.4) had problems assigning
location data to rules with empty production, possibly related to the
definition of YYLLOCA_DEFAULT when N is zero.
This lead to several workarounds in the code base. A number of them
dropped through the floor in the course of refactoring without
apparent problem, and the original problem does not appear to be
reproducible with the current versions of Bison.
This removes the remaining instances. Should the original problem
reoccur at some point of time (or with some versions of Bison), it
would be noticeable as bad point-and-click messages and/or error
messages with bad location data.
Issue 4907: Midi_walker::do_start_note: skip ignored notes in stop_note_queue
For each semitone pitch value, stop_note_queue is likely supposed to
contain at most one Midi_note event with its "ignore_" flag set to
false, and the comparisons between notes of equal semitone pitch to be
always done between the input note and this unique queued note that is
not (yet) being ignored.
If notes which are already being ignored are not skipped in the loop,
the task of raising the "ignore_" flags for note events of equal
semitone pitch (overlapping in time) which stop before the maximum
stopping time of these notes may, due to breaking out of the loop,
fail to work if the queue grows to contain three or more notes of equal
semitone pitch, leading to the emission of premature "note off" events
for this pitch, as demonstrated, for example, in
<http://lists.gnu.org/archive/html/bug-lilypond/2016-06/msg00042.html>.
David Kastrup [Sat, 2 Jul 2016 23:40:04 +0000 (01:40 +0200)]
Issue 4914/2: convert-ly rule for removing Output_property_engraver
It's highly unlikely that users will redefine the Score context from
scratch, so the convert-ly rule just removes every occurence of
Output_property_engraver from user source. Obviously, when running the
rule on the LilyPond code base, we will need to fix up the Score
engraver manually to retain the Output_property_engraver .
David Kastrup [Sat, 2 Jul 2016 23:37:15 +0000 (01:37 +0200)]
Issue 4914/1: Move Output_property_engraver to Score level
This has the advantage of needing only one instantiation of the engraver
and not having \applyOutput mysteriously refrain from having an effect
in contexts without Output_property_engraver .
Due to the hierarchical nature of acknowledgers, acknowledgers in lower
contexts will now get to see the grobs before applyOutput has done its
work. However, grobs are still unfinished (except for type, properties
initialized via context properties and cause) at the time they are
announced, with other details only getting filled in by the engraver
after announcement, so the potential for trouble seems low.
Acknowledgers should usually just register a grob (or write grob data)
with any actual reading of grob data occurring at the end of the
timestep instead or in the process-acknowledged phase.
David Kastrup [Thu, 30 Jun 2016 15:26:01 +0000 (17:26 +0200)]
Issue 4911/3: Don't treat context modification identifiers special
This requires using \with before context modifications like
\RemoveEmptyStaves in order to make the syntax get along
with fewer special cases and exceptions.
John Gourlay [Thu, 23 Jun 2016 19:49:25 +0000 (15:49 -0400)]
Reimplement issue 4781 for musicxml2ly more literally. Reimplementation
was necessary as part of the implementation of issue 4751, but some of
the code changes for 4781 were omitted. This reproduces all the 4781 changes.
David Kastrup [Sat, 2 Jul 2016 08:08:42 +0000 (10:08 +0200)]
Issue 4912: Fix output definition use in \book and \bookpart
The only explicit output definition blocks allowed in \book and
\bookpart blocks were paper blocks. Output definitions supplied with
Scheme expressions were erroneously interpreted like global output
definitions, accepting all output definition types and overriding the
global defaults with them.
Now the only output definitions accepted as Scheme expressions are
paper blocks. As opposed to previously, they actually set the paper
block of the respective book or bookpart.
Masamichi Hosoda [Sun, 26 Jun 2016 03:15:33 +0000 (12:15 +0900)]
Issue 4876/5: Add direct parsing CFF for getting Postscript font name
FreeType 2.6 and 2.6.1 cannot get PS name from pure-CFF.
(FreeType 2.5.5 and earlier does not have this issue.
FreeType 2.6.2+ has this bug fixed.)
So we need direct parsing of the 'CFF' table, in this case.
Masamichi Hosoda [Sat, 25 Jun 2016 01:52:44 +0000 (10:52 +0900)]
Issue 4876/1: Add fontname replacing function for CFF (OTF/OTC) fonts
For CFF (OTF/OTC) fonts,
FT_Get_Postscript_Name ()
in FreeType 2.6+ gets the name in 'name' table.
However, we want the name in 'CFF' table instead of in 'name' table
because output postscript file is embedded only 'CFF' table of the font.
They are inconsistent for some OpenType/CFF Collection fonts (OTC).
This function can get the name in 'CFF' table.
TODO: Check conflicts between fonts which have same name in 'CFF' table
but different name in 'name' table.
Masamichi Hosoda [Sun, 19 Jun 2016 12:54:46 +0000 (21:54 +0900)]
Issue 4902/2: Improve `-dgs-load-fonts` option for TTF
`-dgs-load-fonts` loads fonts via Ghostscript.
However, if a TrueType font (TTF)
that does not have glyph names is loaded via Ghostscript,
all characters are shown in TOFU.
This commit lets `-dgs-load-fonts` loads those fonts
in a way that is not via Ghostscript.
Masamichi Hosoda [Sun, 19 Jun 2016 02:59:45 +0000 (11:59 +0900)]
Issue 4901: Improve `-dgs-load-fonts` option for OTC fonts
`-dgs-load-fonts` loads fonts via Ghostscript.
However, Ghostscript could not load
OpenType/CFF Collection (OTC) fonts by this way.
http://bugs.ghostscript.com/show_bug.cgi?id=696808
This commit lets `-dgs-load-fonts` loads the OTC fonts
in a way that is not via Ghostscript.
Masamichi Hosoda [Sat, 18 Jun 2016 13:49:44 +0000 (22:49 +0900)]
Issue 4900: Improve `-dgs-load-fonts` option for non-zero font-index
`-dgs-load-fonts` loads fonts via Ghostscript.
However, it could not load the font that has non-zero font-index.
This commit lets it loads the font
in a way that is not via Ghostscript.
David Kastrup [Sat, 25 Jun 2016 21:01:25 +0000 (23:01 +0200)]
Don't overload Slur_engraver::listen_slur
Having two overloaded variants of Slur_engraver::listen_slur leads to
problems with ADD_LISTENER template resolution at least in some versions
of g++. So the two-argument version is renamed to listen_note_slur.
David Kastrup [Mon, 20 Jun 2016 21:48:14 +0000 (23:48 +0200)]
Issue 4903/4: Fold Slur_proto_engraver into Slur_engraver
A symmetrical common base class to both Slur_engraver and
Phrasing_slur_engraver seems like an unnecessary complication. Instead,
Phrasing_slur_engraver can just be derived from Slur_engraver .
David Kastrup [Thu, 16 Jun 2016 17:52:01 +0000 (19:52 +0200)]
Issue 4897: Allow multiple \with per context creation
This allows using more than one \with context modification in
connection with \new, \context, \addlyrics, \drums, \lyrics, \chords,
\figures . While combining them inside of a single \with {...} is
possible, sometimes it may be inconvenient.
David Kastrup [Sat, 18 Jun 2016 08:13:10 +0000 (10:13 +0200)]
Issue 4899/4: Listeners should not be virtual
Gregorian_ligature_engraver::listen_pes_or_flexa and
Ligature_engraver::listen_pes_or_flexa were accidentally
declared virtual, but their registration already caters
for what amounts to virtual overrides in effect.
Thomas Morley [Tue, 14 Jun 2016 19:11:16 +0000 (21:11 +0200)]
Issue 4895 Give SystemStartSquare a default of 5.0 for collapse-height
This ensures same behaviour of SystemStartSquare while using
RemoveEmptyStaves as SystemStartBar, SystemStartBrace and
SystemStartBracket. The latter ones already have this default.