Opened 10 years ago

Closed 10 years ago

#861 closed defect (invalid)

overzealous and flaky warning about SETQ'd unused lexical variable/

Reported by: mhd Owned by:
Priority: normal Milestone:
Component: Compiler Version: 1.6
Keywords: Cc:


Sometimes the compiler warns

style-warning: Unused lexical variable FOO

where FOO is some variable I've SETQ'd but then not referred to.

That's annoying enough. I don't think that should be done at all. It's a pain to have to throw away documentary (multiple-value-setq (x y z) ...) variables or go through other hoops just to get rid of this warning. Also, it's "used" by reasonable definition: it's set, just not "read" or "eval'd". Whatever. It's a pain to encounter and to work around.

But that's not the main point.

Sometimes -- not always!! -- I cannot even still the compiler by simply placing the variable inline to be evaluated.

The compiler first of all is so clever as to optimize out the reference, then turns on me and tells me it's not referenced. That is quite frustrating to put it mildly.

Seems to happen in big functions. Small functions work fine, so I cannot give you an example. But it's like this:

  (defun foo (a b) 
       (let (c d)
         (multiple-value-setq (c d) (round a b))

always warns about D "unused" (annoying to me, but I can deal with it)

  (defun foo (a b) 
       (let (c d)
         (multiple-value-setq (c d) (round a b))

not in this case, but in some larger functions, warns about D -- unacceptable, bug, etc.!

Note: let me know if this is a known problem: that is, the flakyness (dependency on function size, or whatever), or -- if not -- if you need an example. I'll put cycles on it, but would rather not if it's already known.

Version info:

            CCL::*OPENMCL-MAJOR-VERSION*,  Value: 1
            CCL::*OPENMCL-MINOR-VERSION*,  Value: 6

Change History (6)

comment:1 Changed 10 years ago by mhd

Update: hint and potentially great workaround:

I just discovered at least in one case changing the would-be "reference" from



  (progn blah)

stilled the compiler. Would like to know once this is diagnosed whether this is a reliable workaround.

comment:2 Changed 10 years ago by gz

The recommended way to disable these warnings is with declarations:

FWIW, it's not a known bug and it would certainly be useful to have a specific test case where the compiler complains about a variable being unreferenced even though it in fact has a (for-value) reference.

comment:3 Changed 10 years ago by gb

The spec's pretty clear that the presence or absence of IGNORE declarations affects whether warnings are issued in the presence or absence of "for value references" to the variables in question. Assigning a value to a variable and never referencing the variable's value seems to to me to be worthy of a style warning when no declaration suppresses that warning. (I think that we will warn about an assignment to a variable declared to be IGNOREd and the spec doesn't mention that case.)

Your claim that a warning is issued when there's a syntactic reference to the variable that's later optimized out is also puzzling, since (a) I can't reproduce that and (b) the parts of the compiler that concern themselves with tracking variable usage and the parts that decide whether or not to actually generate code for something that's entirely side-effect free are fairly far removed from each other. Under what optimization settings do you observe this behavior ?

I'm equally puzzled by the claim that X and (PROGN X) behave differently. When I first saw email about this ticket I misread it and thought that it was describing cases where different kinds of forms typed into the REPL produce different warnings (according to whether those forms are evaluated by a simple interpreter or by involving the compiler.) That is indeed confusing and inconsistent, but it wouldn't be involved here. I have no idea what is involved, and agree that we'd have to see a reproducible test case in order to understand the issue.

comment:4 Changed 10 years ago by mhd

Wow, today I learned that (declare (ignorable ...)) does everything I need here.

Yes, I will try to get you a reproducible case one of these days.

Just cannot share the exact code, but I can figure something out.

comment:5 Changed 10 years ago by mhd

Ah! Found the problem, and it was on my end: the variable reference was being interpreted as a tag. In the context of, say, a tagbody you cannot just drop a variable reference down. E.g., (tagbody ... blah ...) is really different from (tagbody ... (progn blah) ...).

So, all resolved. Please close this. Thanks.

comment:6 Changed 10 years ago by rme

  • Component changed from IDE to Compiler
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.