[PATCH] D53024: [analyzer][www] Add more open projects

[Henry Wong via Phabricator via cfe-commits]

MTC added subscribers: teemperor, baloghadamsoftware, blitz.opensource.
MTC added a comment.
Herald added a subscriber: donat.nagy.

In https://reviews.llvm.org/D53024#1258976, @Szelethus wrote:

> 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.


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 :).



================
Comment at: www/analyzer/open_projects.html:98
+    efficient. For instance, if the function is pure, then a single bit of
+    information “this function is pure” would already be much better than
+    conservative evaluation, and sometimes good enough to make inlining not
----------------
`“this function is pure”` -> `"this function is pure"`


================
Comment at: www/analyzer/open_projects.html:100
+    conservative evaluation, and sometimes good enough to make inlining not
+    worth the effort. Gathering such snippets of information - “partial
+    summaries" - automatically, from the more simple to the more complex
----------------
`“partial` -> `"partial`


================
Comment at: www/analyzer/open_projects.html:259
+    <p>One of the more annoying parts in this is handling state splits for error
+    return values. A “Schrödinger state” technique that was first implemented in
+    the PthreadLockChecker (where a mutex was destroyed and not destroyed at the
----------------
Also here? `“Schrödinger state”` -> `"Schrödinger state"`


================
Comment at: www/analyzer/open_projects.html:267
+    <li>Many alpha checks can be turned into opt-in lint-like checks
+    <p>Path-sensitive lint checks are interesting and they can’t be implemented
+    in clang-tidy and there’s clearly an interest in them, but we here aren’t
----------------
`can‘t` -> `can't`


================
Comment at: www/analyzer/open_projects.html:268
+    <p>Path-sensitive lint checks are interesting and they can’t be implemented
+    in clang-tidy and there’s clearly an interest in them, but we here aren’t
+    having enough maintenance power to respond to bugs and false positives. If
----------------
`there‘s` -> `there's`
`aren‘t` -> `aren't`


Repository:
  rC Clang

https://reviews.llvm.org/D53024