[ moving from autoconf-commit ] Hi Eric,
* Eric Blake wrote on Thu, Jan 22, 2009 at 04:28:58PM CET: > commit 76b444921d13dd34e647efc662431f7b563c503d > Author: Eric Blake <[email protected]> > Date: Thu Jan 22 08:08:06 2009 -0700 > > Silence a false positive expand-before-require case. > --- a/lib/m4sugar/m4sugar.m4 > +++ b/lib/m4sugar/m4sugar.m4 > @@ -1723,28 +1723,34 @@ m4_define([m4_undivert], > # > # The problem can only occur if a single defun'd macro first provides, > # then later indirectly requires, the same macro. Note that directly > -# expanding then requiring a macro is okay, since the requirement will > -# be a no-op; the problem is only present if the requirement is nested > -# inside a context that will be hoisted in front of the outermost > -# defun'd macro. In other words, we must be careful not to warn on: > +# expanding then requiring a macro is okay, because the dependency was > +# met, the require phase will be a no-op; the out-of-order expansion > +# problem is only present if the requirement is nested inside a > +# context that will be hoisted in front of the outermost defun'd > +# macro. In other words, we must be careful not to warn on: > # > # | m4_defun([TEST4], [4]) > # | m4_defun([TEST5], [TEST4 REQUIRE([TEST5])]) > # This looks fishy to me: a test requiring itself? Is that what was meant here? If yes, then I suggest this case appear in the testsuite, too. > +# So, to detect whether a require was direct or indirect, m4_provide > +# stores the diversion number at which a macro was provided. A > +# require call is direct if it occurs within the same diversion that > +# the macro was provided. Thanks, Ralf > --- a/tests/m4sugar.at > +++ b/tests/m4sugar.at > @@ -583,6 +583,13 @@ c > d > post2])dnl > outer > +m4_defun([e], [[e]])dnl > +m4_defun([f], [[f]m4_require([e])])dnl > +m4_defun([g], [[g] > +e > +f])dnl > +m4_defun([h], [[h]m4_require([g])])dnl > +h > ]], > [[pre1 > a [...]
