LARA

Here is a list of common questions along with their answer.

phantm is an acronym of “PHp ANalzer for Type Mistakes”

We believe that even if PHP puts close to no restrictions on types, it is still interesting to verify that they are handled correctly. It is easy to identify patterns of type errors that are directly caused by programming mistakes. We thus bring some of the advantages of statically typed languages to PHP.

No. First of all, static analysis has its limitations. There will always be false positives given the semantics of PHP. However, you can help phantm do a better job, by precisely annotating your code. See Annotations for more details.

Also, you'll notice that by default phantm is quite picky about uninitialized values, or implicit type conversions.

For instance, on the code $a = "2"; echo $a / 2;, phantm will report that $a is not a valid operand for /. Even though those “errors” are not critical and PHP itself handles them gracefully in most cases, it is still considered “bad style” by phantm.

phantm represents types as so-called Lattice elements. In the type Lattice, Top represents the supertype of all types, and Bottom represents the subtype of all PHP types. In short, Top means “Every possible types” (including uninitialized values) and Bottom means “No type”.

Any represents types of defined values. However, the fact that a variable is undefined is represented as a type as well, namely Uninitialized. Any does not include Uninitialized, but Top does.

References are currently ignored by phantm.

phantm will try to reduce the size of errors as much as possible by limitting the string representation of types to the parts that are relevant for the type error.

Numeric is simply Float or Int. Unlike PHP's is_numeric, It does not include numeric string literals.

This is because phantm refines types used in expressions. For instance, given the code

function foo($b) {
    $a = $b / 2; // (1)
    $c = $b / 3; // (2)
}

Before (1), $b is Any and thus issue an error since / expects two numeric types. However, after (1), we can assume that $b is Numeric. This is essential, as it dramatically reduces the number of errors! For instance, on (2), no error is issued.

However, if $b is later used where a String is specifically required, you'll get an error looking like: expected String, found Numeric.

Yes! Usually, the option --quiet or even --shy will do a decent job on removing the least significant errors. Note however that it might potentially hide important notices.