[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-devel
Subject:    Re: [Sbcl-devel] [Sbcl-commits] master: Signal an error for (MAPCAR 'A-MACRO '())
From:       Douglas Katzman <dougk () google ! com>
Date:       2016-05-14 19:51:11
Message-ID: CAOrNasyzvPx0g7N_a0qzvLyLw4fPgEW0MXeFoRpgZRAL-G6U+w () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


> This sounds good but do you know why this shows up on the list of Likely
> suspicious calls?
>

Yes, because I'm the only one who knows how I defined the term "suspicious"
in that check!
And in fact I didn't introduce this "likely suspicious" call now, it's from
b29f6c2670c6e9f71c466004a55073f03df94037.

What the test is trying to do is discriminate between a few scenarios:
1. you compiled a full call to FOO and then defined a compiler macro.
In that case, even though the compiler macro could legally have declined to
produce a new form, it's worth a warning if was not defined because it's
probably not your intent to have not seen the macro definition.
2. inline functions - since there's no such thing as an inline function
that declines to provide an expansion, it almost *always* suspicious to
compile a full call; except if there was a (locally (notinline)).  But if
there is a known inline expansion, but it's proclaimed notinline, I think
you can get a false warning. Maybe?

Anyway the second check is basically flawed and I plan to remove it now
that I've enforced that you *can't* have any inlining failures in
self-build.

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 This sounds good but do you know why this shows up on the list of Likely<br>
suspicious calls?<br></blockquote><div>  </div><div>Yes, because I&#39;m the only one \
who knows how I defined the term &quot;suspicious&quot; in that check!</div><div>And \
in fact I didn&#39;t introduce this &quot;likely suspicious&quot; call now, it&#39;s \
from b29f6c2670c6e9f71c466004a55073f03df94037.</div><div><br></div><div>What the test \
is trying to do is discriminate between a few scenarios:</div><div>1. you compiled a \
full call to FOO and then defined a compiler macro.</div><div>In that case, even \
though the compiler macro could legally have declined to produce a new form, it&#39;s \
worth a warning if was not defined because it&#39;s probably not your intent to have \
not seen the macro definition.</div><div>2. inline functions - since there&#39;s no \
such thing as an inline function that declines to provide an expansion, it almost \
*always* suspicious to compile a full call; except if there was a (locally \
(notinline)).   But if there is a known inline expansion, but it&#39;s proclaimed \
notinline, I think you can get a false warning. \
Maybe?</div><div><br></div><div>Anyway the second check is basically flawed and I \
plan to remove it now that I&#39;ve enforced that you *can&#39;t* have any inlining \
failures in self-build.</div><div>  </div></div></div></div>



------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel


[prev in list] [next in list] [prev in thread] [next in thread]