[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to merge scratch/correct-warning-pos into master, perhaps?
From: |
Brahimi Saifullah |
Subject: |
Re: Time to merge scratch/correct-warning-pos into master, perhaps? |
Date: |
Sat, 22 Jan 2022 20:16:43 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (windows-nt) |
I'm very sorry for the noise, it seems I replied to the wrong Alan :(
https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01454.html
Brahimi Saifullah <brahimi.saifullah@gmail.com> writes:
> 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 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).
>
> 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.
>
>
>> Again, many thanks for the help.
>
> And thanks for the work you've done, faulty warning
> positions had always been an annoyance of mine :)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, (continued)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/22
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/22
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/22
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/23
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/23
Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/15
Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Brahimi Saifullah, 2022/01/15
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Brahimi Saifullah, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/22
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?,
Brahimi Saifullah <=
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/23
Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Andrea Corallo, 2022/01/17