- User Since
- Apr 6 2020, 5:32 AM (40 w, 5 d)
Tue, Jan 12
Wed, Jan 6
Tue, Jan 5
I guess I want to clarify one point here, after this patch the parser will not assume that statement always follows statement attributes. We simply turn off the assumption that what follows is a declaration, parser will simply determine whether it is a statement or a declaration, it can do it on its own without attribute's "help".
Wed, Dec 23
Refine condition for statement attributes
Correct some comments and names
Tue, Dec 22
Maintain previous behavior unless preceeded by a statement attribute
@aaron.ballman I totally agree, but I also would like to understand.
__attribute__ is a GNU extension, right? Then why does it affect the grammar of C? I always thought that attributes should be somewhat transparent for parsers, but it looks like in this situation all compilers automatically assume that __attribute__ begins a declaration.
It is unclear to me why *x;, [[unknown]] *x; (dereference of x) and __attribute__((unknown)) *x; (declaration of int *) have different meanings.
Fix block.c test
Mon, Dec 21
Fri, Dec 18
Add more test cases
Add one gigantic comment on status kinds and the reasons behind some of the design choices
Detect all conventions for captured parameters as well
Dec 17 2020
Dec 16 2020
Add more info to the docs
Turn off conventional check heuristic
Dec 15 2020
Introduce a suppression for double call warning by nullifying the parameter.
Fix minor things
Refine conventions for completion handlers
Dec 14 2020
Add documentation for new attribute and fix review remarks
Dec 11 2020
Right now, I reused existing suppress attribute. However I did it in a rather unconventional manner. I allowed 0 arguments in one spelling and >1 in another, which seems odd.
I can see a couple other possible solutions here:
Dec 9 2020
Here is the HTML file for the test.
Replace let with const
@aaron.ballman Can you please take a look at the attribute side of this?
Dec 4 2020
Fix incorrect comment
The operations that would not leave an event in the report are now clearly printed.
But there are three arrows that confuse me in the example report: the assignment x = 0 (x -> 0 -> x), the function call dereference(x) (x -> dereference), and the return statement return *x (int -> *x). I know the arrow is based on the evaluation order of the engine. But from the view of a user, I think these arrows are confusing to some extent.
For the first two, I think it would be better to point just the statement (maybe a CFGElement) without inner arrows (x -> 0 -> x and x -> dereference), or point to the location of the operator itself rather than the BeginLoc (e.g. x -> 0 -> =). For the third one, an arrow from the function name to the first CFGElement looks good to me. And an arrow from the returned expr to the return type or to a special mark (e.g. ⬅️) can also be added, together with function calls (an arrow from the callstmt to a special mark, e.g. ➡️).
Sorry, for the confusion. I did not come up with the idea of arrows and neither did I chose which tokens are connected by arrows. It is an existing feature, and it existed for quite a long time. The analyzer can produce plist files that contain all these locations, plist files are further used by Xcode to draw arrows. You can see a very old example on our website: https://clang-analyzer.llvm.org
Essentially I took this existing information and used it in the HTML report generation as well. The biggest chunk of this commit is the algorithm for drawing SVG curves.
Here is how it looks for that test file:
Dec 3 2020
Nov 30 2020
That's a good fix!
How did this happen though that max value of off_t was even used for fd. Seems pretty odd!
Nov 25 2020
Add another comment
Add more comments and fix another test.
Nov 24 2020
Fix tests and a typo
Nov 23 2020
LGTM! But I'd like other folks to take a look at it first.
Oct 20 2020
Oct 19 2020
Great job, I think it's awesome to have more control over the analyzer with the language itself.
Sep 21 2020
Great job! I also wanted to support more operations for range-based logic.
After this "accepted" and a huge thank you 😄
I came up with exactly the same fix! Great job!
I just wanted to refactor it and not having
Sep 7 2020
Sep 2 2020
Can we cover __builtin_unique_stable_name as well?
Sep 1 2020
Aug 28 2020
Aug 27 2020
Not that it would matter much, but I was just wondering why there is a slightly bigger memory usage in some of the docker/small projects? The most conspicuous is oatpp.
The measurements fluctuate quite significantly and as you can see the means for both old and new experiments for oatpp are pretty close. So, I would say that the memory differences are not conclusive.
This being said, the performance measurements should also be taken with a grain of salt. We can't really say that we get 5-10% performance improvement for sure, but that analysis tends to be faster instead.
Fix review remarks
Aug 26 2020
Here are some benchmarking results.
Natively on my Mac (no memory measurements due to this issue during psutil installation):
Aug 25 2020
I'll add the charts with performance in the next couple of days
WDYT about moving introducing a generic "SmallImmutableSet" in llvm/ADT to back your implementation?
Oof, it is not really possible. First of all, existing RangeSet didn't really ensure that ranges do not intersect (add is/was not checking for that), and this is left for the user. Additionally, it is designed and optimized specifically for RangeSet queries and operations. Like intersect and contains in a more generic Set sense mean entirely different things.
Aug 24 2020
Awesome! I will submit the patch!
Aug 13 2020
Awesome, looks great!