Usage in an annotation is no odr-use, so I think there needs to be no
definition. Upside is that in practice one will get linker errors if it
is actually odr-used instead of calling a function that returns 0.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D106375
Previous description didn't actually state the effect the attribute has on
thread safety analysis (causing analysis to assume the capability is held).
Previous description was also ambiguous about (or slightly overstated) the
noreturn assumption made by thread safety analysis, implying the assumption had
to be true about the function's behavior in general, and not just its behavior
in places where it's used. Stating the assumption specifically should avoid a
perceived need to disable thread safety analysis in places where only asserting
that a specific capability is held would be better.
Reviewed By: aaronpuchert, vasild
Differential Revision: https://reviews.llvm.org/D87629
They are for more powerful than the current documentation implies, this
adds
* adopting a lock,
* deferring a lock,
* manually unlocking the scoped capability,
* relocking the scoped capability, possibly in a different mode,
* try-relocking the scoped capability.
Also there is now a generic explanation how attributes on scoped
capabilities work. There has been confusion in the past about how to
annotate them (see e.g. PR33504), hopefully this clears things up.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D87066
The old locking attributes had a generic release, but as it turns out
the capability-based attributes have it as well.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D87064
I don't think this is obvious, since try-acquire seemingly contradicts
our usual requirements of "no conditional locking".
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D87065
The attribute documentation now conforms to Aaron Ballman's renaming of the
thread safety attributes, as well as the new paper that is due to be published
in the conference on Source Code Analysis and Manipulation (SCAM 2014) later
this week. In addition, recent changes to the analysis, such as checking
of references and negative capabilities, are now documented.
llvm-svn: 218420