bug#53636: 29.0.50; face-remapping broken on master

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 53636@debbugs.gnu.org,  tsdh@gnu.org
> Date: Sat, 05 Feb 2022 23:27:36 +0100
> 
> (progn
>   (face-remap-add-relative 'mode-line 'link-visited)
>   (make-frame))
> 
> vs
> 
> (progn
>   (face-remap-add-relative 'mode-line 'link-visited)
>   (switch-to-buffer "*Messages*")
>   (make-frame))
> 
> In the first case, the new frame will have mode-line remapped to
> link-visited in all windows, while in the latter it won't.  So it looks
> like a pretty simple bug -- `make-frame' (when computing the faces for
> the new frame) is using the buffer-local value of
> `face-remapping-alist' instead of the global one.

But which case is considered a bug?  In the first case, the mode line
of *scratch* is affected in the second frame; in the second case the
remapping doesn't show in that buffer on _any_ frame, although
face-remapping-alist is updated.

> But after poking at the code for a couple minutes, I'm not sure where
> the computation for faces is done for new faces.  Hm...  is it
> `face-spec-recalc'?  Hm...  but that doesn't access
> `face-remapping-alist'...   Is this done at a lower level?

What is "this" and "the computation" which you are asking about here?