bug#20241: 25.0.50; `setq' with only one argument

[Drew Adams <drew.adams@oracle.com>]

> If you found four occurrences merely by grepping, there could well be
> quite a few more.  In the last one, for example, can we be sure that nil
> is intended, not that the real argument has just been missed out?

If you cannot now analyze the code properly to determine TRT, or
contact the author to make that determination, then do the obvious
(IMO): Assign a `nil' value explicitly where it is now assigned
implicitly.

AND flag that amended code with a comment saying what you've done,
and that you don't currently know whether (a) there is a bug here
or (b) `nil' is really what is needed.

IOW: (1) At least just ensure that the code does the same thing
that it does now, but respects the intended meaning of `setq'.
(2) If you have to punt the careful analysis for later or for
someone else, then add a comment to that effect.

> Maybe having the byte compiler error out in this situation isn't such a
> brilliant idea after all.

IMO, the bug should be fixed to raise an _error at runtime_, for
both interpreted and byte-compiled code.

Whatever else the byte-compiler might do is less important, as
long as it produces code that is comparable - e.g., code that
will also raise an _error at runtime_.

It's OK for a byte-compiler to be smart, but not smarter than
the actual source code ;-).  It should pretty much try to
produce code that does the same thing, but hopefully usually
does it quicker.