\htmlhr
\chapterAndLabel{Must Call Checker}{must-call-checker}

The Must Call Checker conservatively over-approximates
the set of methods that an object should call before it is de-allocated.
The checker does not enforce any rules other than subtyping;
in particular, it does not enforce that the methods are called before
objects are de-allocated.
The Must Call Checker is intended to be run as a subchecker of another checker.
The primary client
of the Must Call Checker is the Resource Leak Checker (Section~\ref{resource-leak-checker}),
which enforces that every method in a must-call obligation for an expression is called
before that expression is de-allocated.

For example, consider a \<java.io.OutputStream>.  This \<OutputStream>
might have an obligation to call the \<close()> method, to release an
underlying file resource. The type of this \<OutputStream> is
\<@MustCall(\{"close"\})>.  Or, the \<OutputStream> might not have such an
obligation, if the underlying resource is a byte array. The type of this
\<OutputStream> is \<@MustCall(\{\})>.
For an arbitrary \<OutputStream>, the Must Call
Checker over-approximates the methods that it should call by assigning it
the type \<@MustCall(\{"close"\}) OutputStream>, which can be read as ``an
OutputStream that might need to call \<close()> (but no other methods)
before it is de-allocated''.

If you are running the Resource Leak Checker
(\chapterpageref{resource-leak-checker}), then there is no need to run the
Must Call Checker, because the Resource Leak Checker does so automatically.
Running both may lead to warning suppressions for the Must Call Checker not
working.


\sectionAndLabel{Must Call annotations}{must-call-annotations}

The Must Call Checker supports these type qualifiers:

\begin{description}

\item[\refqualclasswithparams{checker/mustcall/qual}{MustCall}{String[] value}]
  gives a superset of the methods that
  must be called before the expression's value is de-allocated.
  The annotation is not refined after a method is called; an expression of
  type \<@MustCall("foo")> might or might not have already had \<foo()>
  called on it.
  The default type qualifier for an unannotated type is \<@MustCall(\{\})>.

\item[\refqualclass{checker/mustcall/qual}{MustCallUnknown}]
  represents a value with an unknown or infinite set of must-call obligations.
  It is used internally by the type system but should never be written by a
  programmer.

\item[\refqualclass{checker/mustcall/qual}{PolyMustCall}]
  is the polymorphic annotation for the Must Call type system.
  For a description of polymorphic qualifiers, see
  Section~\ref{method-qualifier-polymorphism}.

\item[\refqualclasswithparams{checker/mustcall/qual}{InheritableMustCall}{String[] value}]
  is an alias of \<@MustCall> that can only be written on a class declaration.
  It applies both to the class declaration on which it is written and also to all subclasses.
  This frees the user of the need to write the \<@MustCall> annotation on every subclass.
  See Section~\ref{must-call-on-class} for details.

\end{description}

\begin{figure}
\includeimage{mustcall}{5cm}
\caption{Part of the Must Call Checker's type
qualifier hierarchy.  The full hierarchy contains one \<@MustCall> annotation
for every combination of methods.
Qualifiers in gray are used internally by the type system but should
never be written by a programmer.}
\label{fig-must-call-hierarchy}
\end{figure}

Here are some facts about the type qualifier hierarchy, which is shown in
Figure~\ref{fig-must-call-hierarchy}.
Any expression of type \<@MustCall(\{\}) Object> also has type
\<@MustCall(\{"foo"\}) Object>.
The type \<@MustCall(\{"foo"\}) Object>
contains objects that need to call \<foo> and objects that need to call
nothing, but the type does not contain an
object that needs to call \<bar> (or both \<foo> and \<bar>).
\<@MustCall(\{"foo", "bar"\}) Object> represents all objects that need to
call \<foo>, \<bar>, both, or neither; it cannot not represent an object that needs
to call some other method.


\sectionAndLabel{Writing \<@MustCall>/\<@InheritableMustCall> on a class}{must-call-on-class}

As explained in Section~\ref{upper-bound-for-use}, a type
annotation on a type declaration means that every use of the type has that
annotation by default.  If a class \<A>'s declaration has a \<@MustCall>
annotation, then \<A>'s subclasses usually should too.  To do so, a programmer can either write
a \<@MustCall> annotation on every subclass, or can write \<@InheritableMustCall>
on only \<A>, which will cause the checker to treat every subclass as if
it has an identical \<@MustCall> annotation.  The latter is the preferred style.

For example, given the following class annotation:
\begin{Verbatim}
    package java.net;

    import org.checkerframework.checker.mustcall.qual.InheritableMustCall;

    @InheritableMustCall({"close"}) class Socket { }
\end{Verbatim}
any use of \<Socket> or a subclass of \<Socket> defaults to \<@MustCall(\{"close"\}) Socket>.

The \<@InheritableMustCall> annotation is necessary because type
annotations cannot be made inheritable.  \<@InheritableMustCall> is
a declaration annotation.


%% \sectionAndLabel{Lightweight ownership annotations}{must-call-ownership-annos}

%% TODO: this explanation feels...lacking to me. It doesn't make that much sense IMO
%% without explaining the must-call consistency checker's usage of Owning/NotOwning.
%% It's therefore been commented out here. Some version of this needs to appear, either
%% here or in the documentation of the consistency checker, when that is merged. For now,
%% this manual page doesn't list @Owning or @NotOwning at all, because they can't be explained
%% without context - so we've decided to treat them as if they don't exist, for now.

%% In many programs, aliasing creates two or more program elements that represent the same
%% underlying object on which some methods might need to be called (i.e. whose type has a non-empty
%% \<@MustCall> qualifier). For example, an \<OutputStream> might be stored in both
%% a local variable and a field. Typically, the Must Call Checker will over-approximate both
%% the local variable and the field (and any other pointers to the object) as \<@MustCall(\{"close"\})>:
%% that is, because all \<OutputStream> objects might need to be closed, each pointer to an
%% \<OutputStream> might need to be closed, too. In practice, however, some of these pointers can be
%% ignored: they are \emph{non-owning}. In the example of an \<OutputStream> that is stored in both
%% a local variable and a field, for instance, it may be the case that the field is non-owning (such
%% as a cache) and the local is owning; or, it might be the case that the field is owning (an open connection,
%% for example, that will be closed later), and the local is non-owning.

%% The Must Call Checker supplies two annotations to support this concept: \<@Owning> and \<@NotOwning>.
%% The Must Call Checker's support for these annotations is limited: method parameters annotated as
%% \<@NotOwning> are treated as bottom (i.e. \<@MustCall(\{\})>) within the method bodies in which they
%% appear. A client analysis of the Must Call Checker can use these annotations as a guide for which
%% pointer to a given object is intended by the programmer as the pointer through which the must-call obligations
%% of the object are satisfied, but these annotations are only hints.

%% This feature can be disabled by passing the \<-AnoLightweightOwnership> command-line parameter to the Must
%% Call Checker.


\sectionAndLabel{Relationship to lightweight ownership}{must-call-non-owning-parameter}

The Must Call Checker interacts with the \<@Owning> and \<@NotOwning> annotations of the
Resource Leak Checker (Section~\ref{resource-leak-checker}). In particular, any location that
the Resource Leak Checker would consider ``non-owning'' (e.g., unannotated parameters, \<@NotOwning>
returns, etc.) is treated as \<@MustCall({})> by the Must Call Checker. This can lead to surprising
results when running the Must Call Checker alone (which is not recommended). For example,
consider the following program:

\begin{Verbatim}
  @MustCall({"toString"}) String foo(@MustCall({"hashCode"}) String arg) {
    return arg;
  }
\end{Verbatim}

The Must Call Checker will not issue a warning about this code, because \<arg>
is non-owning (and therefore treated as \<@MustCall({})>).


\sectionAndLabel{Assumptions about reflection}{must-call-reflection}

The Must Call Checker is unsound with respect to reflection: it assumes
that objects instantiated reflectively do not have must-call obligations (i.e., that their
type is \<@MustCall(\{\})>. If the checker is run with \<-AresolveReflection>, then
this assumption applies only to types that cannot be resolved.

\sectionAndLabel{Type parameter bounds often need to be annotated}{must-call-type-params}

In an unannotated program, there may be mismatches between defaulted type
qualifiers that lead to type-checking errors.  That is, the defaulted
annotations at two different locations may be different and in conflict.  A
specific example is in code that contains a mix of explicit upper bounds
with an \<extends> clause and implicit upper bounds without an \<extends>
clause.

For example, consider the following example (from
\href{https://github.com/plume-lib/plume-util}{plume-util}) of an
interface with explicit upper bounds and a client with implicit upper
bounds:
\begin{Verbatim}
  interface Partition<ELEMENT extends @Nullable Object, CLASS extends @Nullable Object> {}

  class MultiRandSelector<T> {
    private Partition<T, T> eq;
  }
\end{Verbatim}

The code contains no \<@MustCall> annotations.
Running the Must Call Checker on this code produces an error at each use
of \<T> in \<MultiRandSelector>:

\begin{smaller}
\begin{Verbatim}
error: [type.argument] incompatible type argument for type parameter ELEMENT of Partitioner.
        private Partitioner<T, T> eq;
                            ^
  found   : T extends @MustCallUnknown Object
  required: @MustCall Object
error: [type.argument] incompatible type argument for type parameter CLASS of Partitioner.
        private Partitioner<T, T> eq;
                               ^
  found   : T extends @MustCallUnknown Object
  required: @MustCall Object
\end{Verbatim}
\end{smaller}

The defaulted Must Call annotations differ.
\<Partitioner> has an explicit bound, which uses the usual default of \<@MustCall(\{\})>.
\<MultiRandSelector> has an implicit bound, which defaults to top (that is,
\<@MustCallUnknown>), as explained in Section~\ref{climb-to-top}.

In many cases, including this one, you can eliminate the false positive
warning without writing any \<@MustCall> annotations.
You can either:
\begin{itemize}
\item
  add an explicit bound to \<MultiRandSelector>, changing its declaration to
  \code{class MultiRandSelector<T extends Object>}, or
\item remove the explicit bound from \<Partition>, changing its declaration to
  \code{interface Partition<ELEMENT, CLASS>}.
\end{itemize}

% LocalWords:  de subchecker OutputStream MustCall MustCallUnknown
% LocalWords:  PolyMustCall InheritableMustCall MultiRandSelector
% LocalWords:  Partitioner
