bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Damien Cassou]

Hi,

I try to make all my packages warning free by setting
byte-compile-error-on-warn and running the byte compiler during
continuous integration. I do that for both Emacs 25 and Emacs 26. This
has become impossible with Emacs 26 because when-let is deprecated but
it’s replacement does not exist in Emacs 25.

I can think of two solutions to make my life easier (and potentially
other package maintainers who care about code quality):

- introduce when-let* (and if-let*) in Emacs 25; or

- un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
  later.

Best

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Nicolas Petton]

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

Damien Cassou <damien@cassou.me> writes:

> Hi,

Hi Damien,

> I can think of two solutions to make my life easier (and potentially
> other package maintainers who care about code quality):
>
> - introduce when-let* (and if-let*) in Emacs 25; or

That's probably not an option.

> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>   later.

I'm facing the same issue, un-deprecating when-let would also make my CI
happier.

Cheers,
Nico

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

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

Damien Cassou <damien@cassou.me> writes:

> I try to make all my packages warning free by setting
> byte-compile-error-on-warn and running the byte compiler during
> continuous integration. I do that for both Emacs 25 and Emacs 26. This
> has become impossible with Emacs 26 because when-let is deprecated but
> it’s replacement does not exist in Emacs 25.

Couldn't you do

(eval-when-compile
  (unless (fboundp 'when-let*)
    (defalias 'when-let* 'when-let)))

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Damien Cassou]

Noam Postavsky <npostavs@users.sourceforge.net> writes:
> Couldn't you do
>
> (eval-when-compile
>   (unless (fboundp 'when-let*)
>     (defalias 'when-let* 'when-let)))

sure, that's a possible workaround. I was more talking about a solution
for everyone as I guess I'm not the only one to face the problem.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

Damien Cassou <damien@cassou.me> writes:

> I can think of two solutions to make my life easier (and potentially
> other package maintainers who care about code quality):
>
> - introduce when-let* (and if-let*) in Emacs 25; or

Since we don't have a time machine, this seems impractical (or if you
mean release 25.4 just for this, kind of overkill).

> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>   later.

When is "later"?  Wouldn't the problem remain indefinitely?  It kind of
sounds like this is suggestion means Emacs could no longer deprecate
anything.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Damien Cassou]

Noam Postavsky <npostavs@users.sourceforge.net> writes:
> Since we don't have a time machine, this seems impractical (or if you
> mean release 25.4 just for this, kind of overkill).


I would also like a time machine but I was more referring to a new
release of Emacs 25.


>> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>>   later.
>
> When is "later"?  Wouldn't the problem remain indefinitely?


That’s a question we need to answer. I think supporting 2 releases would
already be good (i.e., 26.1 does not deprecate but 26.2 does).


> It kind of sounds like this is suggestion means Emacs could no longer
> deprecate anything.


I’m all in favor of deprecation. This is important to move forward.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eli Zaretskii]

> From: Damien Cassou <damien@cassou.me>
> Date: Wed, 10 Jan 2018 13:13:44 +0100
> Cc: 30039@debbugs.gnu.org
> 
> Noam Postavsky <npostavs@users.sourceforge.net> writes:
> > Since we don't have a time machine, this seems impractical (or if you
> > mean release 25.4 just for this, kind of overkill).
> 
> 
> I would also like a time machine but I was more referring to a new
> release of Emacs 25.

You mean, release Emacs 25.4 with this single change?  That's unlikely
to happen.  And even if it did, I don't understand what problem would
it solve: people who have previous versions will still need to
upgrade, and you can tell them to upgrade to Emacs 26.1 exactly as you
can tell them to upgrade to 25.4.  What am I missing?

> >> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
> >>   later.
> >
> > When is "later"?  Wouldn't the problem remain indefinitely?
> 
> That’s a question we need to answer. I think supporting 2 releases would
> already be good (i.e., 26.1 does not deprecate but 26.2 does).

That's not how we deprecate stuff.  We never wait with deprecation,
only with the actual removal.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Nicolas Petton]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> That’s a question we need to answer. I think supporting 2 releases would
>> already be good (i.e., 26.1 does not deprecate but 26.2 does).
>
> That's not how we deprecate stuff.  We never wait with deprecation,
> only with the actual removal.

But in this case it leads to an issue with linting: when-let cannot be
used in packages if we want to support both Emacs 25 and 26, since
when-let has been deprecated and when-let* didn't exist in Emacs 25.

Of course the linter could be tweaked in the CI to keep builds green,
but that feels like a hack.

Nico

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

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Glenn Morris]

Nicolas Petton wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> That's a question we need to answer. I think supporting 2 releases would
>>> already be good (i.e., 26.1 does not deprecate but 26.2 does).
>>
>> That's not how we deprecate stuff.  We never wait with deprecation,
>> only with the actual removal.
>
> But in this case it leads to an issue with linting: when-let cannot be
> used in packages if we want to support both Emacs 25 and 26, since
> when-let has been deprecated and when-let* didn't exist in Emacs 25.

What's special about this case?
If you:
1) require a warning-free compilation in two releases of Emacs with the
same codebase
2) decline to use standard techniques such as https://debbugs.gnu.org/30039#11

then isn't the conclusion that *nothing* can be marked obsolete unless
the replacement existed in the previous release? Are you asking for this
to become Emacs policy?

Surely this would slow down the adoption of new techniques (because
people wouldn't start seeing the obsolescence warnings till another
release goes by).

I don't like compilation warnings either, but this position seems odd to
me.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: 30039@debbugs.gnu.org, npostavs@users.sourceforge.net
> Date: Wed, 10 Jan 2018 17:24:43 +0100
> 
> >> That’s a question we need to answer. I think supporting 2 releases would
> >> already be good (i.e., 26.1 does not deprecate but 26.2 does).
> >
> > That's not how we deprecate stuff.  We never wait with deprecation,
> > only with the actual removal.
> 
> But in this case it leads to an issue with linting: when-let cannot be
> used in packages if we want to support both Emacs 25 and 26, since
> when-let has been deprecated and when-let* didn't exist in Emacs 25.

It's unfortunate that we got into this situation, but we cannot change
the past, can we?  And releasing another Emacs 25.x, even if we decide
to do that, will change nothing, because users of Emacs 25.3 and older
will still have the same problem.

And frankly, a few byte-compilation warnings are not such a
catastrophe, we have many dozens of them when we build Emacs.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

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

On Tue, Jan 9, 2018 at 3:16 AM, Nicolas Petton <nicolas@petton.fr> wrote:

>> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>>   later.
>
> I'm facing the same issue, un-deprecating when-let would also make my CI
> happier.

How about adding a variable which suppresses deprecation warnings from
a specified version and up. Attached is a work-in-progress patch which
would allow you to set byte-compile-not-obsolete-since to "25.1" in
your CI script (or file-locally) and thus ignore deprecation warnings
from 26.1 or newer.

Alternatively, or additionally, we could let
`byte-compile-not-obsolete-funcs' apply to macros as well (currently
macroexp-macroexpand doesn't consult it).

[-- Attachment #2: v1-0001-WIP-Allow-suppressing-obsoletion-warnings-per-ver.patch --]
[-- Type: application/octet-stream, Size: 3826 bytes --]

From 4920c1a8e967b8317a3272feb6bf63b99301be2a Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 10 Jan 2018 14:07:27 -0500
Subject: [PATCH v1] [WIP] Allow suppressing obsoletion warnings per-version
 (Bug#30039)

* lisp/emacs-lisp/bytecomp.el (byte-compile-not-obsolete-since): New
variable.
(byte-compile-warn-obsolete):
* lisp/emacs-lisp/macroexp.el (macroexp-macroexpand): Check it.

TODO: NEWS, test, other FIXMEs in source.
---
 lisp/emacs-lisp/bytecomp.el | 18 +++++++++++++++---
 lisp/emacs-lisp/macroexp.el | 20 ++++++++++++++------
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index acba9e2..f6ea25b 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -392,6 +392,14 @@ byte-compile-global-not-obsolete-vars
 (defvar byte-compile-not-obsolete-funcs nil
   "List of functions that shouldn't be reported as obsolete.")
 
+(defvar byte-compile-not-obsolete-since nil
+  ;; FIXME: shorter summary line
+  "If set, only report obsolete symbols that were obsoleted
+  earlier than this version.")
+
+;;;###autoload
+(put 'byte-compile-not-obsolete-since 'safe-local-variable #'stringp)
+
 (defcustom byte-compile-generate-call-tree nil
   "Non-nil means collect call-graph information when compiling.
 This records which functions were called and from where.
@@ -1243,12 +1251,16 @@ byte-compile-warn-obsolete
   "Warn that SYMBOL (a variable or function) is obsolete."
   (when (byte-compile-warning-enabled-p 'obsolete)
     (let* ((funcp (get symbol 'byte-obsolete-info))
+           (var-info (get symbol 'byte-obsolete-variable))
            (msg (macroexp--obsolete-warning
                  symbol
-                 (or funcp (get symbol 'byte-obsolete-variable))
+                 (or funcp var-info)
                  (if funcp "function" "variable"))))
-      (unless (and funcp (memq symbol byte-compile-not-obsolete-funcs))
-	(byte-compile-warn "%s" msg)))))
+      (unless (or (and funcp (memq symbol byte-compile-not-obsolete-funcs))
+                  (and (stringp byte-compile-not-obsolete-since)
+                       (version<= byte-compile-not-obsolete-since
+                                  (nth 2 (or funcp var-info)))))
+        (byte-compile-warn "%s" msg)))))
 
 (defun byte-compile-report-error (error-info &optional fill)
   "Report Lisp error in compilation.
diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index b2ac8be..e64e439 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -189,12 +189,20 @@ macroexp-macroexpand
                  (byte-compile-warning-enabled-p 'obsolete)))
         (let* ((fun (car form))
                (obsolete (get fun 'byte-obsolete-info)))
-          (macroexp--warn-and-return
-           (macroexp--obsolete-warning
-            fun obsolete
-            (if (symbolp (symbol-function fun))
-                "alias" "macro"))
-           new-form))
+          (unless (or
+                   ;; FIXME: Deduplicate with `byte-compile-warn-obsolete'.
+                   (and fun (memq fun (and (boundp 'byte-compile-not-obsolete-funcs)
+                                           byte-compile-not-obsolete-funcs)))
+                   (and (boundp 'byte-compile-not-obsolete-since)
+                        (stringp byte-compile-not-obsolete-since)
+                        (version< byte-compile-not-obsolete-since
+                                  (nth 2 obsolete))))
+            (macroexp--warn-and-return
+             (macroexp--obsolete-warning
+              fun obsolete
+              (if (symbolp (symbol-function fun))
+                  "alias" "macro"))
+             new-form)))
       new-form)))
 
 (defun macroexp--expand-all (form)
-- 
2.6.2.windows.1

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Nicolas Petton]

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

Eli Zaretskii <eliz@gnu.org> writes:

> And releasing another Emacs 25.x, even if we decide to do that, will
> change nothing, because users of Emacs 25.3 and older will still have
> the same problem.

That's true, I didn't propose to do that.

> And frankly, a few byte-compilation warnings are not such a
> catastrophe, we have many dozens of them when we build Emacs.

It's definitely not a big deal, but I mentioned the issue with CI &
linting as I think issues like this one could be in the way of their
adoption by package authors.

Nico

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

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Nicolas Petton]

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

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> How about adding a variable which suppresses deprecation warnings from
> a specified version and up. Attached is a work-in-progress patch which
> would allow you to set byte-compile-not-obsolete-since to "25.1" in
> your CI script (or file-locally) and thus ignore deprecation warnings
> from 26.1 or newer.

I think that could be a nice workaround, thanks.  What do others think?

Nico

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

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eric Abrahamsen]

Nicolas Petton <nicolas@petton.fr> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> And releasing another Emacs 25.x, even if we decide to do that, will
>> change nothing, because users of Emacs 25.3 and older will still have
>> the same problem.
>
> That's true, I didn't propose to do that.
>
>> And frankly, a few byte-compilation warnings are not such a
>> catastrophe, we have many dozens of them when we build Emacs.
>
> It's definitely not a big deal, but I mentioned the issue with CI &
> linting as I think issues like this one could be in the way of their
> adoption by package authors.

I removed uses of when-let from my packages altogether, just because I
was being OCD about the compiler warnings. I've encountered no other
functions where the introduction-deprecation-removal cycle has been so
tight that I have to choose between compiler warnings on the one hand,
or multiple users running an Emacs without the function, on the other.

I agree it's not a big deal, for all the reasons already brought up, but
it was a bit of a frustration.

My 0.5¢,
Eric

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

On Wed, Jan 10, 2018 at 5:05 PM, Eric Abrahamsen
<eric@ericabrahamsen.net> wrote:
> I've encountered no other
> functions where the introduction-deprecation-removal cycle has been so
> tight that I have to choose between compiler warnings on the one hand,
> or multiple users running an Emacs without the function, on the other.

Isn't it standard Emacs practice to mark a function deprecated in the
same commit which introduces the replacement? Examples:

[1: 6f1dea5]: 2017-10-18 18:43:44 -0700
  Spelling fixes
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6f1dea5c74057707bf367f863a8be5750bbb6094

[2: 91932ff]: 2017-02-23 22:39:53 -0500
  Use cl-print for Edebug and EIEIO
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=91932fff1ded8ed3b4d39dd06891f26960153b9e

[3: 3db521c]: 2016-06-07 21:34:51 -0400
  Reduce allout.el's pollution of the namespace.
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3db521ccaf3a5b6892bf23ea1305c7cfe9aa1cce

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Nicolas Petton]

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

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> Isn't it standard Emacs practice to mark a function deprecated in the
> same commit which introduces the replacement? Examples:

Yes, but I think it's quite seldom to have a function introduced, then
deprecated in such a short period.  And from what I've seen, if-let and
when-let popular are quite among package authors.

Nico

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

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eric Abrahamsen]

Nicolas Petton <nicolas@petton.fr> writes:

> Noam Postavsky <npostavs@users.sourceforge.net> writes:
>
>> Isn't it standard Emacs practice to mark a function deprecated in the
>> same commit which introduces the replacement? Examples:
>
> Yes, but I think it's quite seldom to have a function introduced, then
> deprecated in such a short period.  And from what I've seen, if-let and
> when-let popular are quite among package authors.

Right, and the issue wasn't the introduction of when-let*, it was the
very short life-cycle of when-let.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

On Wed, Jan 10, 2018 at 5:57 PM, Eric Abrahamsen
<eric@ericabrahamsen.net> wrote:

> Right, and the issue wasn't the introduction of when-let*, it was the
> very short life-cycle of when-let.

I don't understand how that leads to this:

    I have to choose between compiler warnings on the one hand,
    or multiple users running an Emacs without the function, on the other.

Supposing when-let* was only introduced as a replacement to when-let
in Emacs 30, you would still have to choose between users of Emacs 29
reporting errors, or get deprecation warnings when compiling in Emacs
30. The (hypothetical) longer non-deprecated existence of when-let
over versions 26,27,28,29 wouldn't help (unless you plan to stop
developing your package before Emacs 30, I guess).

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eric Abrahamsen]

On 01/10/18 18:06 PM, Noam Postavsky wrote:
> On Wed, Jan 10, 2018 at 5:57 PM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
>
>> Right, and the issue wasn't the introduction of when-let*, it was the
>> very short life-cycle of when-let.
>
> I don't understand how that leads to this:
>
>     I have to choose between compiler warnings on the one hand,
>     or multiple users running an Emacs without the function, on the other.
>
> Supposing when-let* was only introduced as a replacement to when-let
> in Emacs 30, you would still have to choose between users of Emacs 29
> reporting errors, or get deprecation warnings when compiling in Emacs
> 30. The (hypothetical) longer non-deprecated existence of when-let
> over versions 26,27,28,29 wouldn't help (unless you plan to stop
> developing your package before Emacs 30, I guess).

Ah, you're right. I guess it's just a matter of what Nicolas
mentioned -- these are awfully handy macros, and we're adopting them
early.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Nicolas Petton]

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

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> Yes, but I think it's quite seldom to have a function introduced, then
>> deprecated in such a short period.  And from what I've seen, if-let and
>> when-let popular are quite among package authors.
>
> Right, and the issue wasn't the introduction of when-let*, it was the
> very short life-cycle of when-let.

I think this issue should be closed.  While it is a bit of an annoyance,
I don't think there's much to do about it.

Nico

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

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Damien Cassou]

Noam Postavsky <npostavs@users.sourceforge.net> writes:
> How about adding a variable which suppresses deprecation warnings from
> a specified version and up. Attached is a work-in-progress patch which
> would allow you to set byte-compile-not-obsolete-since to "25.1" in
> your CI script (or file-locally) and thus ignore deprecation warnings
> from 26.1 or newer.

that’s a nice workaround. Is it too late for an inclusion in 26.1? I
guess what I’m really after is a configurable lint tool…

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

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

On Thu, Jan 11, 2018 at 4:19 AM, Damien Cassou <damien@cassou.me> wrote:
> Noam Postavsky <npostavs@users.sourceforge.net> writes:
>> How about adding a variable which suppresses deprecation warnings from
>> a specified version and up. Attached is a work-in-progress patch which
>> would allow you to set byte-compile-not-obsolete-since to "25.1" in
>> your CI script (or file-locally) and thus ignore deprecation warnings
>> from 26.1 or newer.
>
> that’s a nice workaround. Is it too late for an inclusion in 26.1? I
> guess what I’m really after is a configurable lint tool…

Here's a finished version of the patch. Eli, is it okay for emacs-26?

[-- Attachment #2: v2-0001-Allow-suppressing-obsoletion-warnings-per-version.patch --]
[-- Type: application/octet-stream, Size: 7438 bytes --]

From eda75474d4216b1f03c901dd77bf03bd7dd7eee0 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 10 Jan 2018 14:07:27 -0500
Subject: [PATCH v2] Allow suppressing obsoletion warnings per-version
 (Bug#30039)

* lisp/emacs-lisp/bytecomp.el (byte-compile-not-obsolete-since): New
variable.
(byte-compile-obsolete-p): New function, extracted from
byte-compile-warn-obsolete, consult the new variable.
* lisp/emacs-lisp/macroexp.el (macroexp-macroexpand): Use the new
function.
* etc/NEWS: Announce `byte-compile-not-obsolete-since'.
* test/lisp/emacs-lisp/bytecomp-tests.el
(byte-compile-not-obsolete-since): New test.
---
 etc/NEWS                               |  5 +++++
 lisp/emacs-lisp/bytecomp.el            | 40 +++++++++++++++++++++++++++-------
 lisp/emacs-lisp/macroexp.el            | 16 ++++++++------
 test/lisp/emacs-lisp/bytecomp-tests.el | 31 ++++++++++++++++++++++++++
 4 files changed, 77 insertions(+), 15 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index b4c489c..7983ea3 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1613,6 +1613,11 @@ which means ask about all file-visiting buffers.
 ---
 ** string-(to|as|make)-(uni|multi)byte are now declared obsolete.
 
+---
+** New variable 'byte-compile-not-obsolete-since'.
+It may be used to suppress obsoletion warnings later than some
+specified version.
+
 +++
 ** New variable 'while-no-input-ignore-events' which allow
 setting which special events 'while-no-input' should ignore.
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index acba9e2..eae43e7 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -392,6 +392,18 @@ byte-compile-global-not-obsolete-vars
 (defvar byte-compile-not-obsolete-funcs nil
   "List of functions that shouldn't be reported as obsolete.")
 
+(defvar byte-compile-not-obsolete-since nil
+  "Disable obsoletion warnings later than specified version.
+For example, if set to \"25.1\", a function marked as obsolete
+\"since 26.1\" will not be reported as obsolete.  If nil, then
+all obsoletion warnings are enabled (as long as they are not
+already suppressed via `byte-compile-warnings',
+`byte-compile-not-obsolete-funcs', or
+`byte-compile-not-obsolete-vars').")
+
+;;;###autoload
+(put 'byte-compile-not-obsolete-since 'safe-local-variable #'stringp)
+
 (defcustom byte-compile-generate-call-tree nil
   "Non-nil means collect call-graph information when compiling.
 This records which functions were called and from where.
@@ -1239,16 +1251,28 @@ byte-compile-warn
       (error "%s" format)		; byte-compile-file catches and logs it
     (byte-compile-log-warning format t :warning)))
 
-(defun byte-compile-warn-obsolete (symbol)
-  "Warn that SYMBOL (a variable or function) is obsolete."
+(defun byte-compile-obsolete-p (symbol)
+  "Return obsoletion message if SYMBOL is obsolete, nil otherwise.
+Consult `byte-compile-warnings',
+`byte-compile-not-obsolete-funcs' and
+`byte-compile-not-obsolete-since'."
   (when (byte-compile-warning-enabled-p 'obsolete)
     (let* ((funcp (get symbol 'byte-obsolete-info))
-           (msg (macroexp--obsolete-warning
-                 symbol
-                 (or funcp (get symbol 'byte-obsolete-variable))
-                 (if funcp "function" "variable"))))
-      (unless (and funcp (memq symbol byte-compile-not-obsolete-funcs))
-	(byte-compile-warn "%s" msg)))))
+           (var-info (get symbol 'byte-obsolete-variable)))
+      (unless (or (and funcp (memq symbol byte-compile-not-obsolete-funcs))
+                  (and (stringp byte-compile-not-obsolete-since)
+                       (version< byte-compile-not-obsolete-since
+                                 (nth 2 (or funcp var-info)))))
+        (macroexp--obsolete-warning
+         symbol
+         (or funcp var-info)
+         (if funcp "function" "variable"))))))
+
+(defun byte-compile-warn-obsolete (symbol)
+  "Warn that SYMBOL (a variable or function) is obsolete."
+  (let ((msg (byte-compile-obsolete-p symbol)))
+    (when msg
+      (byte-compile-warn "%s" msg))))
 
 (defun byte-compile-report-error (error-info &optional fill)
   "Report Lisp error in compilation.
diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index b2ac8be..6fddec3 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -188,13 +188,15 @@ macroexp-macroexpand
              (or (not (fboundp 'byte-compile-warning-enabled-p))
                  (byte-compile-warning-enabled-p 'obsolete)))
         (let* ((fun (car form))
-               (obsolete (get fun 'byte-obsolete-info)))
-          (macroexp--warn-and-return
-           (macroexp--obsolete-warning
-            fun obsolete
-            (if (symbolp (symbol-function fun))
-                "alias" "macro"))
-           new-form))
+               (obsolete (get fun 'byte-obsolete-info))
+               (msg (if (fboundp 'byte-compile-obsolete-p)
+                        (byte-compile-obsolete-p (car form))
+                      (macroexp--obsolete-warning
+                       fun obsolete
+                       (if (symbolp (symbol-function fun))
+                           "alias" "macro")))))
+          (when msg
+            (macroexp--warn-and-return msg new-form)))
       new-form)))
 
 (defun macroexp--expand-all (form)
diff --git a/test/lisp/emacs-lisp/bytecomp-tests.el b/test/lisp/emacs-lisp/bytecomp-tests.el
index 13df591..afe7b99 100644
--- a/test/lisp/emacs-lisp/bytecomp-tests.el
+++ b/test/lisp/emacs-lisp/bytecomp-tests.el
@@ -431,6 +431,37 @@ test-byte-comp-compile-and-load
     ;; Should not warn that mt--test2 is not known to be defined.
     (should-not (re-search-forward "my--test2" nil t))))
 
+(ert-deftest byte-compile-not-obsolete-since ()
+  (with-current-buffer (get-buffer-create "*Compile-Log*")
+    (let ((inhibit-read-only t)) (erase-buffer)))
+  (let ((forms
+         '((defun test-obsolete-26 ())
+           (defun test-obsolete-25 ())
+           (defun test-obsolete-24 ())
+           ;; Normally, the obsoletion would only take effect after
+           ;; loading the file.
+           (eval-when-compile (make-obsolete 'test-obsolete-26 nil "26.1"))
+           (eval-when-compile (make-obsolete 'test-obsolete-25 nil "25.1"))
+           (eval-when-compile (make-obsolete 'test-obsolete-24 nil "24.1"))
+           (test-obsolete-26) (test-obsolete-25) (test-obsolete-24))))
+    (apply #'test-byte-comp-compile-and-load t forms)
+    (with-current-buffer (get-buffer-create "*Compile-Log*")
+      (goto-char (point-min))
+      (should (search-forward "obsolete-26"))
+      (should (search-forward "obsolete-25"))
+      (should (search-forward "obsolete-24")))
+    (let ((byte-compile-not-obsolete-since "25.1"))
+      (apply #'test-byte-comp-compile-and-load t forms)
+      (with-current-buffer (get-buffer-create "*Compile-Log*")
+        (goto-char (point-min))
+        (should (search-forward "obsolete-25"))
+        (should (search-forward "obsolete-24"))))
+    (let ((byte-compile-not-obsolete-since "25"))
+      (apply #'test-byte-comp-compile-and-load t forms)
+      (with-current-buffer (get-buffer-create "*Compile-Log*")
+        (goto-char (point-min))
+        (should (search-forward "obsolete-24"))))))
+
 (ert-deftest test-eager-load-macro-expansion ()
   (test-byte-comp-compile-and-load nil
     '(progn (defmacro abc (arg) 1) (defun def () (abc 2))))
-- 
2.6.2.windows.1

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Fri, 19 Jan 2018 15:00:30 -0500
> Cc: 30039@debbugs.gnu.org, Nicolas Petton <nicolas@petton.fr>
> 
> Here's a finished version of the patch. Eli, is it okay for emacs-26?

Why is this new feature is urgent or important enough to have it in
Emacs 26?

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Noam Postavsky]

On Fri, Jan 19, 2018 at 3:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Fri, 19 Jan 2018 15:00:30 -0500
>> Cc: 30039@debbugs.gnu.org, Nicolas Petton <nicolas@petton.fr>
>>
>> Here's a finished version of the patch. Eli, is it okay for emacs-26?
>
> Why is this new feature is urgent or important enough to have it in
> Emacs 26?

It's urgent, because it has to be in 26.1 in order to solve the
problem in the OP. More generally, if we introduce the feature in 26.1
in can be useful for suppressing warnings from 26.1 and up, whereas if
we delay it until 27, then it won't be helpful for things marked
obsolete in 26.1. So the timing of when we add it directly affects the
usefulness.

On the other hand, it's maybe not that important, as the problem is
only a warning, and there are other ways of suppressing it (e.g., what
I suggested in #11).

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Fri, 19 Jan 2018 15:40:22 -0500
> Cc: Damien Cassou <damien@cassou.me>, 30039@debbugs.gnu.org, 
> 	Nicolas Petton <nicolas@petton.fr>
> 
> On Fri, Jan 19, 2018 at 3:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Noam Postavsky <npostavs@users.sourceforge.net>
> >> Date: Fri, 19 Jan 2018 15:00:30 -0500
> >> Cc: 30039@debbugs.gnu.org, Nicolas Petton <nicolas@petton.fr>
> >>
> >> Here's a finished version of the patch. Eli, is it okay for emacs-26?
> >
> > Why is this new feature is urgent or important enough to have it in
> > Emacs 26?
> 
> It's urgent, because it has to be in 26.1 in order to solve the
> problem in the OP.

But the problem in the OP is just a minor nuisance.

> More generally, if we introduce the feature in 26.1
> in can be useful for suppressing warnings from 26.1 and up, whereas if
> we delay it until 27, then it won't be helpful for things marked
> obsolete in 26.1. So the timing of when we add it directly affects the
> usefulness.
> 
> On the other hand, it's maybe not that important, as the problem is
> only a warning, and there are other ways of suppressing it (e.g., what
> I suggested in #11).

Exactly.  And since the 26.0.91 pretest is already tarred, and just
awaits to be uploaded, I'd prefer from now on to install on the
release branch only stuff that is really necessary (and documentation
patches).

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Michael Heerdegen]

Hi Damien,

> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>   later.

In the meantime, Stefan Monnier has brought up the issue again in
emacs-dev.  In that discussion we have come to the conclusion that we
want to make when-let and if-let aliases for when-let* and if-let* in
Emacs 26.  Should happen in the next days.


Michael.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Damien Cassou]

Michael Heerdegen <michael_heerdegen@web.de> writes:
> In the meantime, Stefan Monnier has brought up the issue again in
> emacs-dev.  In that discussion we have come to the conclusion that we
> want to make when-let and if-let aliases for when-let* and if-let* in
> Emacs 26.  Should happen in the next days.


I'm happy. Thank you!

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Michael Heerdegen]

Damien Cassou <damien@cassou.me> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
> > In the meantime, Stefan Monnier has brought up the issue again in
> > emacs-dev.  In that discussion we have come to the conclusion that
> > we want to make when-let and if-let aliases for when-let* and
> > if-let* in Emacs 26.  Should happen in the next days.
>
> I'm happy. Thank you!

I've now installed an according change into emacs-26 (I hope it wasn't
too late for this change to be accepted in the release branch).

Thanks for bringing this up.  Closing.


Regards,

Michael.

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Lars Ingebrigtsen]

The warnings for when-let  were removed from Emacs 26, I think?  So I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The warnings for when-let were removed from Emacs 26, I think?  So I'm
> closing this bug report.

Yes, dunno why I forgot to close it.  Thanks.

Michael.