zaks.anna added a comment.
Please, move the conversation on how to configure/use CodeChecker in the
particular setting elsewhere. I think it could be useful to the clang dev list;
however, this patch review is not the proper place for it.
http://reviews.llvm.org/D12906
_
o.gyorgy added a comment.
Hi,
Sorry for my late answer.
We fixed the plist parser for the CodeChecker it shoud process the
plist generated by the current trunk clang with the issue hash tags.
Right now CodeChecker does not support forwarding additional options
directly to clang (uses only the co
Hi,
Sorry for my late answer.
We fixed the plist parser for the CodeChecker it shoud process the
plist generated by the current trunk clang with the issue hash tags.
Right now CodeChecker does not support forwarding additional options
directly to clang (uses only the compiler options from the ori
honggyu.kim added a comment.
In http://reviews.llvm.org/D12906#274724, @o.gyorgy wrote:
> Hi,
>
> You are right the diff is is based on the hash. We already tried to
> use an earlier hash generator (before the patch was introduced), which
> generates a slightly different plist, that is why the
o.gyorgy added a comment.
Hi,
You are right the diff is is based on the hash. We already tried to
use an earlier hash generator (before the patch was introduced), which
generates a slightly different plist, that is why the current version
does not work with the patch.
We will fix CodeChecker to u
Hi,
You are right the diff is is based on the hash. We already tried to
use an earlier hash generator (before the patch was introduced), which
generates a slightly different plist, that is why the current version
does not work with the patch.
We will fix CodeChecker to use new hash tag introduced
honggyu.kim added a comment.
In http://reviews.llvm.org/D12906#273089, @xazax.hun wrote:
> By default it is disabled for security reasons. You can enable by passing a
> command line option to the code checker, something like --not-host-only.
Thanks, I can remotely access now with --not-host-on
dkrupp added a comment.
Hi,
its a good idea to include in LLVM/Clang i will propose it
In http://reviews.llvm.org/D12906#272265, @zaks.anna wrote:
> Hi Daniel,
>
> Have you considered contributing this work to clang/llvm?
It's a good idea I will propose this at cfe-dev.
Daniel
http://revie
xazax.hun added a comment.
In http://reviews.llvm.org/D12906#273088, @honggyu.kim wrote:
> In http://reviews.llvm.org/D12906#272257, @dkrupp wrote:
>
> > Hi Anna & Kim,
>
>
> Hi Daniel,
>
> > we recognized these scalability issues you just described and that's why we
> > created CodeChecker http
honggyu.kim added a comment.
In http://reviews.llvm.org/D12906#272257, @dkrupp wrote:
> Hi Anna & Kim,
Hi Daniel,
> we recognized these scalability issues you just described and that's why we
> created CodeChecker https://github.com/Ericsson/codechecker/
> tool. A HTML report viewer for Cla
honggyu.kim added a comment.
Hi Anna,
In http://reviews.llvm.org/D12906#272243, @zaks.anna wrote:
> I think you misunderstood my comment. I am not talking about using the
> existing HTML files here but rather having an HTML viewer, which you could
> use to browse source code. This viewer would
zaks.anna added a comment.
Hi Daniel,
Have you considered contributing this work to clang/llvm?
http://reviews.llvm.org/D12906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dkrupp added a comment.
In http://reviews.llvm.org/D12906#272243, @zaks.anna wrote:
> > > In http://reviews.llvm.org/D10305#224956, @zaks.anna wrote:
>
> >
>
> > > For example, you could keep the information about the reports in the
> > > plist files and use those to
>
> >
>
> > > render th
zaks.anna added a comment.
> > In http://reviews.llvm.org/D10305#224956, @zaks.anna wrote:
>
> > For example, you could keep the information about the reports in the plist
> > files and use those to
>
> > render the reports in HTML.
>
>
> If you're okay with adding HTML file name in
honggyu.kim abandoned this revision.
honggyu.kim added a comment.
Hi Anna,
I was away from the office for 3 weeks. Sorry for the late answer.
In http://reviews.llvm.org/D12906#256215, @zaks.anna wrote:
> I find it very confusing to have 2 different fields for bug identification -
> issue_hash
zaks.anna added a comment.
Should this be closed?
http://reviews.llvm.org/D12906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zaks.anna requested changes to this revision.
zaks.anna added a comment.
This revision now requires changes to proceed.
I find it very confusing to have 2 different fields for bug identification -
issue_hash and BugId. Why do we need to treat the HTML reports differently from
plist files?
http
honggyu.kim added a comment.
In http://reviews.llvm.org/D12906#250237, @zaks.anna wrote:
> I agree with Gabor and do not think we should have 2 entries in the plist
> file for bug identification. This is confusing and I do not see a need for
> this.
>
> Any comparison script can check for 2 fie
zaks.anna added a comment.
I agree with Gabor and do not think we should have 2 entries in the plist file
for bug identification. This is confusing and I do not see a need for this.
Any comparison script can check for 2 fields in a plist file and concatenate
them. We've already discussed this d
honggyu.kim added a comment.
Hi Anna and Gábor,
I modified this patch based on http://reviews.llvm.org/D10305 following your
comments.
I think we can distinguish issue_hash and Bug ID. issue_hash is considered as a
subset of Bug ID here.
1. issue_hash contains
(1) column number
(2) source lin
honggyu.kim updated the summary for this revision.
honggyu.kim updated this revision to Diff 35070.
http://reviews.llvm.org/D12906
Files:
include/clang/StaticAnalyzer/Core/BugId.h
lib/StaticAnalyzer/Core/BugId.cpp
lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
lib/StaticAnalyzer/Core/PlistDi
xazax.hun added a comment.
In http://reviews.llvm.org/D12906#248418, @honggyu.kim wrote:
> (3) bug type (bug message)
As far as I remember the other version of this patch exclude any message that
is displayed to the user deliberately, to make the hash more resilient to
changes to those string
honggyu.kim added a comment.
You made a comment while I was writing other comment :)
In http://reviews.llvm.org/D12906#248392, @zaks.anna wrote:
> This new patch does not seem to build on top of
> http://reviews.llvm.org/D10305 but is an alternative way of generating the
> hash that reuses a l
honggyu.kim added a comment.
Just to make it simpler to understand, original strings of issue_hash are as
below with this patch:
BUG 1
3$returna;$Garbage return value
BUG 2
3$intb=a;$Assigned value is garbage or undefined
BUG 3
3$returna;$Garbage return value
This consists of the 3 f
xazax.hun added a comment.
I was thinking a bit more, what would be the best way to determine what should
we include in the hash.
In order to determine that first we need to define the scope of the hash
itself. There are several sensible choices such as:
- identify bugs that were generated by
xazax.hun added a comment.
I can see two very differen directions on the two version of this patch. I
think this is bad and we should pick one.
In the other version we started to exclude some of the stuff (like filename)
from the hash, since it is available already in the plist and gives the
p
zaks.anna added a comment.
This new patch does not seem to build on top of http://reviews.llvm.org/D10305
but is an alternative way of generating the hash that reuses a lot of the
building blocks from the other patch. What is the reason for that?
(It also addresses your comment to this patch an
honggyu.kim added a comment.
I think we can enhance the bug comparison method one by one rather than making
a big change at once.
The point of this patch is to make "issue_hash" field in plist more robust
while still using existing CmpRuns.py for comparison.
I would like to hear any kind of com
honggyu.kim added a comment.
issue_hash is generated with hash value rather than line offset from function
as below:
issue_hash765b04830932fef5631bf3c48c4d2db2
http://reviews.llvm.org/D12906
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
honggyu.kim created this revision.
honggyu.kim added reviewers: jordan_rose, krememek, zaks.anna, danielmarjamaki,
babati, dcoughlin.
honggyu.kim added subscribers: cfe-commits, phillip.power, seaneveson,
j.trofimovich, hk.kang, eszasip, dkrupp, o.gyorgy, xazax.hun, premalatha_mvs.
This patch br
30 matches
Mail list logo
