toolchain/53146: make: .for loop binder names aren't expanded

[dholland%NetBSD.org@localhost]

	Note: There was a bad value `' for the field `Confidential'.
	It was set to the default value of `yes'.

>Number:         53146
>Category:       toolchain
>Synopsis:       make: .for loop binder names aren't expanded
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 02 04:55:00 +0000 2018
>Originator:     David A. Holland
>Release:        NetBSD 8.99.8 (20171205)
>Organization:
>Environment:
System: NetBSD valkyrie 8.99.8 NetBSD 8.99.8 (VALKYRIE) #24: Tue Dec  5 17:30:57 EST 2017  dholland@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

In ordinary assignments the variable name can be supplied as a
variable expansion:

        BAR=bar
        $(BAR)=baz
        meh:
                echo $(bar)

prints "baz".

However, this is not accepted in a .for loop. The name becomes the
string formed by the variable reference itself.

This:
        FOO=foo
        meh:
        .for $(FOO) in a b
                echo "$(FOO)" , "$(foo)" , "$($(FOO))"
        .endfor
prints (with make -n)
        echo "foo" , "" , "a"
        echo "foo" , "" , "b"

What seems to be happening is that the loop binds a variable named
"$(FOO)", so no variable "foo" is bound; then when make goes to
evaluate $($(FOO)) it finds that "FOO" is a variable but not a loop
variable, so it doesn't expand it yet; but then it sees that "$(FOO)"
is a loop variable and expands that, so we get the loop values in the
third print even though one might expect $($(FOO)) to evaluate to the
same thing as $(foo).

>How-To-Repeat:

as above.

>Fix:

Probably for-loop binders should be allowed to be named by variable
expansions like regular assignments; that is, the for code should do
variable expansion on the binder names. This seems like a wild thing
to do, but there doesn't seem to be any obvious reason to forbid it.

Otherwise we'd want to look for variable expansions in there and error
on them. The current behavior is clearly undesirable.

(also variable names in general shouldn't be allowed to contain "$",
but that's a broader issue)