Mind you, there are some ideas I didn't add to the list -- I just don't know how to put them to words nicely, but I'm on it.
- Enhancing constraint solving. I just simply lack the knowledge to make an entry here about it.
- Fixing up taint analysis.
@george.karpenkov mentioned assigning a unique error code to each analyzer warning, and maintaining it on the website.
Also, a lot of items on this list is outdated, but I joined the project relatively recently, so I'm not sure what's the state on all of them.
Whoa thanks! Will have a closer look again.
|33 ↗||(On Diff #168810)|
I'll try to list other constructor kinds that i have in mind.
|76 ↗||(On Diff #168810)|
|86–87 ↗||(On Diff #168810)|
I'll try to be more, emm, positive on the website :]
|234 ↗||(On Diff #168810)|
|235 ↗||(On Diff #168810)|
|262 ↗||(On Diff #168810)|
Something is unfinished here.
I admit that the difficulty was mostly chosen at random, so that could be brought closer to the actual difficulty of the project.
|86–87 ↗||(On Diff #168810)|
Oh, right, sorry, I tried to "positivitize" most of these, but apparently missed this one O:)
AFAIK, the items below is outdated.
- Enhance CFG to model C++ temporaries properly (This problem has basically been fixed by @NoQ.)
- Enhance CFG to model C++ new more precisely (This problem has basically been fixed by @NoQ.)
- Implement iterators invalidation checker (IIRC, @baloghadamsoftware has solved this, see IteratorChecker.cpp.)
- Write checkers which catch Copy and Paste errors (IIRC, @teemperor has solved this, see CloneChecker.cpp)
- Enhance CFG to model C++ delete more precisely (@blitz.opensource's focus is no longer on clang static analyzer, so we should not keep him as current contact.).
And there are items, I'm not sure what the current state is. Like:
- Explicitly model standard library functions with BodyFarm. (This item is marked as ongoing, it doesn't look very active nowadays.)
If I'm wrong, @NoQ and @george.karpenkov, please correct me. In addition 2018 Bay Area LLVM Developers' Meetings may bring some new open projects :), see http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof6.
At the end, there are some punctuation problems, yea, I browsed this page through the browser :).
|98 ↗||(On Diff #168810)|
“this function is pure” -> "this function is pure"
|100 ↗||(On Diff #168810)|
“partial -> "partial
|259 ↗||(On Diff #168810)|
Also here? “Schrödinger state” -> "Schrödinger state"
|267 ↗||(On Diff #168810)|
can‘t -> can't
|268 ↗||(On Diff #168810)|
there‘s -> there's
In addition 2018 Bay Area LLVM Developers' Meetings may bring some new open projects :)
Actually, let's commit this before the conference, even if it's not perfect, so that people who suddenly get inspired to work on Static Analyzer already had an updated list :)
|29 ↗||(On Diff #169193)|
@george.karpenkov your turn here.
|33 ↗||(On Diff #169193)|
Actually, maybe let's turn this into a single project with sub-bullets and list all problems instead of just one.
Ok if i just dump my thoughts with markdown? >_<
|69 ↗||(On Diff #169193)|
"supporting all of them" -> "modeling all methods in all classes of the standard library"
|70 ↗||(On Diff #169193)|
Maybe move "One good thing to start..." into a sub-bullet?
|86–87 ↗||(On Diff #169193)|
"Pointer-to-pointer casts are also causing a surprising amount of problems. The decision to re-use ElementRegion to track the type of the object behind the pointer value seems to create more problems than it solves, but..."
|109–116 ↗||(On Diff #169193)|
Let's move this into a sub-bullet of "Enhance the modeling of the standard library." and remove the part about std::string, but instead say "This is often effective for simple C functions such as atomic builtins and certain related threading functions (such as call_once) because atomicity doesn't have any meaning for Static Analyzer and can be completely ignored. This approach is not recommended for functions dealing with complicated C++ code - temporaries, templates - unless you have unbelievably good AST handwriting and recite all supported versions of the C++ standard by heart."
|144 ↗||(On Diff #169193)|
Let's move this into the construction context bullet. I think we do call the destructor now but it might be that we don't call the custom delete operator.
|177 ↗||(On Diff #169193)|
Let's mark this with "Refactoring: ".
|308 ↗||(On Diff #169193)|
This should be removed because we already have a bullet for this.
|29 ↗||(On Diff #169193)|
Let's just skip it.
|314 ↗||(On Diff #169193)|
This is handled by Z3 invalidation, I'm not sure it's worth it spending much effort here in the long run.
Yes it is. Though the other item you mentioned should be on this list -- I just simply forgot to put it there before updating the diff O:). Feel free to commandeer it, this patch is barely my work.
@Szelethus thanks! BTW if you really want to invest into maintaining the website,
I think it's totally worth it to change all contents to markdown,
and then have a script to generate HTML from that.
Committers would be expected to manually run that script.
This would also solve our problem with the disappearing header.
This is extremely important to get right. Alpha doesn't mean "i did an experiment, let me dump my code so that it wasn't lost, maybe others will pick it up and turn it into a useful checker if they figure out how". Alpha doesn't mean "a checker that power-users can use at their own risk when they want to find more bugs". Alpha doesn't mean "i think this checker is great but maintainers think it's bad so they keep me in alpha but i'm happy because i can write in my resume that i'm an llvm contributor". All of these are super popular misconceptions.
Alpha means "i'm working on it". That's it.
Let's re-phrase to something like: "When a new checker is being developed incrementally, it is committed into clang and is put into the hidden "alpha" package (from "alpha version"). Ideally, once all desired functionality of the checker is implemented, checker should be moved out of the alpha package and become enabled by default or recommended to opt-in into, but development of many alpha checkers has stalled over the years."
I guess let's add the rest of the constructors from my message above.
Something's wrong here.
Let's ignore (3) as a red herring, but I'm not sure I see the difference between (1), (2) and (4). When someone works actively on a checker, but then stops, it immediately transfers from state (4) to state (2) and optionally (1)
What message above? The original email?
This is kinda mostly about the attitude with which people should put stuff into the alpha package. Yeah, if someone stops for inevitable reasons, then we're inevitably left with unmaintained experimental code in the repo, i guess that's why this section exists. But contributors shouldn't plan for this from the start. A lot of contributors literally believe that alpha is by design a stockpile of incomplete work and weird experiments and it'll make everybody happy if they add more incomplete work and weird experiments into it, i myself misunderstood this for a long time and i want to address this misconception.
|198 ↗||(On Diff #169933)|
Probably it is worth mentioning here, that there is a macro language already for describing summaries of standard library functions in StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp.
This macro language could be refactored to a separate header file so it could be used in other checkers too. Could also be extended for C++.
Another useful addition would be to enable users to describe these summaries in run-time (in YAML files for example) to be able to model their own proprietary library functions.
Then as a next step we could introduce a flow sensitive analysis to generate such summaries automatically. Which is a hard problem indeed, the others above should not be too difficult