bug#35968: Release 26.3

bug#35968: Release 26.3

[npostavs]

Tracking bugs to fix before releasing Emacs 26.3.

I'm thinking of the following:

#35767 26.1; byte compiler lost warning about calling define-key with wrong number of arguments
       - regression from 25.3, has a simple fix.
       - https://debbugs.gnu.org/35767#8
#29220 26.0.90; eieio-persistent-read fail to restore saved object.
       - regression from 25.3, reasonably simple partial (conditional on eieio-backward-compatibility) fix.
       - https://debbugs.gnu.org/29220#193
#35739 [w32] Bad signature from GNU ELPA for archive-contents
       - fixed in master
       - for emacs-26 need something less invasive
#35770 [PATCH] Broken duplicate case elimination in switch byte-compilation
       - regression from 25.3, fixed in master
       - for emacs-26 just disable optimization (?)

bug#35968: Release 26.3

[Noam Postavsky]

npostavs@gmail.com writes:

> Tracking bugs to fix before releasing Emacs 26.3.
>
> I'm thinking of the following:

Maybe also

#35557 26.1; false positive: Match data clobbered by buffer modification hooks

Though I'm not sure exactly what to do about it.

bug#35968: Release 26.3

[Noam Postavsky]

>> Tracking bugs to fix before releasing Emacs 26.3.
>>
>> I'm thinking of the following:
>
> Maybe also
>
> #35557 26.1; false positive: Match data clobbered by buffer modification hooks

Oops, I meant rather

#35264 "Match data clobbered by buffer modification hooks" when hooks only shifted match-data's markers

Is the patch in https://debbugs.gnu.org/35264#8 okay (generally, and
specifically for emacs-26)?

bug#35968: Release 26.3

[Noam Postavsky]

> Is the patch in https://debbugs.gnu.org/35264#8 okay (generally, and
> specifically for emacs-26)?

For the record, I mention that this patch definitely won't go to
emacs-26, and might be problematic generally (refer
https://lists.gnu.org/r/emacs-devel/2019-06/msg00036.html).

There are no outstanding patches for emacs-26 at the moment.

bug#35968: Release 26.3

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 05 Jun 2019 21:27:55 -0400
> 
> There are no outstanding patches for emacs-26 at the moment.

Thanks, I asked Nicholas to produce a pretest.

bug#35968: Release 26.3

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, I asked Nicholas to produce a pretest.

I'm on it :-)

Cheers,
Nico


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#35968: Release 26.3

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: 35968@debbugs.gnu.org
> Date: Tue, 11 Jun 2019 22:00:21 +0200
> 
> > Thanks, I asked Nicholas to produce a pretest.
> 
> I'm on it :-)

Thanks.

bug#35968: Release 26.3

[Eli Zaretskii]

> From: npostavs@gmail.com
> Date: Tue, 28 May 2019 17:13:42 -0400
> 
> Tracking bugs to fix before releasing Emacs 26.3.
> 
> I'm thinking of the following:
> 
> #35767 26.1; byte compiler lost warning about calling define-key with wrong number of arguments
>        - regression from 25.3, has a simple fix.
>        - https://debbugs.gnu.org/35767#8
> #29220 26.0.90; eieio-persistent-read fail to restore saved object.
>        - regression from 25.3, reasonably simple partial (conditional on eieio-backward-compatibility) fix.
>        - https://debbugs.gnu.org/29220#193
> #35739 [w32] Bad signature from GNU ELPA for archive-contents
>        - fixed in master
>        - for emacs-26 need something less invasive
> #35770 [PATCH] Broken duplicate case elimination in switch byte-compilation
>        - regression from 25.3, fixed in master
>        - for emacs-26 just disable optimization (?)

I'm okay with doing everything where we have a simple enough fix,
which means all but the penultimate bug.

Thanks.

bug#35968: Proposed clean-compile patches for release 26.3

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

I propose the attached patches for Emacs 26.3, to help it compile 
cleanly with more-recent software (GCC 9, librsvg 2.45.1). The idea is 
mainly to avoid bug reports from people who would otherwise send us 
these diagnostics. Most of these patches are already in master; the 
exceptions (patches 2 and 5) are for parts of Emacs that are typically 
not compiled in master.


[-- Attachment #2: 0001-Suppress-GCC-9-no-longer-supported-messages.txt --]
[-- Type: text/plain, Size: 1248 bytes --]

From d8c463238d4164f128aea28e695935e99420c34c Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 29 May 2019 17:31:18 -0700
Subject: [PATCH 1/5] =?UTF-8?q?Suppress=20GCC=209=20=E2=80=9Cno=20longer?=
 =?UTF-8?q?=20supported=E2=80=9D=20messages?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC): Remove -Wchkp.
This suppresses a boatload of warnings of the form
“gcc: warning: switch ‘-Wchkp’ is no longer supported”.
when using GCC 9.  Do not merge to master.
---
 m4/manywarnings.m4 | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/m4/manywarnings.m4 b/m4/manywarnings.m4
index 72fdd41860..c876caa16a 100644
--- a/m4/manywarnings.m4
+++ b/m4/manywarnings.m4
@@ -1,4 +1,4 @@
-# manywarnings.m4 serial 13
+# manywarnings.m4 serial 13-emacs
 dnl Copyright (C) 2008-2019 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -126,7 +126,6 @@ AC_DEFUN
     -Wbuiltin-macro-redefined \
     -Wcast-align \
     -Wchar-subscripts \
-    -Wchkp \
     -Wclobbered \
     -Wcomment \
     -Wcomments \
-- 
2.21.0


[-- Attachment #3: 0002-Pacify-GCC-when-compiling-unexelf.c-on-Fedora-30.txt --]
[-- Type: text/plain, Size: 750 bytes --]

From f54595eceec7a716b156ce32606f165a20a8517d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 29 May 2019 17:31:40 -0700
Subject: [PATCH 2/5] Pacify GCC when compiling unexelf.c on Fedora 30

* src/unexelf.c (unexec): Pacify GCC 9.
---
 src/unexelf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/unexelf.c b/src/unexelf.c
index c63a8d03c2..6d19bf1fb9 100644
--- a/src/unexelf.c
+++ b/src/unexelf.c
@@ -304,6 +304,7 @@ unexec (const char *new_name, const char *old_name)
 	      || seg->p_vaddr > old_bss_seg->p_vaddr))
 	old_bss_seg = seg;
     }
+  eassume (old_bss_seg);
 
   /* Note that old_bss_addr may be lower than the first bss section
      address, since the section may need aligning.  */
-- 
2.21.0


[-- Attachment #4: 0003-Simplify-xd_signature-to-pacify-GCC-9.txt --]
[-- Type: text/plain, Size: 1305 bytes --]

From 088e6d83f1af7e540e69595d560aeeb16db62d76 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 29 May 2019 17:32:37 -0700
Subject: [PATCH 3/5] Simplify xd_signature to pacify GCC 9

* src/dbusbind.c (xd_signature): Use simpler way to set up
the subsignature.  This also pacifies GCC 9 on Fedora 30 x86-64.
Backport from master.
---
 src/dbusbind.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/dbusbind.c b/src/dbusbind.c
index 6ae9bc7f53..fcb58f7448 100644
--- a/src/dbusbind.c
+++ b/src/dbusbind.c
@@ -346,7 +346,6 @@ xd_signature (char *signature, int dtype, int parent_type, Lisp_Object object)
   int subtype;
   Lisp_Object elt;
   char const *subsig;
-  int subsiglen;
   char x[DBUS_MAXIMUM_SIGNATURE_LENGTH];
 
   elt = object;
@@ -428,10 +427,9 @@ xd_signature (char *signature, int dtype, int parent_type, Lisp_Object object)
 	  elt = CDR_SAFE (XD_NEXT_VALUE (elt));
 	}
 
-      subsiglen = snprintf (signature, DBUS_MAXIMUM_SIGNATURE_LENGTH,
-			    "%c%s", dtype, subsig);
-      if (! (0 <= subsiglen && subsiglen < DBUS_MAXIMUM_SIGNATURE_LENGTH))
-	string_overflow ();
+      signature[0] = dtype;
+      signature[1] = '\0';
+      xd_signature_cat (signature, subsig);
       break;
 
     case DBUS_TYPE_VARIANT:
-- 
2.21.0


[-- Attachment #5: 0004-Pacify-librsvg-2.45.1-and-later.txt --]
[-- Type: text/plain, Size: 1719 bytes --]

From 528b361f2c121398f01a8c4210130524cf4450dd Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 29 May 2019 17:38:21 -0700
Subject: [PATCH 4/5] Pacify librsvg 2.45.1 and later

* src/image.c (svg_load_image): Pacify librsvg 2.45.1 and later,
and add a FIXME comment about the deprecated librsvg functions.
Backport from master.
---
 src/image.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/src/image.c b/src/image.c
index 50515e1a42..bda60c03a1 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9306,6 +9306,17 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   if (filename)
     rsvg_handle_set_base_uri(rsvg_handle, filename);
 
+  /* Suppress GCC deprecation warnings starting in librsvg 2.45.1 for
+     rsvg_handle_write and rsvg_handle_close.  FIXME: Use functions
+     like rsvg_handle_new_from_gfile_sync on newer librsvg versions,
+     and remove this hack.  */
+  #if GNUC_PREREQ (4, 6, 0)
+   #pragma GCC diagnostic push
+  #endif
+  #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
+   #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+  #endif
+
   /* Parse the contents argument and fill in the rsvg_handle.  */
   rsvg_handle_write (rsvg_handle, (unsigned char *) contents, size, &err);
   if (err) goto rsvg_error;
@@ -9315,6 +9326,10 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   rsvg_handle_close (rsvg_handle, &err);
   if (err) goto rsvg_error;
 
+  #if GNUC_PREREQ (4, 6, 0)
+   #pragma GCC diagnostic pop
+  #endif
+
   rsvg_handle_get_dimensions (rsvg_handle, &dimension_data);
   if (! check_image_size (f, dimension_data.width, dimension_data.height))
     {
-- 
2.21.0


[-- Attachment #6: 0005-Pacify-GCC-9-Wredundant-decls.txt --]
[-- Type: text/plain, Size: 1474 bytes --]

From 4bcbc3a3eb58543ef4a16e7692151b97ddda3ae7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 29 May 2019 17:45:30 -0700
Subject: [PATCH 5/5] Pacify GCC 9 -Wredundant-decls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/gmalloc.c (_fraghead) [!HYBRID_MALLOC]:
Make it static in this case, too.  This avoids having both
‘extern struct list _fraghead[];’ and
‘static struct list _fraghead[BLOCKLOG];’, which
GCC 9 complains about.
---
 src/gmalloc.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/src/gmalloc.c b/src/gmalloc.c
index f3b3d77aac..9284d9bd60 100644
--- a/src/gmalloc.c
+++ b/src/gmalloc.c
@@ -182,7 +182,7 @@ struct list
   };
 
 /* Free list headers for each fragment size.  */
-extern struct list _fraghead[];
+static struct list _fraghead[BLOCKLOG];
 
 /* List of blocks allocated with aligned_alloc and friends.  */
 struct alignlist
@@ -339,9 +339,6 @@ size_t _heapindex;
 /* Limit of valid info table indices.  */
 size_t _heaplimit;
 
-/* Free lists for each fragment size.  */
-struct list _fraghead[BLOCKLOG];
-
 /* Instrumentation.  */
 size_t _chunks_used;
 size_t _bytes_used;
@@ -351,10 +348,6 @@ size_t _bytes_free;
 /* Are you experienced?  */
 int __malloc_initialized;
 
-#else
-
-static struct list _fraghead[BLOCKLOG];
-
 #endif /* HYBRID_MALLOC */
 
 /* Number of extra blocks to get each time we ask for more core.
-- 
2.21.0

bug#35968: Proposed clean-compile patches for release 26.3

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 29 May 2019 18:10:24 -0700
> 
> I propose the attached patches for Emacs 26.3, to help it compile 
> cleanly with more-recent software (GCC 9, librsvg 2.45.1). The idea is 
> mainly to avoid bug reports from people who would otherwise send us 
> these diagnostics. Most of these patches are already in master; the 
> exceptions (patches 2 and 5) are for parts of Emacs that are typically 
> not compiled in master.

Thanks.  I'm okay with all these changes, with one possible exception:

> @@ -351,10 +348,6 @@ size_t _bytes_free;
>  /* Are you experienced?  */
>  int __malloc_initialized;
>  
> -#else
> -
> -static struct list _fraghead[BLOCKLOG];
> -
>  #endif /* HYBRID_MALLOC */
>  
>  /* Number of extra blocks to get each time we ask for more core.

This hunk seems to be just an aesthetic cleanup.  Does it cause any
warnings/errors during compilation?  If not, I'd prefer to leave it
out, for paranoia reasons.

bug#35968: Proposed clean-compile patches for release 26.3

[Paul Eggert]

On 5/30/19 7:03 AM, Eli Zaretskii wrote:
> This hunk seems to be just an aesthetic cleanup. Does it cause any 
> warnings/errors during compilation? If not, I'd prefer to leave it 
> out, for paranoia reasons.

Yes, if the hunk is omitted, _fraghead is defined twice and GCC complains:

   gmalloc.c:353:20: error: redundant redeclaration of ‘_fraghead’ 
[-Werror=redundant-decls]
     353 | static struct list _fraghead[BLOCKLOG];
     |                    ^~~~~~~~~
   gmalloc.c:185:20: note: previous declaration of ‘_fraghead’ was here
     185 | static struct list _fraghead[BLOCKLOG];
     |                    ^~~~~~~~~

So I installed the patches as-is.