Some iteration forms don't honor the principle that iteration variables are, by definition, always "used".

Bug #719585 reported by Jean-Philippe Paradis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Low
Douglas Katzman

Bug Description

What I do:
(do (var) (t))
(do* (var) (t))
(do-all-symbols (var))
(do-external-symbols (var))
(do-symbols (var))
(dolist (var '(1 2 3)))

What happens:
In all these cases, a STYLE-WARNING is signaled:
"The variable VAR is defined but never used."

What I expected to happen:
The standard states, in the section for Declaration IGNORE:

"The stream variables established by with-open-file, with-open-stream, with-input-from-string, and with-output-to-string, and all iteration variables are, by definition, always ``used''."

Glossary entry for "iteration variable": "n. a variable V, the binding for which was created by an explicit use of V in an iteration form."

Glossary entry for "iteration form": "n. a compound form whose operator is named in the next figure, or a compound form that has an implementation-defined operator and that is defined by the implementation to be an iteration form.

do do-external-symbols dotimes
do* do-symbols loop
do-all-symbols dolist"

These STYLE-WARNINGs thus seem to be spurious (as silly as the examples may be).

DOTIMES is not affected by this bug. LOOP doesn't seem to be either, though I only tried one trivial example.

The forms establishing stream variables are not affected by this bug.

SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

*features*:
(:SWANK :QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ANSI-CL :COMMON-LISP
 :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
 :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :UNIX :ELF :LINUX :SB-THREAD
 :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK
 :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS
 :CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-BARRIER-VOPS :LINKAGE-TABLE
 :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T)

Tags: ansi easy review
Changed in sbcl:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Roman Marynchak (roman-marynchak) wrote :

* (macroexpand '(dolist (v '(1 2 3))))

(BLOCK NIL
  (LET ((#:N-LIST609 '(1 2 3)))
    (TAGBODY
     #:START610
      (UNLESS (ENDP #:N-LIST609)
        (LET* ((#:TMP611 (TRULY-THE (MEMBER 3 2 1) (CAR #:N-LIST609)))
               (V #:TMP611))
          (SETQ #:N-LIST609 (CDR #:N-LIST609))
          (TAGBODY))
        (GO #:START610))))
  NIL)

This is very interesting. How can we make V to be "used" without the knowledge about the origin of the expansion (how do we know that it is an iteration form which is mentioned in CLHS)? Should DOLIST be re-implemented?

BTW, I find these style warnings to be quite useful. In fact, they are _right_, because there is no code which actually _reads_ from V.

Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

Spec says they're wrong, though.

  (declare (ignorable ...))

is the way to fix these.

tags: added: ansi easy
Revision history for this message
Roman Marynchak (roman-marynchak) wrote :

There is a patch. I am not sure about the formatting, so please adjust it if needed.

Changed in sbcl:
status: Triaged → In Progress
assignee: nobody → Roman Marynchak (roman-marynchak)
tags: added: review
Changed in sbcl:
assignee: Roman Marynchak (roman-marynchak) → nobody
Changed in sbcl:
status: In Progress → Confirmed
Revision history for this message
Douglas Katzman (dougk) wrote :
Changed in sbcl:
assignee: nobody → Douglas Katzman (dougk)
status: Confirmed → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.