Re: Time to merge scratch/correct-warning-pos into master, perhaps?

[Alan Mackenzie <acm@muc.de>]

Hello, Brahimi.

On Sat, Jan 22, 2022 at 20:16:43 -0300, Brahimi Saifullah wrote:
> I'm very sorry for the noise, it seems I replied to the wrong Alan :(

:-)  I know the feeling.  I'm massaging your post a bit and replying to
it.

> Alan Mackenzie <acm@muc.de> writes:

>> With the current state of the git branch, flymake on a .el file now
>> seems to be working for me.

> Yes, Flymake is working perfectly now.

> I did notice an issue with the warning for unused forms:

>     value returned from (#<symbol + at 2> 1 1) is unused
>     (from byte-compiling a file that consists of "(+ 1 1)")

I'll look at that later today, thanks.

> I expect that the symbol should be used, not the symbol with
> positions.  But it looks like this just got fixed a few hours ago
> in master while my build was from before the merge.


> While further testing this I also found a couple problems relating to
> unused function arguments -- I'm unsure if they have anything to do with
> the latest round of changes or not.

> First, a bug:

>     (defun f (a b c)
>   ; ^^^ Warning: Unused lexical argument `a'
>   ;      Warning: Unused lexical argument `b'

>     "A B C."
>     (+ 1 1))
>   ; ^^^ Warning: Unused lexical argument `c'

> You should be able to reproduce it by copying the above function
> somewhere and byte compiling (sans the).

Yes, no problem.  That was a one-line correction to some hairy code which
went to great lengths to get a correct (or close) warning position in the
previous mechanism.  Sorry about the mistake.

I've committed the fix for this to master.

> If the function consists of a single form, the position returned for
> the last "unused lexical argument" will wrongly point to it.  In this
> example, the warning about C being unused will instead point to `+'.

> The second issue is that, even when the unused lexical argument warnings
> work correctly, they always point to the "defun," and not to the actual
> argument in question.  Not the end of the world of course, but it would
> be nice for them to be more accurate.

I think it's fixed now.  Thank you indeed for the bug reports.

>> Again, many thanks for the help.

> And thanks for the work you've done, faulty warning
> positions had always been an annoyance of mine :)

-- 
Alan Mackenzie (Nuremberg, Germany).