bug#8711: 24.0.50; binding _ to unused values with lexical-binding

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> There seems be no way to avoid a warning in code like this:

>> ;; -*- lexical-binding: t -*-
>> (eval-when-compile (require 'cl))
>> (defun foo (x) (destructuring-bind (_) x))

Hmm... the byte-compiler complains because the above gets turned into

     (let* ((--cl-rest-- x)
            (_
             (if (= (length --cl-rest--) 1)
                 (car --cl-rest--)
               (signal 'wrong-number-of-arguments (list nil (length --cl-rest--))))))
       nil)

which gets changes by byte-opt.el into
       
     (let* ((--cl-rest-- x))
       (if (= (length --cl-rest--) 1)
           (car --cl-rest--)
         (signal 'wrong-number-of-arguments (list nil (length --cl-rest--))))
       nil)

And note that this is only done for a `nil' body (tho it can also be
something like (progn nil) because that would be optimized to nil as
well), and not for a body like `5' (although the optimization is just
as valid for `5' as for nil).
         
>> (defun bar (x) (destructuring-bind (_) x (ignore _)))

  (defun bar (x) (destructuring-bind (_) x (ignore nil)))

works (because (ignore nil) happens not to be optimized to nil).
 
> This latter is because cconv-analyse-use is not smart enough when
> checking for use of variables starting with an underscore.

> ;; -*- lexical-binding: t -*-

> (let ((_ nil))
>   (ignore _))

> =>

> Warning: variable `_' not left unused.

> This despite ignore not touching it.

The two warnings come from different analyzes:
- The warning for `bar' comes from cconv.el which is intended to check
  whether the variable is syntactically used, rather than semantically.
- The warning for `foo' checks whether pure functions are not called for
  their side-effects and it's applied after optimizations so in the
  above code, the code generated by destructuring-bind ends up optimized
  to something that calls `car' without binding the result to _ because
  it figured that _ is not used and just got rid of it without warning.

So most likely the answers I give here aren't satisfactory to the OP,
since his real problem is probably different than (destructuring-bind
(_) x) and the solution for that problem is probably going to be
yet different.


        Stefan