bug#51577: [External] : Re: bug#51577: 27.2; Regression: reproducible hang with face functions

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "51577@debbugs.gnu.org" <51577@debbugs.gnu.org>
> Date: Wed, 3 Nov 2021 18:58:23 +0000
> 
> > You set the region face to inherit from itself, and you expect that to
> > work without causing an infloop when Emacs tries to resolve some face
> > attribute?
> 
> Yes.  I expected Emacs to act as it has in the past,
> and ignore such an :inherit as a no-op.

What happened in the past was the result of the implementation, not
the design.  The implementation changed (for valid reasons), so the
undefined behavior your code invokes now gets you in trouble.

> > If FACE1 has some attribute 'unspecified', but inherits
> > from FACE2, Emacs will try to go up the inheritance chain to see if
> > some of the parent faces specifies that attribute.  If FACE1 inherits
> > from itself, going up the inheritance chain will never end.
> 
> Only if the implementation doesn't recognize the
> inheritance loop.

What would you expect it to do if it did?

And how does your code differ from this:

  (while t nil)

Or would you consider it a bug that Emacs doesn't detect the infinite
while-loop, either?

> > IOW, it's a cockpit error.
> 
> You can look at it that way.  But I'd expect that
> inheritance of a face from itself would be a no-op.

Why?

> And that's exactly what the case was in Emacs 26.

Yes, undefined behavior can do different things in different versions.

> Why should the code now chase its tail down an
> infinite rabbit hole?  Is this really by design?

The design is to chase the inheritance chain, yes.  Why is it needed
is a long story, and isn't really relevant for the issue at hand, as
long as it isn't a bug or faulty design.  Faces aren't supposed to
inherit from themselves, period.

> Not rhetorical questions.  It seems like a design
> change has been made, but with no announcement.

The announcement _was_ made, but we announce features, not their
designs.