This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Add FuchsiaLockChecker and C11LockChecker
ClosedPublic

Authored by xazax.hun on Jan 24 2020, 12:11 PM.

Details

Summary

Basically, the semantics of C11 and Fuchsia locks are very close to PThreads. Most of the work was boilerplate to make sure the correct check name appears in the diagnostics. If you have any idea how to reduce this boilerplate I'd like to know :)

I had to add a dummy check that can always be enabled. Otherwise, CheckerManager::getChecker would trigger an assertion fail due to attempting to get a checker that was potentially not enabled.

I plan to add more tests but wanted to share early to get some feedback about the approach.

Diff Detail

Event Timeline

xazax.hun created this revision.Jan 24 2020, 12:11 PM
NoQ added a comment.Jan 24 2020, 3:35 PM

Yay, C11 as well!!

If you have any idea how to reduce this boilerplate I'd like to know :)

I don't see any immediate solutions to the boilerplate that don't consist in introducing better checker APIs. Eg., we could have introduced a LazyBugType - a wrapper around Optional<BugType> that'd take description immediately but create the actual bug type only once the checker name is known, or we could make a MultiCallDescriptionMap that'd prevent us from both splitting up the map and writing down an extra piece of information on every line. But these are big and very much non-K.I.S.S. endeavors.

I had to add a dummy check that can always be enabled. Otherwise, CheckerManager::getChecker would trigger an assertion fail due to attempting to get a checker that was potentially not enabled.

You mean PthreadLockBase? I think that's how @Szelethus intended to have such checker hierarchies to work.

I plan to add more tests

Yes please! :D

clang/test/Analysis/c11lock.c
2

I wouldn't mind alpha.core given that these functions belong to the standard library.

2

(i.e., i mean put the checker into alpha.core)
(but, yeah, also please add core to the run-line)

xazax.hun marked an inline comment as done.Jan 24 2020, 4:33 PM
xazax.hun added inline comments.
clang/test/Analysis/c11lock.c
2

You are reading my mind. Actually I wanted to ask where to put this but forgot to ask :)

xazax.hun updated this revision to Diff 240624.Jan 27 2020, 9:42 AM
xazax.hun marked 2 inline comments as done.
  • Add more tests.
  • Move the C11 checker to alpha.core
In D73376#1839818, @NoQ wrote:

I don't see any immediate solutions to the boilerplate that don't consist in introducing better checker APIs. Eg., we could have introduced a LazyBugType - a wrapper around Optional<BugType> that'd take description immediately but create the actual bug type only once the checker name is known, or we could make a MultiCallDescriptionMap that'd prevent us from both splitting up the map and writing down an extra piece of information on every line.

Those would be very welcome additions. Although these are more likely to be useful for advanced users and not help with writing one's first checker, so I guess this remains to be nice to have :)

You mean PthreadLockBase? I think that's how @Szelethus intended to have such checker hierarchies to work.

Yay!

xazax.hun marked 2 inline comments as done.Jan 27 2020, 9:47 AM
xazax.hun added inline comments.
clang/test/Analysis/c11lock.c
8

Strictly speaking, this is implementation defined. But the C11 implementations I am aware of are following this trend (thrd_success == 0). E.g. if the implementation is using pthreads as a backend it is unlikely for this to be any other value.

33

This is a TODO, and I did not solve in this patch for two reasons:

  • Having a mutex in stack scope is rare and prone to errors.
  • I did not want to add new functionality in this patch.

That being said I am not sure if I want to add this anytime soon (due to reason 1).

NoQ added inline comments.Jan 27 2020, 11:39 AM
clang/test/Analysis/c11lock.c
8

Yeah, this is most likely fine but we should add a FIXME just in case. We could most likely uncover the exact constant easily by simply matching the AST (and abort all checking if the constant isn't found in the AST).

  • Add a FIXME.
NoQ accepted this revision.Jan 27 2020, 12:02 PM

LGTM!~

This revision is now accepted and ready to land.Jan 27 2020, 12:02 PM
This revision was automatically updated to reflect the committed changes.

Documentation under clang/docs/analyzer/checkers.rst seems to be missing. Could we get that fixed before 11.0.0 releases?