It might worth updating the Programmer's Manual, it still states that SmallSet has no support for iteration.

I played around with it, and this seemed a bit cleaner. Since I would only match against the definition of the record (and the definition of its methods), the matcher would need to look like this: stmt(hasDescendant(blahBlah(...))), and I'd only be able to retrieve (with my limited knowledge) the entire method definition, not the actual FieldDecl in the case of a match.
I didn'd do a whole lot of AST based analysis, so feel free to correct me on this one ^-^

@george.karpenkov @xazax.hun, is this how you imagined checking whether an access is guarded?

Ping :)

Thanks. Somehow I missed that being accidentally removed in rC342221.

Cool! Looks a lot cleaner.

Fixes according to inline comments.

I ran the checker on LLVM/Clang and grpc, and saw no crashes at all! Quite confident about the current diff. However, I'm not 100% sure it doesn't break on Objective C++ codes. Can you recommend a project like that?

There are some nasty environment issues I'm dealing with, so the issue is the lack of a well functioning creduce, but I'll get it done eventually.

Generalized the patch so that the user can supply the pattern that is matched against the fields of the records.

Polite ping :)

How then do you think I should try matching the IntPointerArray example? I am now leaning towards not doing this via AST Matchers as I am not sure if I can easily match more complex cases.

Sounds like a test case would be great to have.

Aye. I'd be good to land this with that testcase. There are a variety of other projects I'm working on (related to the checker), and none of them depend on this patch, so I'll commit this once I figure out how to use creduce ><

Added doc to www/analyzer/alpha_checks.html.

I've been made aware of some valid concerns with this patch. I'll revisit this at a later time, please ignore it for now.

Polite ping ^-^

Fixed an assertation failure where a lambda field's this capture was undefined.

Fixed a crash where the returned region's type wasn't CXXRecordDecl. I'm not even sure how this is possible -- and unfortunately I've been unable to create a minimal (not) working example for this, and I wasn't even able to recreate the error locally. However, on the server where I could repeatedly cause a crash with the analysis of lib/AST/Expr.cpp, this fix resolved the issue.

Reuploaded with -U99999. Oops.

This is pretty cool!

Would you be comfortable me commiting this without that assert, or should I come up with a more risk-free solution?

Fixed a crash, where the super region was symbolic.

Fixed two crashes. Interesting how many much better this approach works, as I've never encountered FunctionTyped objects or only forward declared typed pointers after dereferencing.

I managed to cause a bunch of crashes with this patch, so consider it as a work in progress for now :/

In D49986#1192798, @Szelethus wrote:

In D49985#1181568, @NoQ wrote:

In D49985#1181564, @dblaikie wrote:

It looks like concat orders the arguments in the same way that the output would be (so concat(X, list) produces [X, list]) - so preserving that argument order seems like it improves/retains readability compared to switching them around so 'concat(list, X)' produces '[X, list]'.

Yeah, i guess that might have been the motivation behind such inconsistency. I'll be fine with fixing the order for other data structures.

@NoQ Have your views changed about this patch? Shall I abandon it?

Thanks for taking a look!

Now using universal references.

Actually, the note messages were incorrect as in this case the static and dynamic type of the object differs.

Rebased to D51057.

Rebased to D51057.

Addressed the inline comments.

• Added a llvm::SmallSet to further ensure the termination of the loop.
• Changed isLocType to isDereferencableType, block pointers are regarded as primitive objects.
• Added new tests

@NoQ, is this how you imagined derefercing to work? I'm still a little uncertain that I implemented this in a way that addresses all your concerns.