[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scratch/accurate-warning-pos: next steps.
From: |
Paul Eggert |
Subject: |
Re: scratch/accurate-warning-pos: next steps. |
Date: |
Tue, 11 Dec 2018 13:43:32 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 |
On 12/11/18 12:51 PM, Alan Mackenzie wrote:
Let's just assume we can get a list of functions from somewhere.
Exactly how is a minor implementation detail. I only suggested objdump
to demonstrate it was possible and easy. I think the C compiler, any C
compiler, can generate cross references. That would be another source
of the info.
I'm afraid that many C compilers don't generate cross references, and
that this is not a minor implementation detail that we can assume away.
That's OK, if the cost is borne only by people who want accurate
diagnostics. People who want compilation speed can simply turn off the
accurate-diagnostics flag.
WHAT???? There is no such flag, will be no such flag, MUST be no such
flag. We give accurate diagnostics to EVERYBODY, and we do this FAST.
That would be nice, but if we can't do it quickly (without significant
slowdowns elsewhere, or major contortions to the code) then perhaps
we'll have to settle for accurate diagnostics as an option.
The byte compiler is well over 8000 lines of code, much, possibly
most, of which would need to be rewritten
Although it would not be trivial to modify 8000 lines of code in a
tedious but mostly-systematic way, that is not what I would call an
enormous project. For perspective, the Emacs patch I'm currently hacking
on (in a different area) is currently about 3000 lines and I wouldn't be
surprised if it doubled before it's done. Sometimes even
reasonably-minor conceptual changes require many tedious changes to the
source code; that's just life when hacking.
I suggest you take on the task yourself, or organise a team
Thanks, but this issue is not that high on my priority list.
people writing macros don't have to and mustn't have
to care about diagnostic mechanisms. Lisp hackers deserve to get the
best diagnostics without any such ugly compromises being made.
As I understand it these annotations are not simply concessions to
limitations of our location implementation; they also provide
information that are useful for other reasons. I'm still not seeing
examples of why it would be hard for users to provide the optional
annotations, if they want the corresponding advantages.
- Re: scratch/accurate-warning-pos: next steps., (continued)
- Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps.,
Paul Eggert <=