Jonas Hahnfeld <[email protected]> writes: > Am Sonntag, den 22.11.2020, 22:49 +0100 schrieb David Kastrup: >> >> To me that seems crazy. Instead \footnote should not modify the >> stencil generated from its argument in place. If it needs something >> with different dimensions, it needs to create a new stencil, copying >> the stencil expression and changing the dimensions. > > Yes indeed, this seems to be the contract for stencils: Make a copy > whenever a Stencil is passed in from Scheme.
And/or is not being generated from scratch. > I managed to find the code path for Balloon grobs that violate this > rule, here's a fix: > https://gitlab.com/lilypond/lilypond/-/merge_requests/522 (Note that > the test case shows that this was already broken before this unstable > series, at least 2.20.0 but probably older versions too). > > If possible, I'd like to merge this rather sooner than later so I can > finally post the MR to enable 'make check'... > >> ly:stencil-set-extent! has been removed in 2.5.17. Extents are not >> intended to be mutable as far as I can discern, so if our C++ code >> does violate that assumption, it is that code we should fix instead >> of giving up on behavior guaranteed from the Scheme side of things. > > In fact, the C++ code does and many methods of the Stencil class modify > the object, but this is ok as long as we stick to the rule above. Well, basically the rule should be that as soon as a Stencil is exposed to the Scheme layer, it is immutable. Stencils are of type Simple_smob, so one could stipulate that the result of any call to smobbed_copy () is off-limits for further modification. It's not the absolute point after which things come crashing down, but it's close. In particular, anything that we access via unsmob<Stencil> should be considered off-limits for modification. I have no idea whether there is a sane C++ way of ensuring that automagically. > I'd be happy to assert in some way that stencil representations coming > from Scheme are not altered, but I can't think of a good way to do > this... > -- David Kastrup
