In D152436#4408301, @steakhal wrote:

In D152436#4405558, @balazske wrote:

These are reports that could be improved:
link
In this case function fileno returns -1 because of failure, but this is not indicated in a NoteTag. This is a correct result, only the note is missing. This problem can be solved if a note is displayed on every branch ("case") of the standard C functions. But this leads to many notes at un-interesting places. If the note is displayed only at "interesting" values another difficulty shows up: The note disappears from places where it should be shown because the "interestingness" is not set, for example at conditions of if statement. So the solution may require more work. This case with function fileno occurs 13 times in all the tested projects.

Could you elaborate on what do you mean by "The note disappears from places where it should be shown because the "interestingness" is not set, for example at conditions of if statement.". A short example would do the job I think.

I looked at the TPs, and if the violation was introduced by an assumption (instead of an assignment), then it's really hard to spot which assumption is important for the bug.
I wonder if we could add the TrackConstraintBRVisitor to the bugreport to "highlight" that particular assumption/place.

Another question is if default value of ModelPOSIX can be changed to true?

One deficiency is that some filenames of test files contain the old std-c-library-functions-arg name that is not used any more.

I could test the checker on these projects (CTU analysis was not used):
memcached,tmux,curl,twin,vim,openssl,sqlite,ffmpeg,postgres,tinyxml2,libwebm,xerces,bitcoin,protobuf,qtbase,contour,acid

removed check name in documentation code comment

There are still some problems with dependencies, the ErrnoChecker really needs now the StdCLibraryFunctions checker (to be turned on and run before) but this is not enforced. The checker order looks to work but not enforced specially.

Updated documentation and removed occurrences of old checker name.

The case of fully dependent type (unique_ptr<T>) is not working in this checker and likely not in SharedPtrArrayMismatchCheck. I can fix this in a next patch (for both checkers).
Maybe we can remove the warning in all cases when the type is a POD type (or add a check option)?

Fixed the documentation issue.
Added tests.

Applied another review suggestion.

Applied review suggestions, removed the list of functions.

Change of some type definitions, using restrict again.

using "wihch" at argument values

using short way for getting macro value
added constraint description

added special argument condition function to remove code repetition

using __restrict instead of restrict

Fixed formatting problems.

Simplified AST matchers a bit.
Added check for list-initialization syntax at constructor call.
Added some tests.
Updated documentation.

Fixed documentation issues.
Check is added to list.rst.

I decided to add back DescriptionKind and make possible to use a message like
"should not be NULL". Now all generated strings in functions describe and
describeArgumentValue start with "should be" or "is" to make this consistent.
The messages are now in form "is ... but should be ..." which sounds at some times
too trivial but acceptable as generated message.

ping
This is a solution for a problem at least until a better fix is found.

In D145868#4189574, @vabridgers wrote:

Hi @balazske , all LIT and unittests pass with this change. By your logic, then we are missing some LIT or unittest cases that support your statement. Can you think of a case that demonstrates this? Thanks!

Added a simple test and another test.
Instead of calling getTypeDeclType only the reuse of existing type is done
(this was the part that fixes the problem). In this way the underlying type
is still imported. The result is not correct but fixes some crash.

The problem is somewhat bigger and not fast to fix. This test shows what is problematic:

TEST_P(ASTImporterOptionSpecificTestBase,
       ImportExistingTypedefToUnnamedRecordPtr) {
  const char *Code =
      R"(
      typedef const struct { int fff; } * const T;
      extern T x;
      )";
  Decl *ToTU = getToTuDecl(Code, Lang_C99);
  Decl *FromTU = getTuDecl(Code, Lang_C99);

There are some unresolved comments in the test (cast is not needed at Import and EXPECT_TRUE can be used) but otherwise LGTM.
(But I have a feeling that problems may happen with attributes like GuardedByAttr if these are imported before the field is added to the record. Probably it is better to only import the NoUniqueAddressAttr in VisitFieldDecl.)

My opinion is that we can not omit importing the "underlying type". The TypedefType has the type of the declaration (type of getDecl()) and the "underlying type" that may be different (this is the thing that comes from commit D133468). This is exactly different if TypedefType::typeMatchesDecl() (returns a stored value in TypedefType) returns true. In this case the type object is stored in the TypedefType node and is not the same as the type of declaration getDecl(). If function getTypeDeclType is used it creates the typedef type always with the type of getDecl() and the typeMatchesDecl will always return true for this type even if at the to-be-imported type it was false.

Change format of bug reports.
Now the problem is shown first, then the acceptable values.
Sometimes the messages can become too verbose (in case of
"should be NULL") or grammatically not totally correct,
I can not tell if this is acceptable but this was the most
simple implementation.

rebase, reformatted code

changed comments, small variable rename

The new test should be better, it imports the f function without new and no VaList should exist in the imported translation unit. It looks like the test.cpp is appended to the AST after the import of the other files. I changed function CreateVaListDecl to always use the AArch64 create function, the test did not fail.

Changed the lit test.

Updated the test.

A tried to find out how to add a correct test but could not check if this fails or not on AArch64 platform. The test should import the va_list declarations and then another variable std. I want to touch ASTContext only if a test failure is found on AArch64 that makes it necessary. In that case I would add a non-modifying function getVaListTagDeclIfExists, another option is to change all other simiar get functions to "getOrCreate" form to have consistent API.

Add a test.