bin/49214: make(1) parsing bug with dynamic sources

[dholland%netbsd.org@localhost]

>Number:         49214
>Category:       bin
>Synopsis:       make(1) parsing bug with dynamic sources
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 18 08:05:00 +0000 2014
>Originator:     David A. Holland
>Release:        NetBSD 7.99.1 (20140918)
>Organization:
>Environment:
System: NetBSD homeworld.netbsd.org 6.1_STABLE NetBSD 6.1_STABLE (NBMAIL) #0: 
Tue Jun 10 18:49:40 UTC 2014 
spz%franklin.NetBSD.org@localhost:/home/netbsd/6/amd64/obj/sys/arch/amd64/compile/NBMAIL
 amd64
Architecture: x86_64
Machine: amd64
>Description:

Observe the following:

   ------
% cat woops
blah: ;
foo: $(.TARGET:S/foo/mo oo/)
        echo $(.ALLSRC)
bar $(.TARGET:S/foo/mo oo/): blah
        echo $(.ALLSRC)
% make -f woops foo
make: Unclosed substitution for @ (/ missing)
make: don't know how to make oo/). Stop

make: stopped in [dir]
% make -f woops bar
echo blah
blah
%
   ------

The space inside the variable is only parsed correctly when the
variable is on the target side of the rule.

But there's a second problem: what does it even mean for $(.TARGET) to
be used on the target side of the rule? It's not sensible and produces
odd behavior. The unexpanded variable string becomes itself a rule
name, and then trying to use $(.TARGET) blows up because it's self-
referential:

   ------
% cat woops2
blah:;
foo $(.TARGET:S/foo/moo/): blah
        echo $(.ALLSRC)
bar $(.TARGET:S/bar/baz/): blah
        echo $(.TARGET)

% make -f woops2 '$(.TARGET:S/foo/moo/)'
echo blah
blah
% make -f woops2 '$(.TARGET:S/bar/baz/)'
Variable @ is recursive.

make: stopped in [dir]
   ------

This situation arises because $(.TARGET) and a handful of other rules
are allowed to be expanded dynamically in the sources list for each
target in a rule; therefore they're expanded late and not during the
main parsing pass.

However, it seems that someone accidentally added the code to
recognize them and call Var_Parse on them to properly find the end of
the variable reference to the targets half of the dependency rule
parser in ParseDoDependency instead of the source half. (This is
entirely understandable as the code's quite a maze.)

They aren't valid at all as targets and should be rejected if found on
the targets side.

A passing note that a problem might exist appeared in the PR 49085
patch from Jarmo Jaakkola, although this issue is otherwise unrelated
to that PR.

>How-To-Repeat:
as above
>Fix:

move the logic as needed