<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 9/4/18 4:58 AM, Kristóf Umann wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGcXOD5LSVmSrW7SBqgBAh5m43JU_eC1h9VagqDOBbc2BYxTnw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">> I guess nobody did this before because plists
were supposed to be used by IDEs, and IDEs were supposed to have
their own jump-to-definition functionality (in this case, macro
definition).<br>
<br>
<div>Is it correct that plists are only meant for IDEs?</div>
</div>
</blockquote>
<br>
I mean, i understand that you're trying to extend the format for a
different but completely valid use case, and there's nothing wrong
about it, but i just shared my random guess on why was it not
important to support, originally, in a historical perspective.<br>
<br>
<blockquote type="cite"
cite="mid:CAGcXOD5LSVmSrW7SBqgBAh5m43JU_eC1h9VagqDOBbc2BYxTnw@mail.gmail.com">
<div dir="ltr">
<div>IDEs cannot always know which compilation action was used
to analyze the TU. Especially if the analysis (or the
compilation) is made for multiple targets (32-64 bits etc).<br>
</div>
</div>
</blockquote>
<br>
That sounds strange to me. IDEs are assumed to be responsible for
both compilation and analysis (otherwise what does "I" stand for?),
so they definitely do know this stuff. And it's clear that in our
case different build targets would produce different analysis
results, so any IDE that integrates the analyzer would need to keep
track of that.<br>
<br>
<blockquote type="cite"
cite="mid:CAGcXOD5LSVmSrW7SBqgBAh5m43JU_eC1h9VagqDOBbc2BYxTnw@mail.gmail.com">
<div dir="ltr">
<div>I've often been made aware of user complaints that the
Static Analyzer found a false positive, but it's often
virtually impossible to trace back what really happened, as
the cluster of macros was so hard to follow, not even
jump-to-definition was a satisfactory solution.<br>
</div>
</div>
</blockquote>
<br>
Users should either send preprocessed files with run-lines (a-la
what scan-build automatically dumps; possibly preprocessed with
-frewrite-includes to preserve macros), or very clear instructions
on how to build their code. Otherwise there are tons of other
reasons why you would be unable to reproduce the bug.<br>
<br>
One of the most infuriating problems with reproducing bugs is
hitting various complexity thresholds in the analyzer. Eg.,
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D28023">https://reviews.llvm.org/D28023</a> contains an epic story of how in
order to reproduce the bug i needed to hit a threshold with ±0.08%
precision. It's great that we have determinism, right?<br>
<br>
<blockquote type="cite"
cite="mid:CAGcXOD5LSVmSrW7SBqgBAh5m43JU_eC1h9VagqDOBbc2BYxTnw@mail.gmail.com">
<div dir="ltr">
<div>I think it would valuable to show the macro expansion as
the Static Analyzer expands it. I'm however a little uncertain
as to how I'd implement this. There's two options that came to
my mind:<br>
<br>
</div>
<div>* Add macro expansion info into the plist output (behind an
optional flag, and maybe a macros-as-events flag too). This
would easily be the best solution for my needs, but seems to
be hard to implement well. It also depends on other consumers
of the plist output whether there's an actual desire for this
feature other than mine.<br>
<br>
</div>
<div>* Develop a standalone clang tool that would create a new
file with the macro expansions. This would be the least
invasive solution for plist file generation, but also the
least comfortable for my needs.<br>
<br>
</div>
<div>My main question is, would you be fine with adding a new
macro node to the plist output?<br>
</div>
</div>
</blockquote>
<br>
I would probably not be using it in the foreseeable future, but i'm
definitely not opposed to it. It seems that plists are quite
reliable, i.e. adding more keys to their dictionaries usually
doesn't break existing stuff.<br>
<br>
Because George recently observed that generating plists might be a
relatively time-consuming operation (not as slow as generating htmls
but still noticeable in some cases), it might be good to keep it
under the flag; i'm not fully sure that these observations are
accurate, so if they aren't confirmed, i'm fine with having these
dumps without a flag.<br>
<br>
Are you planning to dump *all* macro expansions, or only expansions
around diagnostic pieces?<br>
<br>
<blockquote type="cite"
cite="mid:CAGcXOD5LSVmSrW7SBqgBAh5m43JU_eC1h9VagqDOBbc2BYxTnw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Cheers,<br>
</div>
Kristóf</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Kristóf Umann <<a
href="mailto:dkszelethus@gmail.com" moz-do-not-send="true">dkszelethus@gmail.com</a>>
ezt írta (időpont: 2018. aug. 27., H, 17:11):<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>Thanks for the great responses!<br>
<br>
</div>
I've had quite a few conversations with my colleges and
I think I'll take another direction with this, one that
doesn't involve plists. It's a great point to mention
that macro expansions shouldn't be handled by the
analyzer, although jump-to-definition isn't an ideal
solution to to my (our) problems, as macro definitions
are often very hard to read due to them containing
references to various other macros.<br>
<br>
</div>
Cheers,<br>
</div>
Kristóf<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">George Karpenkov <<a
href="mailto:ekarpenkov@apple.com" target="_blank"
moz-do-not-send="true">ekarpenkov@apple.com</a>> ezt
írta (időpont: 2018. aug. 18., Szo, 2:03):<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div
style="word-wrap:break-word;line-break:after-white-space">I
just wanted to say that it would be really amazing if
HTML output knew how to show the macros properly (I
guess it might be less critical for plists, as Artem
says).
<div>This is definitely one of my top complaints about
HTML reports; I’ve tried working on it at the past,
but other work took priority.</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Aug 17, 2018, at 4:55 PM, Artem Dergachev
via cfe-dev <<a
href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
wrote:</div>
<br
class="m_-1742139835440702351m_-2071606503778737690Apple-interchange-newline">
<div>
<div text="#000000" bgcolor="#FFFFFF"> I guess
nobody did this before because plists were
supposed to be used by IDEs, and IDEs were
supposed to have their own jump-to-definition
functionality (in this case, macro
definition).<br>
<br>
I don't know that much about macros and source
locations, but i suspect it should indeed be
possible to obtain the expanded text by
traversing spelling and expansion locations,
though probably sometimes scanning
token-by-token is inevitable. To state the
obvious, there are a lot of useful methods in
the SourceManager, but it's often unobvious
how to combine them correctly :/<br>
<br>
<div
class="m_-1742139835440702351m_-2071606503778737690moz-cite-prefix">On
8/17/18 5:09 AM, Kristóf Umann via cfe-dev
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi!<br>
<br>
I'm currently trying to implement a new
node in the plist output that would show
the expansion of a macro, like this:<br>
<br>
<span
style="font-family:monospace,monospace">void
setToNull(int **vptr) {</span><br>
<span
style="font-family:monospace,monospace">
*vptr = nullptr;</span><br>
<span
style="font-family:monospace,monospace">}</span><br>
<span
style="font-family:monospace,monospace"><br>
</span></div>
<span
style="font-family:monospace,monospace">void
print(void*);</span><br>
<div><br>
<span
style="font-family:monospace,monospace"></span><span
style="font-family:monospace,monospace">#define TO_NULL(x) \<br>
</span><span
style="font-family:monospace,monospace">
setToNull(x)<br>
</span><span
style="font-family:monospace,monospace"><br>
</span><span
style="font-family:monospace,monospace">#define
DOES_NOTHING(x) \</span><br>
<span
style="font-family:monospace,monospace">
{ \</span><br>
<span
style="font-family:monospace,monospace">
int b; \</span><br>
<span
style="font-family:monospace,monospace">
b = 5; \</span><br>
<span
style="font-family:monospace,monospace">
} \</span><br>
<span
style="font-family:monospace,monospace">
print(x)</span><br>
<span
style="font-family:monospace,monospace"></span><br>
<span
style="font-family:monospace,monospace">#define
DEREF(x) \</span><br>
<span
style="font-family:monospace,monospace">
DOES_NOTHING(x); \</span><br>
<span
style="font-family:monospace,monospace">
*x</span><br>
<span
style="font-family:monospace,monospace"></span><br>
<span
style="font-family:monospace,monospace">void
f() {</span><br>
<span
style="font-family:monospace,monospace">
int *a = new int(5);</span><br>
<span
style="font-family:monospace,monospace">
TO_NULL(&a);</span><br>
<span
style="font-family:monospace,monospace">
DEREF(a) = 5;</span><br>
<span
style="font-family:monospace,monospace">}</span><br>
<br>
For this code, two <span
style="font-family:monospace,monospace">PathDiagnosticMacroPiece</span>s
should be generated, and a message like
this should be displayed:<span
style="font-family:monospace,monospace"></span><br>
<span
style="font-family:monospace,monospace">
Expanding macro 'TO_NULL' to
'print(&a); setToNull(&a)'</span><br>
<span
style="font-family:monospace,monospace">
Expanding macro 'DEREF' to '{ int
sajt; sajt = 5; } print(a); *a'</span><br>
I've made some progress on this issue,
but here are the problems I faced.<br>
<br>
Currently, HTML file generation supports
macro expansions fairly well, however,
the code that achieves this seems to be
held together by sheer luck:<br>
<a
href="https://clang.llvm.org/doxygen/namespaceclang_1_1html.html#a3283736376c3e436ff65975acdb1d399"
target="_blank" moz-do-not-send="true">https://clang.llvm.org/doxygen/namespaceclang_1_1html.html#a3283736376c3e436ff65975acdb1d399</a><br>
As I understand it, the entire file is
re-lexed and preprocessed, during which
macro expansions are added to the HTML
file. I attempted to reuse the code here
without having to re-lex everything, but
so far my efforts lead to little
success. I also found that any
modification of this code quickly leads
to instabilities -- although this part
of Clang is somewhat of a mystery to me
just yet, so I'd concede to this being
my fault.<br>
<br>
I also fear that since HTML output is
not as used as other outputs, and could
lack vigorous testing, it could be
crash-prone.<br>
<div>
<div style="margin-left:40px"><br>
</div>
Do you know any way of obtaining the
expansion of a macro expression that
doesn't involve such <span
class="m_-1742139835440702351m_-2071606503778737690gmail-m_5067136254874769323gmail-yZ8quc
m_-1742139835440702351m_-2071606503778737690gmail-m_5067136254874769323gmail-ILfuVd">abusement</span>
of the preprocessor? Something like
this would be ideal:<br>
<span
style="font-family:monospace,monospace"></span><br>
<span
style="font-family:monospace,monospace"></span><span
style="font-family:monospace,monospace">SourceLocation Loc = /*
PathDiagnosticMacroPiece location
*/;</span><br>
<span
style="font-family:monospace,monospace"></span><span
style="font-family:monospace,monospace">Preproc.getMacroExpansionForExpression(Loc));</span><br>
<br>
Cheers,<br>
Kristóf</div>
</div>
</div>
<br>
<fieldset
class="m_-1742139835440702351m_-2071606503778737690mimeAttachmentHeader"></fieldset>
<pre class="m_-1742139835440702351m_-2071606503778737690moz-quote-pre">_______________________________________________
cfe-dev mailing list
<a class="m_-1742139835440702351m_-2071606503778737690moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
<a class="m_-1742139835440702351m_-2071606503778737690moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>